The thing about OOP is that you need your objects to belong to your solution domain, not your problem domain. If you get this backwards, you will likely be unhappy.
The thing about OOP is that it is described as way to make programming easier because objects are so "intuitive," and the examples for this are all toy simulations with naive object "models." What the post describes, and what everyone who actually does a significant amount of OOP programming eventually figures out, is that the only things OOP makes intuitive are stupid approaches. It's possible to program well in OOP languages, but there's nothing intuitive about doing anything non-trivial well, in any language.
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.
Most problem domains (or shall I more appropriately call them business domains?) have a small number of key abstractions that are crucial to understanding the domain. Coupling these abstractions with the right relationships between them is the essence of modeling the system in which a problem occurs and a solution is desirable. The key abstractions are going to be the same more or less irrespective of what your specific system in that problem domain will try to do.
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.
Of course the concepts of the problem domain will somehow be present in your solution design. But many OO designs try to force a one to one mapping, which doesn't work well in my experience.
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.
> The thing about OOP is that you need your objects to belong to your solution domain, not your problem domain.
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.
or to have both problem and solution objects with ways to compute the latter from the former.
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 may seem thick-headed for saying this, but if I were building a system to solve a problem related to the management of customers, having something representing the customers themselves would seem integral to the solution. How would I represent the customer data? Is it just stashed in some generic key-value mapped data structure? I would assume it would have to be in the system somewhere.
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?
A system certainly has to map between the objects and the language of the customer problem down into computer science and software engineering concepts, but shouldn't that be down at the lower levels of your system? Top-level architecture seems like it should employ objects that represent the main features of the business domain and the relationships between those features. If your system is modeled in terms of DB connection pools and collections, doesn't that create too large a gulf between the system's eventual users and the system GUI?
Sorry, I am not making any comment one way or the other about the OP, simply pointing out that problem domain objects model things users care about and solution domain objects model things the computer cares about.
Lambda the Ultimate discussing object-oriented programming is like backwoods Christians discussing Hinduism. "What do them folks need all them gods for anyways? An' that one Krishna, why's he look like a blue baby? Ah guess some folks'll believe anything!"
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?
> 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 apologize for any offense. I don't mean to imply that all "backwoods Christians" are really baffled by Hinduism -- I also know some of the type you mention, the serious students who learn ancient Greek.
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.
