I don't think this blog post was researched well. It reads like a parody, in fact. It starts with a project, throws a bunch of assertions and ill founded opinions, proceeds to present a series of pessimizations, and somehow concludes the pessimizations are better?
The most charitable interpretation is that the blog post shows one of the main problems in software engineering circles: complaining about stuff they don't know and/or understand.
Take for example the leading accusation that code is overengineered by using static member functions.
> This code is over-engineered in the small. Notice that file type or mode are static per file format. They most likely do not depend on the data. We can easily eliminate virtual calls by storing this info as class members.
I don't think the blogger thought this approach all the way through, as it's not free from tradeoffs. In fact, the blogger explained some traits but somehow failed to arrive at the obvious conclusion. For example, file type and file mode are a type trait, not a instance trait. By replacing static files with a combination of getters and supporting member variables, it introduces two member variables. The blogger introduces these member variables at the base class level, which means each and every instance of every derived class has to store data used by two read-only getters that specify a type trait. This is data that needs to be saved in memory, and copied and moved around. Virtual function calls are somehow a problem and represent overengineering, but needlessly copying data around isn't? Baffling.
But there's more. Virtual function calls are somehow a problem, but as a solution the blogger asserts that replacing all member functions with a single function that copies around a large struct instance bundling all attributes... That's somehow good? The blogger also throws away any semblance of encapsulation to return instead a POCO. Why? At this point I really don't know.
The blog post reads like an exercise in absurdity. I wonder if the blogger writes software for a living.
motorest•2h ago
The most charitable interpretation is that the blog post shows one of the main problems in software engineering circles: complaining about stuff they don't know and/or understand.
Take for example the leading accusation that code is overengineered by using static member functions.
> This code is over-engineered in the small. Notice that file type or mode are static per file format. They most likely do not depend on the data. We can easily eliminate virtual calls by storing this info as class members.
I don't think the blogger thought this approach all the way through, as it's not free from tradeoffs. In fact, the blogger explained some traits but somehow failed to arrive at the obvious conclusion. For example, file type and file mode are a type trait, not a instance trait. By replacing static files with a combination of getters and supporting member variables, it introduces two member variables. The blogger introduces these member variables at the base class level, which means each and every instance of every derived class has to store data used by two read-only getters that specify a type trait. This is data that needs to be saved in memory, and copied and moved around. Virtual function calls are somehow a problem and represent overengineering, but needlessly copying data around isn't? Baffling.
But there's more. Virtual function calls are somehow a problem, but as a solution the blogger asserts that replacing all member functions with a single function that copies around a large struct instance bundling all attributes... That's somehow good? The blogger also throws away any semblance of encapsulation to return instead a POCO. Why? At this point I really don't know.
The blog post reads like an exercise in absurdity. I wonder if the blogger writes software for a living.