DEV Community: wrong-about-everything

Static classes are evil

wrong-about-everything — Wed, 20 Dec 2017 10:48:18 +0000

In spite of some languages, e.g., PHP, don’t have such thing as static classes, the concept is still present there. Class consisting entirely of static methods is effectively the same thing as static class.

Besides static classes are procedural and their clients are untestable (well, there are some hacks in Java and PHP, but I don’t even want to mention them), they have couple of more issues.

Classes tend to be big to huge

Since classes with static methods have nothing to do with objects, they don’t know who they are, what they should do and what they should not do. The boundaries are blurred, so we just write one instruction after another. It’s hard to stop until we’re done with our task. It is inevitably imperative and non-OOP process.

Dependencies are hidden

Code is way less readable. What’s in the class? Database query, some intense calculations, email sending? You just don’t control how many of them are in the class. One static method here, one there — and here it is, our new God object. And when you realize that, it’s already too late.

Low cohesion

Hence the class is getting less and less cohesive. If the class has a lot of dependencies, chances are that it does more than it should. For the sake of justice I should say that the possible reason of large number of dependencies is that they are at lower abstraction levels. So composing dependencies in higher-level abstractions could be the way to go.

Tight coupling

Static methods mean that they can be called from anywhere. They can be called from a lot of contexts. They have a lot of clients. So if one class needs some little special behavior to be implemented in static method, you need to make sure that none of the other clients got broken. So such reuse simply doesn’t work. I can compare it with noble (and failed) attempt to compose and reuse microservices. The resulting classes are too generic and completely unmaintainable. This results in the whole system being tightly coupled.

Example

As an example let’s consider client’s financial balance (taken from Payment Service Provider example). It has all mentioned drawbacks and looks like this:

class FinancialBalanceUtils
{
    static public function reserveBalance()
    {
        if (!self::shouldReserve()) {
            return;
        }
        self::assertAllConditionsAreMet();
        self::queryFinancialBalanceForCurrentClient();
        $result = self::checkFinancialBalance();
        if (!$result) {
            return false;
        }
        self::reserveFinancialBalanceForCurrentClient();
    }
}

So, let’s inspect it from the beginning.

We are not sure where it is called from as it can be called from absolutely anywhere. So we need to make sure that this method really should be executed, hence shouldReserve() method.
We are not sure where it is called from, once again! Are all preconditions satisfied? No one knows, so we absolutely must verify this —assertAllConditionsAreMet() method.
Then we get financial balance by tons of parameters from database with queryFinancialBalanceForCurrentClient() method, as the query and database table serve the needs of every client who needs financial balance.
OK, we are still not sure if the financial balance we got is fine. We need to check what’s in there — checkFinancialBalance().
Aaand finally we really do reserve the balance with reserveFinancialBalanceForCurrentClient().

I omitted logging, error handling and minor code quirks and kept only the essentials. And it’s already too big.
This class is a hidden dependency itself, and it consists of hidden dependencies. How much database queries are executed in this method? I don’t know.
Do you still have any doubts that this class does more than it should?
Was it worth it to allegedly avoid copy-paste which resulted in completely unmaintainable, super-generic code that is really scary to edit?

Try OOP instead

Identify your objects. Focus on “what”, not “how”. Focus on objects, not procedures.
When objects are identified, make all your dependencies explicit first, and limit their number. Limit it to five per method. Why five? I don’t know, it just sounds reasonable. Six feels too much already. When there are more than five probably your class wants to do more than it should. Or, probably, the abstraction level of those dependencies is too low. Anyway, explicit dependencies give you a chance to make your design more solid.
Don’t generalize too early, remember the Rule of Three. First implement only some specific scenarios.

Here is a cross-posted version from my medium post.

Implementation Inheritance Is Evil

wrong-about-everything — Sun, 17 Dec 2017 12:44:35 +0000

A lot has been said about why inheritance is bad. I’ll share my take on this subject and show that inheritance is not really needed most of the time.

Structural inheritance

It breaks encapsulation

Inheritance for the sake of properties reuse is not the way that was meant by inheritance in OOP, since the early days of Simula and Smalltalk. Such inheritance approach breaks the human metaphor. Nobody should have an access to my internals: stomach, brain, or lungs. It breaks object’s encapsulation, its fundamental feature. It breaks OOP.

It is fragile

Behavior and internal structure are orthogonal concepts. They change independently. If some object extends internal structure of another one today, it doesn’t mean things will stay the same tomorrow.

It is procedural

Inheritance based on internal structure inevitably promotes procedural outlook. Good objects just have no chance to survive in such an ill environment. They become nothing but a data structures.
My personal experience with huge hierarchies reflects exactly this point. One of the projects I was engaged to had a huge amount of classes representing each request that the application could handle. The terrible thing was that those classes were full of business-logic. Since there were no real objects, reflecting domain, business-logic in those request-classes was more like procedures operating upon some data. And since that inheritance was motivated solely by request-fields reuse, it was very unnatural and unmaintainable.

It often feels artificial

Entities resulted from applying inheritance in this procedural sense always seem artificial. They rarely reflect ubiquitous language, if ever. The reason is that any domain has natural seams, marking off different responsibilities, behaviors — it is exactly what makes one object different from another. Objects internal data inherently can not be used to distinguish objects — just because it is internal.

Behavioral inheritance

Inheritance for the sake of behavioral extension is the way to go. It’s like biology species taxonomy. It was built relying upon some mutual traits that all of that species share. For example, all mammals are vertebrates, endothermic and produce milk to feed their babies. Primate is a kind of mammal, but have well developed hands and feet, with fingers and toes. Humans are a kind of primate, but we have the ability to self-reflect.

This is a metaphor used in object thinking and it has an interesting consequence. It implies that concrete classes can not be inherited. Keeping in mind biological taxonomy metaphor, there are no concrete mammal instances. There are no concrete primates. There are cats, dogs, humans. The real entities are the leafs of the hierarchy. All the rest is an abstract classes or interfaces. Hence what I’m in favor of is way closer to the concept of subtyping, not inheritance.

Inheritance is rare

Say we have a Merchant entity. It can be approved and expired. Typical approach is to make a “status” property. But very soon we realize that behavior differs a lot. Approved merchant can do pretty much anything that our system allows, unlike an expired one. Hence we come up with two separate classes — one for an approved merchant and one for an expired merchant. The first impel would be to make a base merchant class with all the internal data that they share — name, address, etc. But, firstly, as I wrote at the beginning, this is wrong motive, and secondly, none of object internal data has to be modeled (and often isn’t) as object’s properties. So this inheritance is wrong in both ways.

Following behavioral object decomposition approach, it turns out that inheritance is not necessary in most of the time. Things that we used to consider to be related very closely — approved merchant and expired merchant, both being merchants — in reality do not share any behavior, so do not have mutual parent.

Inheritance hierarchies are small

So following this decomposition approach there would not be huge inheritance cascades unless we design biology taxonomy. The number of decorators, on the contrary, is big.

It’s all about decomposing your domain. When done right, it comes out naturally. It’s far from being easy though.

Wrapping it up

So do not extend concrete classes—only abstract. Decompose your problem space first, this results in small and rare inheritance hierarchies, with plenty of decorators.

This is a cross-posted version of this original post.