It's a showcase, research, and example project on the cross section of event-based systems and using hexagonal/clean architecture in Rust.
It is a description of my general approach to building application/services, so I can share it and receive feedback, possibly improving how I do things.
I often receive feedback to my general OOP critique from people somewhat sympathetic to my message suggesting that since OOP is vague and not precisely defined, it would be more productive to talk about its core tenets/features in separation and drop the “OOP” name altogether.
I've also received an email (hi Martin!) asking among other things on my opinion about usage of interfaces in OOP. So instead of writing a private response, I'm just going to dwell a bit more on it in a blog post.
BTW. I'm continuing to read #oop#books to gather more insight and arguments. Currently, I am going through Object-Oriented Software Construction by Bertrand Meyer. The book is huge and presents the case for OOP in-depth, which is perfectly fulfilling my needs. And on top of it – it's old, so it gives me a lot of insight on “what were they thinking?!” ;). Hopefully, I'll get to a post about it in the not-too-distant future, but I will be referring to it already in this post.
Edit: I received a lot of feedback that this post is a rant. It's probably true. The primary reason is because of frustration. I have been engaging online looking for books and example of code presenting “Good OOP” for studying and refining my views. The previous book I was recommended and read: Growing Object Oriented Software, was a blast. This book was recommended frequently, even more than the previous one, so I reluctantly bought it and then got rather upset about how big of a disappointment it was. It's a book about small scope code refactoring, not really OOP, so it's not even on the point. And even at learning to refactor, I think it uses confusing and counterproductive examples all the way. I read it, I didn't like it, I wrote a short rant why exactly, to get it off my list. If you don't enjoy rants, hit Ctrl+W now.
When asking around “Good OOP” examples a lot of people recommend 99 bottles of OOP book. I was reluctant to buy it. By the name and the description, I could tell that it is going to use the “99 Bottles of Beer” song as an example of some sort... which frankly seemed completely unproductive. But since people keep on mentioning it – I got it. And unsurprisingly, I was right: the book indeed is confusing and just... not good.
TL;DR: Even as a vocal critic of OOP, I can see that this book is doing a huge disservice to anything that could be called a reasonable OOP. Save yourself $40 and don't buy it. If you own it, throw it in the trash. If you've read it – know that you learned a bunch of nonsense about OOP, and maybe some minor stuff about structuring your code and writing tests.
TL;DR: I review Growing Object-Oriented Software, Guided By Tests and contrast it with my personal approach to developing software, explaining my reasoning, and making some comments on the book, OOP and software engineering in general.
Have you ever noticed that Jira (and most if not all) SWE work tracking systems allow assigning only one person to a given task? The whole industry (at least where I've seen it) runs around the assumption that at the bottom “one task == one person”.
The more I think about it through the years, the more confident I am that it's a very unproductive thing to do, and we should default to two people working at the same time on a given task. In complex domains, sometimes potentially even three.
Anytime there's a thread about Bitcoin on HN or elsewhere and people start talking about money, Bitcoin, crypto, economic and such, it becomes pretty clear that pretty much no one there has any clue what they are talking about.
One talking point that irritates me most in these discussions is that both sides (pro and anti crypto) are wrong about “why does fiat money have some / does not have any value”. The pro-crypto side says “fiat money has no value / is not backed by anything” and the anti-crypto side says “fiat money is backed by the fact that you have to pay taxes with it / government has guns”.
Both statements are nonsense. The simple truth is: modern “fiat money” is backed by the loans created when it was created.
One problem that I have when discussing OOP is the “no true Scotsman” fallacy. Whatever criticism one has against OOP can be always rejected with “that's not a real/good OOP”.
So here is the dare – send me links to public Open Source projects that you think are an example of superb and excellent OOP code. It doesn't have to be fancy, but it has to be a real project doing something useful end to end: not a library or a framework. You can find the mail link at the bottom. I did some Google searches looking for similar questions (and answers) and I haven't really found anything useful.
Please share this post if you're also interested.
My plan is to collect some projects, pick up handful that I find best, and then apply common OOP criticism to a concrete code that other people find the best in class.
I will make sure to edit this post and add them below.
I was just recently mulling over how interfaces (Java-style) for data types are pretty much always the wrong thing to do.
Putting an interface means losing a resolution on something. Now you have to talk to it through a generic approximation. The benefit of that – you can now talk to anything that implements that interface, which means an open set. Anyone can come and add a new thing that implements that interface and it will work, without changing a line of code. Drawbacks: All the additional information about that thing is lost, and you have to come up with that interface which is not a trivial task. As the business logic changes, such interfaces often need to be revised. And as any abstraction and indirection – it introduces some confusion and mental tax.
In a typical business setting, data shape type is almost always a closed set. Even if you have N versions of some you want to support, you don't expect random external developers to add more, without altering the broader code around it. The closed set of allowed formats can just be expanded, new cases handled and the job is done. And business logic is never as simple as we would like and very often requires conditional handling, which is just painful to express via interfaces. A “switch statement” is more flexible and can do whatever without bothering with defining a contract between the data and the code using it.
While there are exceptions and it is all context-dependent, as a rule of thumb, avoid stuffing your data with interfaces, and use sum types.