Step 2: Design an Interface
Not Started

I hope you had a chance to think about how you felt while writing that code. Here are my thoughts:

Overloading the OrderController's createOrder() method wasn't the right decision. Method overloading is not necessarily a bad idea, but in the context of this code, it's not the best approach:

Lack of Scalability

Looking ahead, we might use "Partner" accounts to place orders with the OrderController. If so, we'd need to overload the createOrder() method again to accept a PartnerAccount. Having three methods with the same name and similar behavior might make our code more complex and harder to maintain.

Maintenance Overhead:

If you modify the shared logic in overloaded methods, you must update each version individually. This increases maintenance work and the risk of bugs if any method is overlooked during updates.

Code Duplication

The method's code is quite similar, with the account type being the main difference. We can simplify this by "factoring out" the common elements, similar to our previous approach in the inheritance lesson.

Method overloading isn't the best option in this case. We'll use an interface and polymorphism to address these issues. In the upcoming lessons, you'll:

  • Develop an interface usable by any account for placing orders
  • Apply this interface to both BusinessAccount and PersonAccount
  • Modify OrderController to use this generic interface rather than a specific account type

Challenge

Create an interface called IAccount. It should have a method with the following specifications:

  • Name: placeOrder
  • Parameters: An instance of the Order sObject
  • Return type: void