Object-Oriented Software Engineering

What Hacker News says

1. BlackstratDec 2023
   I knew Ed back in the day. It was a lot of fun watching him interact with my programming staff, mostly C++ programmers. Trying to get them to see that objects printing themselves resulted in excess coupling. Or trying to get programmers to write things down. I still remember laughing when he told them something to the effect of “programmers shouldn’t wear illiteracy as a badge of honor”. Essays on Object Oriented Software Engineering was a good book in the early 90s.
   Show morethread
2. jdouganSep 2022
   Object-Oriented Software Engineering is the title of Jacobson's 1992 book describing a reduced tool-less version of Objectory that was referred to as OOSE. ISBN 0-201-54435-0

   To this day I still use OOSE notation when sketching a design, I alwas thought UML was a step down.

   thread
3. hgaDec 2014
   I would suspect that learning functional programming itself, after pretty much everyone gets started with imperative, could take as much effort as learning OO from the same imperative base (but of course a lot more people now start with something like Python and at least dabble with OO).

   I.e. more than an afternoon or probably a month to get good, vs. the few days it takes to learn another language with familiar paradigms.

   Not sure from personal experience because I learned functional style Lisp/Scheme really early, more than a decade before OO, which made learning Clojure a relative snap. OO in the form of C++ was harder for me, but maybe functional is just easier for my mind to wrap around. The quality of the Lisp and Scheme texts I used, especially SICP, also probably made a difference (the OO texts I used were good, but not as great, with the exception of OOSE (http://www.amazon.com/Object-Oriented-Software-Engineering-A...), but that's as much about great design of your project as well as what the project is making).

   Show morethread
4. stonethrowawayJul 2024
   I want to agree with this but it’s a surface level concern. I’m not trying to belittle the author’s point but I do want to emphasize something that isn’t talked about enough.

   Reification has two meanings in software development. Author uses one, the more familiar one - it’s discussed in many books on DDD. The other is a bit more vague and unapproachable. It’s the one I want to bring to peoples attention. It can be summed up as: “Accounts, transactions and balances are not enough.”

   Jim Weirich hints at this perfectly in his approach to solving the Coffee Maker [0]. I’ll quote the punch line for everyone:

   > Some people may be uncomfortable with the divergence of the Analysis and the Design models. Perhaps they expect that the design model will just be a refinement of the analysis. Remember that analysis is an attempt to understand the problem domain. Although we use OO tools to represent our understanding, that understanding has only an indirect influence on the structure of the software solution (in that the software must actually provide a solution). In fact, as we refine our software design, we will find that it moves even farther away from the analysis model. Solutions oriented classes, which do not appear in analysis, will be added to the design. Classes that came from the analysis model may mutate or even disappear entirely.

   This is the form of reification that I believe is more closely associated with how the term is used in classical OOD (f.e. Object Oriented Software Engineering: A Use Case Driven Approach), but I suppose people’s experiences may disagree. This is a kind of “right layer of abstraction” that has to be pontificated and not just put down as an object because it’s a process or a “thing” from the outwardly-behavioural view of the situation.

   As I mentioned, it’s not talked about enough. Jim is right to call it out: it’s uncomfortable because it’s having to dig deep into the system ontology.

   [0] http://www.cs.unibo.it/cianca/wwwpages/ids/esempi/coffee.pdf

   Show morethread
5. jameskiltonJun 2012
   It's different than the command pattern, and I didn't make up the idea or the name. The whole idea of the Interactor came straight from http://www.amazon.com/Object-Oriented-Software-Engineering-A... which Uncle Bob bases a lot of his talk on.
   thread