Inheritance

Reading Only

As seen in the shopping cart example, methods provide an excellent way to reuse code. You can encapsulate your logic in a method and then call it as many times as you need.

With OOP, we can take things a step further, especially when dealing with more complex data structures. We can organize classes and establish relationships between them to capture shared characteristics. Let's draw a parallel to a math problem: think about the equation 2x^2 + 6x. To simplify this expression, you'll notice that 2x is a common term for both 2x^2 and 6x. So, you can factor it out. The result2x(x+3).

In Apex, we can achieve something similar using inheritance. Inheritance allows us to define parent and child relationships between classes so that we can inherit attributes and methods. It's like factoring out the parts that multiple classes share, creating an organized structure.

I won't show you the code for inheritance just yet, I'll save that for the next course. Instead, I'll show UML diagrams to help illustrate the concept. Try to relate it back to the algebra problem we saw earlier. If you need it, here's a intro to UML Diagrams.

Let's get started. Say you have a class designed to represent subscription products. This class includes attributes such as name and price. The total cost of a product is calculated based on the price after applying sales taxes. Your class might look something like this:

Now, consider that you also have a class for service-based products. These also have a name and price, but they also introduce an additional attribute called hours, which signifies the duration of the service. The pricing is structured per hour, so the total cost is derived by multiplying the price by the number of hours, with sales taxes applied in the same manner. The class might look something like this:

Here's what the same between the two classes:

• name attribute
• price attribute
• The signature and the implementation of the applyTaxes() method
• The signature of the calculateTotalPrice() method
  
  

Here's what is different:

• Service products have an hour attribute, subscriptions do not
• The implementation of the calculateTotalPrice() method
• The constructors

Just as in the example of simplifying 2x^2 + 6x to 2x(x+6) there are shared elements and differences between the two classes. If we focus on preserving what's unique to each class, our two classes would look like this:

The part that's the same can go into a base/parent class called Product.

Instead of having ServiceProduct and SubscriptionProduct call Product by invoking its methods, we can have them inherit the attributes and methods from Product instead.

I lied. I'll show you some code. Assume this is the implementation of SubscriptionProduct like the UML outlined for us:

public class SubscriptionProduct extends Product {
    public SubscriptionProduct(String name, Decimal price){
        super(name, price);
    }
}

There is pretty much nothing here. You'll see some unfamiliar syntax like extends and super() - I'll get to that in the next course. Yet, even though there's nothing in here, I can write this code and it will compile and execute:

SubscriptionProduct sp = new SubscriptionProduct('OS Software - 1 Year', 500.00);
Decimal totalPrice = sp.calculateTotalPrice();
System.debug(totalPrice); // Outputs 550.00 assuming a 10% sales tax ( 500 * 1.10 = 550)

calculateTotalPrice() doesn't exist on SubscriptionProduct and yet I was able to call it. That's inheritance.

SubscriptionProduct inherited the methods and attributes from its superclass, Product. That's just a sneak peek of the code - I'm not expecting it to click by now. Stick around for the next course to understand the details of writing code like this.