Growing object-oriented software vs. what I would do
1–10 of 99 posts
Re: Growing object-oriented software vs. what I would do
#2> I've quickly realized that the authors have a concrete idea of what an object means to them. I was confused why their code was always so... “callback-y” and after studying it a little more, I've discovered the reason. I might have missed it, but I don't think they ever explicitly state it. All calls between objects are unidirectional: no public method of an actual object (not a plain data class) returns any value. They are always void methods. Objects don't “call” each other. They send a message and don't wait for a response. (Well, actually since they actually “send” it via method call, they do wait, but they pretend they don't.
https://en.wikipedia.org/wiki/Command–query_separation
https://martinfowler.com/bliki/CQRS.html
That sounds very much like Command-query separation or Command Query Responsibility Segregation to me. I haven't read this particular book (and almost certainly won't be getting to it within the next decade based on my ever increasing pile of unread books), but I wonder if they call this out. It's a critical decision in the architecture/design of a piece of software and it's worth stating that it's how they intend to design the system.
Coincidentally, to my mind, that model (CQS/CQRS) fits well with the blog author's idea of using an agent-based event system. Moving the objects into distinct threads of execution or processes, which also coincides with one of the intended ideas of OO by Alan Kay. OO-as-message-passing very much fits within the agent-based execution model.
Re: Growing object-oriented software vs. what I would do
#3To the author: if you haven't read POODR, I highly recommend that. It's the book that felt the most "real OOP" to me. No `class Dog extends Animal` in sight. It's written by one of those Smalltalkers, and I think it's got a lot of very valuable ideas about software design, not just OOP specifically.
The "callback-y" approach in Growing Object-Oriented Software sounds fascinating.
> Immediately I remind myself that the implementation from the book ignores the problem of persistence completely. If you close that application it loses all the state. I think this is not an accident. This is where things go wrong for OOP really fast.
This is a really good point.
EDIT: I see you really did not like 99 Bottles of OOP, which is by the author of POODR. In that case maybe her way of explaining things doesn't agree with you and you should skip it!
Re: Growing object-oriented software vs. what I would do
#4To the author: if you haven't read POODR, I highly recommend that. It's the book that felt the most "real OOP" to me. No `class Dog extends Animal` in sight. It's written by one of those Smalltalkers, and I think it's got a lot of very valuable ideas about software design, not just OOP specifically. The "callback-y" approach in Growing Object-Oriented Software sounds fascinating. > Immediately I remind myself that th…
POODR = Practical Object-Oriented Design in Ruby by Sandi Metz.
Re: Growing object-oriented software vs. what I would do
#5This is a hot take but: I have a growing sense that one defining feature of some software engineers is that they’re embarrassed by dense logic. I think you see this in the Java world where people seem to hide the core logic of their program amidst a dizzying array of interfaces and deep function call chains. Maybe with enough DI and whatnot, the business logic itself can melt into the structure of the program.
In comparison, C programs tend not to hide this stuff. C functions are often long and complex. If you were implementing quicksort in C, you would write (more or less) one function with all the logic packed in there you can just read top to bottom. In Java it would be a nest of SortComparator interfaces and SortAlgorithm implementors, which would act to hide the algorithm itself.
There’s something more honest about the C style. It’s like, yeah, the algorithm is complicated. So we put it all together in one dense function. Here it is - go nuts! You don’t have to go hunting for the right implementing class. Or divine how FooFactory has configured your Foo object instance.
All that Java style class abstraction seems to (intentionally or otherwise) make the actual logic of your program hard to find and hard to trace. It’s coy. When I’m trying to read someone’s code, that’s simply never what I want.
Re: Growing object-oriented software vs. what I would do
#6To the author: if you haven't read POODR, I highly recommend that. It's the book that felt the most "real OOP" to me. No `class Dog extends Animal` in sight. It's written by one of those Smalltalkers, and I think it's got a lot of very valuable ideas about software design, not just OOP specifically. The "callback-y" approach in Growing Object-Oriented Software sounds fascinating. > Immediately I remind myself that th…
POODR = Practical Object-Oriented Design in Ruby by Sandi Metz.
Thanks. I tend to leave it abbreviated because it's always the top Google result!
Re: Growing object-oriented software vs. what I would do
#7> I've purchased three OOP books (in the order I've read them): ...
If your gonna pick three books on OOP it should include Design Patterns at the top of the list. At least if you want to understand why OO is a thing people still use and talk about.
Re: Growing object-oriented software vs. what I would do
#8> does anyone really care?
I liked this piece. Enough to log in and comment at least. It's the rare article where the author is open about his biases but gives an opposing approach an honest go. Reading three books about OOP is way more generous than I'd ever be. And when that approach still doesn't make sense, he offers a better one. Always enjoy reading the informed hater's perspective.
Re: Growing object-oriented software vs. what I would do
#9This is a hot take but: I have a growing sense that one defining feature of some software engineers is that they’re embarrassed by dense logic. I think you see this in the Java world where people seem to hide the core logic of their program amidst a dizzying array of interfaces and deep function call chains. Maybe with enough DI and whatnot, the business logic itself can melt into the structure of the program. In com…
In A Philosophy of Software Design the author talks at length about this and proposes that "deeper" modules (classes/methods/functions etc.) provide the most cost/benefit ratio, where the interface of a module is the cost and the functionality is the benefit.
Code doesn't magically become less complex by hacking it into pieces.
Re: Growing object-oriented software vs. what I would do
#10To the author: if you haven't read POODR, I highly recommend that. It's the book that felt the most "real OOP" to me. No `class Dog extends Animal` in sight. It's written by one of those Smalltalkers, and I think it's got a lot of very valuable ideas about software design, not just OOP specifically. The "callback-y" approach in Growing Object-Oriented Software sounds fascinating. > Immediately I remind myself that th…
[deleted]