Step 1: Life without Interfaces
Not Started

In the next four lessons, we'll refactor "bad" code and replace it with an interface. You're in an org that has this BusinessAccount class:

public class BusinessAccount { Account accRecord; public BusinessAccount(Account a){ this.accRecord = a; } public void placeOrder(Order o){ if(isValidOrder(o)){ InvoiceGenerator.sendNewInvoice(accRecord, o); } } private Boolean isValidOrder(Order o){ Boolean isValid = false; // Validation logic specific to business accounts // isWithinCreditLimit() // hasOverdueInvoice() return isValid; } }

It's a wrapper for the Account sObject. Business accounts have their own unique process for validating and placing orders.

There is also a class named PersonAccount. It's also a wrapper for the Account sObject, but it represents a person, not a business. It's placeOrder and isValidOrder methods are different as a result:

public class PersonAccount { Account accRecord; public PersonAccount(Account a){ this.accRecord = a; } public void placeOrder(Order o){ if(isValidOrder(o)){ CreditCardEngine.chargeCardOnFile(accRecord, o); } } private Boolean isValidOrder(Order o){ Boolean isValid = false; // Validation logic specific to person accounts // isCreditCardOnFile() // doesExceedOrderLimits() return isValid; } }

You're asked to build a common controller class to share between business and person accounts. See the challenge below for details.

Challenge

The outline of OrderController has been provided. The createOrder() method is overloaded to accept an instance of either PersonAccount or BusinessAccount along with the order.

For each method, implement the body by calling the placeOrder method of the respective account instance. This is the same public method you saw above for BusinessAccount and PersonAccount.

After you submit, reflect on your feelings about this code. What do you like, and what do you hate? Does it go against the topics we talked about earlier with abstraction, code duplication, and other topics?