Abstract Classes

[00:00:00]
>> Spencer Schneidenbach: So we talked about virtual. I wanna talk about abstract classes. Abstract classes are classes that are meant to be inherited from and cannot be instantiated directly. If I'm modeling this in a very object, if I'm modeling this particular business problem, right? I have employees, some of them are hourly, some of them are salary.

[00:00:19]
If I'm modeling that in a specific way and they're an employee, they're always gonna be paid. So I may not want to instantiate this employee class directly. So I might declare it as what's called abstract. An abstract essentially says, I cannot inherit, or, sorry, I cannot instantiate the employee type directly.

[00:00:37]
So if I say, var newwww = new Employee, it's gonna say you can't do that because you can't create a type of an abstract class. An abstract class is meant to define properties and behaviors but in a way that says, you need another object to actually use this in order for it to be useful.

[00:00:57]
>> Spencer Schneidenbach: So the implications of abstract classes, you can also declare what's called an abstract method. And an abstract method forces derived types to implement the behavior on this method. So you see that we have an abstract string class. You can see at the end, we put a semicolon.

[00:01:15]
There is no body on this method. We are saying that we want inherited classes to define this behavior such that we may then choose to override it in such a way, oops, let's do this. Override it in such a way as to make the base class force it to provide its own behavior.

[00:01:37]
And if you don't do that, if you choose not to, declare this as abstract, don't override this, the compiler will throw an error, say, you have to implement this member. So really important and really useful, especially as we talk about interfaces. I'm gonna end this section by saying that I have spicy takes about inheritance.

[00:01:58]
I think that lots of developers, new and old, tend to overuse inheritance once they realize what it is. Most business problems don't model well in inherited classes. Specifically, I wanted to point out, I promised that if I said that I wrote something that I wouldn't write in real life, that I would tell you.

[00:02:16]
I would almost certainly, probably not write an employee class where it's an abstract class, and then have the hourly and the commissioned employees be inherited from that and provide different behaviors that way. This is a design thing, not a language thing, just letting you know kind of that I prefer a very flat inheritance hierarchy.

[00:02:35]
In fact, organizational hierarchies, I prefer those to be flat as well. In real life, if I were doing this, I wanna tell you about how I would actually model this problem. I would probably just have an employee class and have an enum to say, some of these are hourly, some of these are salary, some of these are salary plus commission, and so on and so forth.

[00:02:55]
And then have a class that actually defines the way that I would calculate the payment for those things. This documentation is example of calculate pay, is obviously gonna be different for an hourly employee versus a salaried employee. Salary is fixed, an hourly is paid by the hour, right?

[00:03:13]
So I just wanted to warn you, put out there my opinion that I think inheritance can be overused and abused sometimes. Most of the time, I find that developers are trying to inherit from lots of objects, or really go for inheritance because they don't like the duplication of code.

[00:03:31]
So I wanted to point out that there is the principle of don't repeat yourself. And developers tend to try to use inheritance to go so far as to not repeat a property even once, whereas I go for the moist principle. Moderate overlap is sometimes tolerable, especially if I'm talking about code that I've copy-pasted a couple of times.

[00:03:50]
Listen, I'm in it to ship products. So if I copy-paste my toe code once or twice, I'm probably gonna be okay with that. Any more than that, I'm probably gonna look, okay, is there an abstraction that would prevent me from copy-pasting it? So inheritance is important, and I did wanna provide a warning.

[00:04:05]
Soapbox over.