In a previous post Anthony Ferrara looked at design patterns and their use (and usefulness) in modern applications. in this new post he continues the series but focuses more on a strategy to move past them related to inheritance.

In my last post, I talked about revisiting the concept of Design Patterns and questioned how useful it is to "learn" them. The conclusion that I came to was that you are better served by focusing on how objects communicate rather than traditional patterns. Well, that's not the only "traditional concept" that I think we should move beyond. So, let's talk about inheritance...

He starts with a bit of definition about what inheritance actually is (for a little context) related to classes, not traits or interfaces. He compares two ideas around this inheritance - the actual implementation of it in the code and the specification of it, the planning a "promise" the structure defines. He discusses the separation of these two ideas and that what matters is that the specification is implemented - how doesn't matter as much. He gets down to the most basic concept behind the idea of inheritance, the idea of a "contract", that defines the "agreement" the implementation puts into practice.

Finally, he gets down to what he calls "the key" behind inheritance and encapsulation of functionality into desecrate parts - behaviors. These allow you to know what kind of functionality comes from which class/object without having to guess. Methods have behaviors and objects are collections of these, combining to make a larger object-centric behavior.

Object Oriented Programming is all about abstraction. Each layer is an abstraction of code below it. Using "types" makes this difficult, because often we don't have real-world analogs to represent each layer. After all, an abstraction is specifically not a type. It's the concept behind it. With behaviors, this comes naturally.