Software Development

Your base classes and data structures should be the foundation of your overall software system for the current application. These are tools made available to the rest of your software. As such, they should have a consistent expected behavior. Changing the behavior of your base classes and tools after the fact is a surefire way to cause havoc within your software.

I've often heard of an example where the internals of base classes are hidden away is the Windows GUI system. I had to laugh. You can access windows properties from anywhere in your code. You can even inspect another applications window properties. There is nothing hidden about the Windows GUI. With Borland compilers, you can use something called the VCL (Visual Component Library). It is an OOP wrapper for the Windows GUI. It works extremely well, but it does have limitations. Often, you can derive these classes and create your own. But VCL uses the ideology of encapsulating the internals of base classes. As such, derived classes have no access to its base classes' internals. Visual components are essentially state objects. They hold properties. So if you try and create a different kind of component that has a slightly modified behavior, you are out of luck because the base class will be out of sync with its derived class. This happens a LOT. So you're left with only one option which is to create your own component from scratch when all you needed was access to one internal property.

I've said it before and I'll say it again, the 'private' keyword should not exist. The main issue is this. If you have a list of private internal states and only declare public virtual functions, you are out of luck. Even if you override those virtual functions, you have no access to the internal state and cannot update it. That means you have to duplicate and keep track of all internal states, many of which you have no clue about because it is all hidden away. In short, it means you're writing from scratch even though you may be deriving from a base class. I've seen this happen a LOT.

Let me say it again, if you use the 'private' keyword, you are sacrificing extensibility. If you end up changing base classes, then may I suggest you stop doing that and first try to figure out what exactly you are supposed to be doing.

The use of the 'private' keyword ties in with the YAGNI principle. I've heard this a lot, especially by library writers. On the surface, it makes sense. Once you include a feature, you can never take it out. And the more features you have, the more that can go wrong. While this is true, you can't sacrifice a complete feature set for the sake of YAGNI. And this is where I veer off from accepted OOP practices yet again. I believe in feature sets. This is more commonly known as structured programming. Or separation of concerns.

Let me rewind and talk about classifications. Take a something as simple as a rock. Do we categorize it as a solid? As an inert object? As a tool? As a projectile? As a weapon? As a building material? The list is endless. When we write software, we have the tendency to globally classify objects. Classes are global and many languages don't have proper features for classification. The truth is that the classification of an object should not be determined by its base class, but rather by its user (or how it is used, i.e. how it is interacting with other objects).

To see this more clearly, consider a human being. Someone can be a government official, a tennis player (or any of the countless sports), a church member, a neighborhood watch member, etc. It'd be insane to use these classifications as base classes. Classifications can change depending on the location of the entity and its interactions. As such, classifications are better represented as members of a set. Base classes are used to retain and extend global properties of the entity itself. And if you understand this concept, then you can start to see exactly why the base class encapsulation principle is flawed.

If you use base classes as a classification, and we must as there are no other tools available, then we run into a problem. Classifications MUST change. Since these things change depending on its use, we must change the base classes if the requirements of the software change. This is why people choose base class encapsulation so that any changes are reflected through virtual functions and not its internals which would be unmaintainable.

The solution is to remove classification from being a base class. Instead, use the separation of concerns principle. This dates from the 70s, but it is used everywhere, mostly unknowingly. What you do is have another object that can view the primary object in a manner of its choosing. IOW, you use a helper object to represent another class as if it were in a different classification. A common issue with this is how to tag extra information. You need either an extension API or simply add it as a secondary base class if it's common enough. That way, you keep different properties grouped separately and can be used with different types of objects.

The concept of having different views for the same object is very powerful. It is something that is lacking in most programming languages. In fact, all accepted programming practices frown upon this. And even with all the issues that keep coming up, no one is looking at WHY these issues exist. And it doesn't surprise me that they do not look more closely. Helper objects (or view objects) MUST be able to look at the internals of the primary object upon which they are acting. Helper objects should also be used for enabling interactions between two primary objects. That way, you can still keep encapsulation, but at the helper object level, not at the primary object level. Primary objects should only declare functions where it can accomplish the task without the assistance of another object. Otherwise, you get into the problem of who should commit an action.

This last issue is so pervasive that I'm amazed programmers live with it. When two objects must interact, which one should perform the action? The answer is neither. If one of them performs the action, then you are including excessive and unnecessary coupling. If neither one performs the action, then the two primary objects remain reusable in other applications or in other parts of the same application. The helper object will handle the action and as such is specific to your application. And that's the way it should be. Your application should be about acting upon independent objects and manipulating them in a way that produces the expected result. But once you start including those specific actions within the primary objects themselves, you lose any concept of reusability and extensibility. Don't even think about those two features. They're gone.

Once you understand how these things affect each other, you start to see better ways to organize your software. You know you're on the right track when you can keep adding things to your software LONG after critical decisions have been made. So when you hear mention of YAGNI, be wary of how they are developing software. Check if they are putting all functionality within a single class. Java is especially worrisome as they do not allow multiple inheritance. There are ways around it, but it isn't very much fun. Also check if they include methods that call methods in other objects. This is 100% likely. The real world has solved this problem time and again. You have primary objects and then you have other objects that act upon those primary objects. If you keep this principle in mind, you will find your applications so much easier to build and maintain. You'll also notice that programming is a lot more fun.