4 ms·

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 unh

by curtis 17y ago

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.

iron_ball 17y ago
That comment put this into perspective and gave me a light bulb. Thanks!
diN0bot 17y ago
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.
arakyd 17y ago
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.
- curtis 17y ago
  I think you're right that there's a serious problem with how OOP is described. Why that's so is a full topic in and of itself. In the case of Alan Kay, I can't help but feel like he was trying to create one thing but actually created another.
  - jamesbritt 17y ago
    "Smalltalk is object-oriented, but it should have been message oriented." -- Alan Kay http://folklore.org/StoryView.py?project=Macintosh&story=Creative_Think.txt http://folklore.org/StoryView.py?project=Macintosh&story...
jamongkad 17y ago
Could you please provide an example for this?
- raganwald 17y ago
  A pool of database connections is a collection of objects in the solution domain. A "customer" is an object in the problem domain.
  - Kaizyn 17y ago
    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?
  - jamongkad 17y ago
    Thank you! but it's still not very clear to me. I'm having trouble trying to visualize how this should play out. :\
    - raganwald 17y ago
      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.
  - azanar 17y ago
    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? I am now really confused.
Kaizyn 17y ago
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.
- fauigerzigerk 17y ago
  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.
garnet7 17y ago
> 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.

by curtis 17y ago

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.

iron_ball 17y ago

That comment put this into perspective and gave me a light bulb. Thanks!

diN0bot 17y ago

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.

arakyd 17y ago

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.

curtis 17y ago
I think you're right that there's a serious problem with how OOP is described. Why that's so is a full topic in and of itself. In the case of Alan Kay, I can't help but feel like he was trying to create one thing but actually created another.
- jamesbritt 17y ago
  "Smalltalk is object-oriented, but it should have been message oriented." -- Alan Kay http://folklore.org/StoryView.py?project=Macintosh&story=Creative_Think.txt http://folklore.org/StoryView.py?project=Macintosh&story...

jamongkad 17y ago

Could you please provide an example for this?

raganwald 17y ago
A pool of database connections is a collection of objects in the solution domain. A "customer" is an object in the problem domain.
- Kaizyn 17y ago
  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?
- jamongkad 17y ago
  Thank you! but it's still not very clear to me. I'm having trouble trying to visualize how this should play out. :\
  - raganwald 17y ago
    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.
- azanar 17y ago
  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? I am now really confused.

Kaizyn 17y ago

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.

fauigerzigerk 17y ago
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.

garnet7 17y ago

> 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.