Being poor at modeling is essential to OOP (comment on LtU)

http://lambda-the-ultimate.org/node/3265#comment-48063

by blasdel • 17 years ago

67 22 17 years ago

One word: Awesome.

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.

curtis2• 17 years 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• 17 years ago

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

diN0bot• 17 years 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• 17 years 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.

curtis2• 17 years 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.

jamongkad3• 17 years ago

Could you please provide an example for this?

raganwald2• 17 years ago

A pool of database connections is a collection of objects in the solution domain. A "customer" is an object in the problem domain.

Kaizyn2• 17 years 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• 17 years 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• 17 years 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.

jrockway• 17 years ago

Wow, looks like Programming Reddit found LtU. Sad.

ulvund• 17 years ago

464 times

http://www.reddit.com/domain/lambda-the-ultimate.org/top/

wwalker32• 17 years ago

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?

anamax• 17 years ago

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

wwalker32• 17 years ago

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.

Being poor at modeling is essential to OOP (comment on LtU)

Related Stories