A conversation with Ronna Steinberg, who was an OOP developer for many years, and now is a Go Google Developer Expert. Ronna has been thinking about Go and OOP for awhile, asking herself whether or not Go is an object oriented programming language. Tune in to find out her answer and hear some of the options gophers have for object oriented design.

I almost brought up the Law of Demeter on Go Time a couple weeks back:

That being said, sometimes you just have to follow the other person’s path until you realize when it doesn’t actually work for you. I’m totally fine with cargo-culting some sort of rule… I was gonna say the Law of Demeter, but that one’s too hard to explain. What’s a very simple – DRY, right?

See how quickly I abandoned ship there? Ok, it’s not that hard to explain. I just didn’t feel like taking the time to explain it when it wasn’t even my point. Good thing Double Agent Caleb Hearth did a nice write-up on Test Double’s blog about it!

Andrzej Krzywda:

My goal is to help you improve the design of the if/else based codebases. Yes, that probably means creating new method, extracting new object. It might be a bit OOP. If that’s not your taste and you’re fine with if/else then this may not be for you.

He then goes on to refactor a deeply nested Ruby method by extracting some classes that are responsible for their own behavior. This is perhaps a bit rudimentary to long-time OOP folks, but I see a lot of code out there looking like Andrzej’s example method so there’s plenty of people who would benefit from understanding this concept.

This is a written summary of Katerina Trajchevska’s Laracon 2019 talk on SOLID. Tosho Trajanov says it is a “must-read for every software engineer.” Here’s a primer on the primer:

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

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…

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.

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