[HN Gopher] Growing object-oriented software vs. what I would do
___________________________________________________________________
Growing object-oriented software vs. what I would do
Author : vivty
Score : 30 points
Date : 2021-08-08 09:54 UTC (1 days ago)
(HTM) web link (dpc.pw)
(TXT) w3m dump (dpc.pw)
| Jtsummers wrote:
| > 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.
| crabmusket wrote:
| To 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!
| Jtsummers wrote:
| POODR = _Practical Object-Oriented Design in Ruby_ by Sandi
| Metz.
| crabmusket wrote:
| Thanks. I tend to leave it abbreviated because it's always
| the top Google result!
| josephg wrote:
| This 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.
| theteapot wrote:
| > 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. In fact just pick this one book.
| I'd be interested to read a tear down from the author of the
| article.
| jim-jim-jim wrote:
| > 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.
___________________________________________________________________
(page generated 2021-08-09 23:00 UTC)