Hacker News Reader

Comment by simplotek | Hacker News Reader

> The wrong abstractions can lead to coupling and complexity.

This comes to the old quote:

* "Make everything as simple as possible, but not simpler.” Albert Einstein.

Abstractions undoubtedly add complexity that quickly becomes unmanageable. By now everyone is already aware of the horror that's the enterprise version of Hello World, and YAGNI/gold plating are renowned antipatterns. Many codebases have already succumbed to the perils of premature generalization, where the good old rule of 3 of refactoring serves as a shield against it.

But still some developers succumb to the siren song of abstracting away things.

View on HN

Okay, let's take an excerpt from one of those enterprise "hello world"s:

    IHelloWorldString helloWorldString = helloWorld.getHelloWorld();
    IPrintStrategy printStrategy = helloWorld.getPrintStrategy();
    IStatusCode code = helloWorld.print(printStrategy, helloWorldString);

Extracting two subobjects from an object to feed them back to the same very object is not an abstraction, it's merely adding a bunch of public methods (and interfaces) to the object. That may or may not help in abstracting things: and usually, the more handles and bells and whistles are available to pull and play with, the less abstracted the code actually is.

> it's merely adding a bunch of public methods (and interfaces)

What do the interfaces represent?

In this case, nothing particularly meaningful or useful, they mostly just shrink wrap the underlying (single) implementation's details and re-expose them as-is for the caller to cope with. Some people also think that that somehow helps with encapsulation too.

> In this case, nothing particularly meaningful or useful

You're either playing dumb or weren't able to understand what was in the code. IHelloWorldString is an abstraction over the way the string was implemented, IPrintStrategy is a strategy pattern that abstracts away how the abstract hello world string is supposed to be printed, and finally IStatusCode is an abstraction over how a status code is implemented.

> they mostly just shrink wrap the underlying (single) implementation's details and re-expose them as-is for the caller to cope with.

No, not really. Their purpose is to abstract away implementations. Just because there's a single implementation that does not mean this wasn't abstracted away.

There's using "abstraction" in the classical sense of "harder to understand", as in "abstract painting". In today's world, good abstractions are the exception.

> it's merely adding a bunch of public methods (and interfaces) to the object

The object is the abstraction they're complaining about. Why have an object to begin with?

How is gold plating the same as YAGNI? They're opposites, no?

> How is gold plating the same as YAGNI? They're opposites, no?

No, gold plating and YAGNI are two faces of the same abstraction coin.

Under-engineering is not the same thing as YAGNI.

I worked at a place where the former employee had engineered his whole S3 to files synchroniztion layer. We never needed that. That's YAGNI. (And if we did, the library already has it!)

Choosing crappy overly-simple ideas for abstraction is not what YAGNI is all about. It's about pulling in overhead+complexity when it's justified, and only then.

Reply on news.ycombinator.com