Being poor at modeling is essential to OOP (comment on LtU)
lambda-the-ultimate.org
lambda-the-ultimate.org
problem domain objects are often part of the input and internal computation space, whereas solution objects are usually user-friendly world views. so both are helpful to think about before writing too much code.
in the financial transaction example, input and computations occur over transaction objects. however users want to navigate monthly balances. thus, there has to be a cross reference or object transformation from the highly granular transactions to monthly aggregations.
I blame Alan Kay for inventing a new paradigm and then not explaining how it was supposed to be used (it's like Lisp meets biology!), thus allowing it to be taken over by others who filled the vacuum with a multitude of their own (usually half-baked) ideas bastardized implementations, and "software architect" positions.
In the case of Alan Kay, I can't help but feel like he was trying to create one thing but actually created another.
Maybe I'm just misinterpreting what distinction is drawn between a solution and problem domain. So far, my interpretation is as follows:
* You build objects to represent the machinery involved in the computation (databases, processors, interpreters, etc). These represent your solution domain.
* Anything that explicitly represents the data being computed, rather than just being a container for data collections, is kicked to the weeds as unnecessary and wrong-headed. These would represent your problem domain.
Do I have this interpretation correct? If so, I worry.
I have seen data processors objects become near unmanageable hedges of thorns because the entire conversion from input data to output data is rolled into a GiganticBlobProcessor object. That object containing hundreds, or even thousands of lines of code that means absolutely nothing on their own. This seems prone to its own pitfalls and need for revolutionary changes.
How is this extra scaffolding a net-win? Why can't I take all this processing code, and move it into the definition of the data being translated, which is probably split amongst multiple classes to model relationships?
For instance, I have something representing a sphere within a graphical rendering system, which is capable of responding to requests for its radius, area, volume, intersection with other shapes, etc. Have I already done it wrong? Should I have just a radius primative and then have a SphereDimensionalEvaluator which does the task, being passed the radius?.
I understand the point made by the LtU commenter that TaxReport itself is probably little more than a container, since reports don't really do much in a metaphorical sense. But a customer does: it can request actions and computations from other things, and other things can ask the customer things and tell the customer to do some action. Is my thinking about things this way leading me down a very dark alley?
I am now really confused.
Now, depending on what type of system you end up wanting to build (a real-time monitoring system, a web-based reporting tool, etc.), you will end up introducing other abstractions that represent computer science/software engineering knowledge. However, these will only supplement and not replace the abstractions that are rooted in the problem domain.
In short, if you see the solution domain as distinct from the problem domain, you will run into trouble with your system design.
Conceptually, the problem domain consists of a number of "stories", each of them useful to explain one aspect of the system, but the stories are inconsistent with each other and they have to be inconsistent in order to clearly state the aspect they focus on. You could say they are denormalized views on the model. Declaring them to _be_ the model destroys their value and/or the model.
Many OO designs try to replace the model proper with one of its views, usually the one that shows what kinds of things are known. In that view it is reasonable to ignore the fact that some parts of a Customer object are loaded in every HTTP request from some cache, some parts have to remain encrypted at all times, some parts are subject to harsh regulatory requirements and have to reside on a different system (like credit card numbers), some parts need to be available for near realtime analytics whereas others are considered archived, etc.
So you may have a security view, an operational view that includes scalability, distribution and deployment, a process/workflow view that focuses on routing and approval, several different analytics and reporting views, and usually some more.
It's a bad idea to take one of those views and an promote it to _be_ the model through which all other views have to be reconstructed on demand. The model will have to be something different and creating it requires a different mindset the one that OO textbooks suggest.
Would be great if someone wrote up a nice blog post giving a concrete example of how this works out in practice. That is, come up with some reasonable example of a problem to be solved, give some ideas for objects in the solution domain, and give some examples of possible objects in the problem domain that you should not use.
More words: This sums up so much wisdom on how to do (or not do) OO. The whole thread is great, but that comment is definitely a highlight.
It just seems pointless to constantly profess such dismay and amazement at how clueless other peoples' programming paradigms are. Is there anyone who really doesn't believe there's more than one self-consistent, sensible way to write code?
The existence of multiple ways to write sensible code does not imply that every way to write code is sensible.
BTW - Do you have any significant experience with "backwoods Christians" or are you just winging it from your ignorance? (I've run into several who taught themselves Greek so they could read ancient religious texts.)
I was using the "backwoods Christian" stereotype to make a point in a (hopefully) humorous way, that people who are totally wrapped up in their own worldview often completely fail to understand the point of other worldviews, and don't even realize they're missing the point.
For what it's worth, I was raised in the back woods, and grew up around the kind of people I caricatured (who were thankfully always a minority). But since intent is hard to convey on the Internet, it would have been wiser for me to use talking animals like Aesop, or something else less likely to offend.