The objects are just one tool. You usually need a few to do the job well.<p>The biggest thing I've seen blow up actual OOP projects has been a lack of respect for circular dependencies in the underlying domain. If you have one of those problems where it is ambiguous which type "owns" another type, then the moment you start writing methods in these types you are treading into the dark forest. Often times it is unclear that your problem exhibits circular dependencies until code is already being written and shipped.<p>My approach to these situations is to <i>start</i> with a relational data model. A SQL schema (and its representative DTOs) can model circular dependencies competently. You can then have additional object models (views) that can be populated by the same relational data store (just a different query). One other advantage with the relational modeling approach is that it is very easy to explain things to the business <i>before you write a single line of code</i> [0]. The purpose of a SQL table can be demonstrated with a sample excel sheet with mock business data.<p>This path was largely inspired by Out of the Tar Pit [1] and practical experience in fairly wicked domains (semiconductor mfg., banking, etc). I am not sure <i>Functional</i> Relational Programming is the answer for everything, but the "Relational" part certainly seems to be universally applicable.<p>[0]: <a href="https://en.wikiquote.org/wiki/Fred_Brooks#:~:text=Show%20me%20your%20flowcharts%20and,%3B%20they'll%20be%20obvious" rel="nofollow">https://en.wikiquote.org/wiki/Fred_Brooks#:~:text=Show%20me%...</a>.<p>[1]: <a href="https://curtclifton.net/papers/MoseleyMarks06a.pdf" rel="nofollow">https://curtclifton.net/papers/MoseleyMarks06a.pdf</a>
I want to re-read this and think about it more.<p>But one thing stuck out: I never liked most of the distillation of actions as clean architecture would advocate for, be they lambdas in class form (DepositAction) or interactors. I feel strongly that they are the right thing in describing business logic, however.<p>What did click for me is the conceit of a service, which the JVM world embraces. Services are plain old objects that have a method for each action you'd like to model. This is nicer than the aforementioned approaches because there is often common code to different actions. Like actions, services are the place where validation happens, persistence happens, and all of the interesting business logic. IO and orthogonal concerns are injected into them (via constructor), which lets you write tests about the core logic pretty easily.<p>What you get is the ability to reason about what happens without the incidental complexity of the web. Web handlers then boil down to decoding input, passing it to the service, examining the result of calling an action, and then outputting the appropriate data.<p>That's all they should've ever been doing. :)
<i>> An object has state and operations combined.</i><p>My own definition has always been that an object has state and <i>identity</i>.<p>I have never considered functions/methods to be a requirement for something to be an object.
+1 for use of the word "Reification"!<p>There's another universe of object-adjacent systems that may or may not be connected with conventional OO programming languages. Two examples I'd point to are Microsoft's COM (designed so it is straightforward to write and call COM objects from C) and the "objects" in IBM's OS/400. In both of those cases I think the reification is the important thing, although you can see reification in Java's object headers where objects get a number of attributes necessary for garbage collection, concurrency control, etc.
> Smalltalk was one of the first Object-Oriented Programming Languages out there. It's where ideas like inheritance and message-passing came from (or at least where they got popular, from what I understand);<p>It may be worth pointing out that while Smalltalk is arguably one of the key languages that popularized such ideas and other OOP concepts, these were first introduced by Simula 67.
I enjoyed this post a lot. I happened to blog about the same thing from the FP side of things [1] (well, because Closures are just the poor man's Objects).<p>Generally, I don't know how to (philosophically) navigate the tensions between Functional / Object Oriented / Imperative / Declarative paradigms, except to remind myself about <i>The Thing That Actually Matters</i> (in my estimation)... to always remember that The State is the frenemy.<p><i>For the love of State is the root of all evil: which while some coveted after, they have erred from Lambda the Ultimate, and pierced themselves through with many sorrows.</i> --- Yours Truly.<p>:)<p>[1] <a href="https://www.evalapply.org/posts/what-makes-functional-programming-systems-functional/index.html" rel="nofollow">https://www.evalapply.org/posts/what-makes-functional-progra...</a><p>(edit: forgot to link to blog post)
I never liked „OOPs world“ obsession with a receiver. Why the hell receiver of a message gets to dispatch the implementation at very late moment? Why not context? And when there are many receivers? I.e. a composite object of an int and a float receive message „add“ - who decides which implementation to use and why the heck any of them may even know how to add self to another? There were many attempts to solve this and all were horrible (i.e. extension methods). I have been experimenting with these concepts too (i.e. a receiverless message is a throw, which will be picked up by an enclosing effect handler via pattern match), but its all unreadable and unmaintainble mess. Anyone doing the same thing? I would love to exchange thoughts :) extras to read: ian piumarta‘s papers on his OOP system and a paper on Korz programming language
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.<p>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.”<p>Jim Weirich hints at this perfectly in his approach to solving the Coffee Maker [0]. I’ll quote the punch line for everyone:<p>> 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.<p>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.<p>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.<p>[0] <a href="http://www.cs.unibo.it/cianca/wwwpages/ids/esempi/coffee.pdf" rel="nofollow">http://www.cs.unibo.it/cianca/wwwpages/ids/esempi/coffee.pdf</a>
What works for me:<p>There are two types of objects: State objects and Tool objects.<p>The purpose of a State object is to maintain a state. Think strings, databases, files etc.<p>The purpose of a Tool object is to operate on State objects. Think loaders, printers, editors, transformers etc.<p>It’s a simple way to organise OO code. And it works. At very large scale (millions of lines of C++).<p>It is similar to the functional Data/Function thinking. However it actually works better because State objects can enforce constraints, and Tool objects can cleanly maintain an internal temporary state while operating on State objects.
Objects are just the poor man's actors. If you want to see what encompasses objects and more, look up the actor model.<p>That's what I thought this article is going to talk about but not even a honorary mention.