SOLID is an acronym formed by the names of 5 design principles centered around better code design, maintainability, and extendability.
Mihai on the value of automating as many of your project’s Quality Gates as possible.
For instance, in my projects, I have rules ranging from cosmetic matters like naming or indentation to architectural rules such as “Classes are either abstract or final” or “All variables, of any kind, should be final”.
Here is a simple principle for naming methods in OOP, which I’m trying to follow in my code: it’s a verb if it manipulates, it’s a noun if it builds. That’s it. Nothing in between. Methods like saveFile() or getTitle() don’t fit and must be renamed and refactored. Moreover, methods that “manipulate” must always return void, for example print() or save(). Let me explain.
Naming objects well has been a career-long struggle for me. I just might give this a try…
The aim of Bash Infinity is to maximize readability of bash scripts, minimize the amount of code repeat and create a central repository for a well-written, and a well-tested standard library for bash.
It seems to me that by the time you need something as fancy/full-featured as this, maybe the task at hand has outgrown Bash? Cool, nonetheless. 👍
If we get rid of the concept of “model objects”, then there should be very little (almost zero) space for procedural code/algorithms in our codebase, since each object is a component that has its well-defined place in the bigger picture.
The following question arises: where does the “business logic” go? The answer is: business logic should be visible in how objects are wrapping/composing each other, rather than being visible in a 200 LoC method of some “service” class.
A visual explanation on why model objects are not a good practice in object-oriented software.
It is explained that a developer’s job should be the one of an engineer, instead of the one of a manual worker (I would say even the one of a puppeteer, but I don’t like the rhyme); objects should be alive and have behaviour of their own rather than being mere models surrounded by tools, artificial ways of making them act as if they were alive.
Fluent interface, first coined as a term by Martin Fowler, is a very convenient way of communicating with objects in OOP. It makes their facades easier to use and understand. However, it ruins their internal design, making them more difficult to maintain. A few words were said about that by Marco Pivetta in his blog post Fluent Interfaces are Evil; now I will add my few cents.
Yegor uses his own HTTP library as an example where the interface designed is fluent (which looks nice and readable to use) and shows how that design goal made the internal code a mess. My gut tells me it’s worth the trade-off to provide a better user experience, but Yegor’s real-life experience punches me right in the gut:
Fluent interfaces are perfect for their users… However, the damage they cause to object design is the price, which is too high.
He suggests decorators and smart objects as an alternative. Lots to ponder here, and the conversation going on in the comments is lively as well. 👌