OOP Icon

OOP

Object-oriented Programming
5 Stories
All Topics

Yegor Bugayenko yegor256.com

Builders and manipulators

Yego Bugayenko: 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...

read more...

Bash github.com

A standard library and boilerplate framework for writing tools using Bash

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. 👍

read more...

Mihai A amihaiemil.com

Logic should hide in plain sight

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.

read more...

Mihai A amihaiemil.com

Dolls and maquettes (a metaphor about why model objects are evil)

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.

read more...

Yegor Bugayenko yegor256.com

Fluent interfaces are bad for maintainability

Yegor Bugayenko: 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. 👌

read more...
0:00 / 0:00