Hacker News new | comments | show | ask | jobs | submit login

You make an extremely significant qualification here:

If you actually are working with real-world things

A lot of computation involves abstractions that don't correspond to real world things. Modeling techniques aren't nearly as applicable in cases when there's nothing objective (like a chemical system) or semi-objective (like a business process) to model.

Freud said sometimes a cigar is only a cigar. Well, sometimes a function is only a function.

I worked for years on OO projects and slowly came to realize that many complex object models act like a straitjacket. They're highly coupled and thus difficult to change. This of course is the exact opposite of the benefit most often claimed for OO. It's one of the oddities of the software world that people repeat for a very long time assumptions that their own experience is contradicting. Once you've accepted a language or a paradigm as a way of thinking, you frame all problems in terms of it and you just don't see its weaknesses even when they're directly affecting you. OO was oversold way beyond its roots in simulation, partly because of the irrational economics of the software industry, and a lot of people were trained not to think about programming from any other point of view.

When a partner and I began working in Common Lisp we made a conscious effort not to take the approach we were accustomed to. For example, we didn't begin by asking "What are our objects?" We simply let ourselves follow the path of least resistance, programming incrementally in a functional style. I fully expected to end up with an object model but that never happened: we just had a lot of orthogonal functions that were easily organized in a modular fashion. Subsequent experience has borne this out, and in fact most times I have defined object models in CLOS, I've regretted it. (Generic functions are a different story.)

I'm not claiming OO isn't useful, which would be absurd as people mean different things by OO anyway. But I am sympathetic to Paul Graham's statements about objects (and also about design patterns being human compilers) because I was becoming aware of these aspects of my own experience by the time I encountered them.




Yes, I only think you can even talk about a domain model if there actually is some kind of world (real or imaginary) or some collection of entities to model.


By the way, do you know the book Domain-Driven Design? I think it is the most sophisticated book on OO and domain modeling. But I also think that it's straining beyond OO toward a design style that is not really about object models, but rather about how to create a good language for talking about one's problem. (The application then reduces to a series of statements in that language.) Lisp programmers would be comfortable with this distinction. In the book it's obscured by the fact that the examples are in Java.


This is a good point. When you're building a model of X, your design is guided by asking questions about X and getting consistent answers to them. This works if X exists separately from the model and is stable and coherent. But when these assumptions don't hold, the same techniques can easily produce a design that is arbitrary and complicated.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: