Take the 2-minute tour ×

When I try to design an OO solution ,I generally use the CRC modelling wherein I list the class names (nouns), what they do(verbs) and how they collaborate with other classes.

This blog has the below thing to say about this noun-verb approach

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

My question is, does a better modelling technique exist to use OO approach?

share|improve this question
Assuming that the $$$ bid makes sense, just start coding. When stuck, find a way to remove obstacle(s). Re-factor later. "CRC" is not something I have heard of before now, but that did not stop me from writing classes. If there was a great mechanical principle out there, someone would have made a good code analysis tool using it and it would be popular. Until I find such thing, I will continue using my intuition. Of course, one has to use verbs and nouns at the right places ... –  Job Jul 4 '11 at 1:38
Yeesh. Just get a quick mental model of the system and start writing code. I know many will disagree with me here, but you can overanalyze this stuff to death. As long as you have a decent amount of experience you shoul dhave a clue as to what will and will not work. If something proves to be difficult to work with early on then change it, and now you have even more experience. –  Ed S. Jul 4 '11 at 4:15
add comment

3 Answers

In fairness, he did add "In fun" to that claim.

To this day, I do tend to start by modeling systems using the "noun and verb" approach, but I have found over the years that TDD teaches us that this approach draws your focus to the wrong thing. In this sense, the blogger has a point. However, I'm not sure that it is the approach at fault, rather than the way our minds work.

If you want to try a little challenge here, stop reading and go try to model the Monopoly game, using the English language, then come back here.

I suspect the temptation will be to immediately look at the objects that we interact with a lot - the board, the spaces, the cards, the dice, the pieces - but that is not where the bulk of the logic goes. Most of these objects are entirely dumb. Data, if you will.

But as soon as you start to write tests, you realise which object is by far the most important in any game: the rules.

Remember that little piece of paper that you read once when you first got the game and don't interact with again until there is a dispute? The computerised version does not operate that way. Every single thing the player tries to do, a computer will consult the rules and see if they're allowed to do it or not.

When you think about it, you do the same thing but because it takes time to read the paper-based rules and your brain has a reasonable caching system, you consult the rules in your head. A computer is probably going to find it as easy to read the rules again - unless they're stored in the database, in which case it might cache them too.

And this is why TDD is so popular for actually driving design. Because it tends to drive your thought process quickly to the right places:

When I think that I'm going to write some tests for my Monopoly game. I might look at my set and try to find the objects. So, we've got these pieces. I'll write some tests for those.

Maybe I'll have a base class MonopolyPiece and each type of piece will derive from those. I'll start with the DogPiece. First test... ahh. Actually, there is no logic here. Yes, each piece will be drawn differently, so I might need a DogDrawer, but while I'm fleshing out the game, I just want to write "D" on the screen. I'll spice up the UI at the end.

Let's find some actual logic to test. There are a lot of these houses and hotels, but they don't need tests. Money, no. Property cards, no. And so on. Even the board is nothing but a state machine, it doesn't contain any logic.

You'll quickly find you have three things left in your hand. The Chance and Community Chest cards, a pair of dice and a set of rules. These will be the important parts to design and test.

Did you see that coming when you wrote out the nouns and verbs?

There is, in fact, a great example in Robert Martin's Agile Principles Patterns and Practices where they try to flesh out a Bowling Score Card app using TDD and find all sorts of things they thought were obvious classes just weren't worth bothering with.

share|improve this answer
Can't understand why TDD is an answer to making OO analysis the OP is asking about. Noun/verb is the very first approximation of the problem domain (most useful for beginners), and of course refining classes can be done later, but the claim TDD directs design in the right direction is IMHO plain wrong (do you really suggest skip planning, design and start coding?!). The Monopoly example is also misleading, depending on what part of the system you are working on: UI or core logic. On UI side dices and whatnot make perfect sense. –  Roman Susi Oct 4 '13 at 13:23
+1 & favoriteized. First, my experience is that TDD does drive your thought process quickly to the right places (Well, you might argue about "quickly" sometimes). And it can help reveal design defects early too: You'll learn dependency injection if nothing else! Noun-Verb - who doesn't start here? But Most of these objects are entirely dumb. Data, if you will is profound. The title of a seminal book says it all for me Algorithms + Data Structures = Programs –  radarbob Oct 5 '13 at 21:14
add comment

I've never found such methods helpful for me. In fact I found that using them just confuses me worse. Check out Robert C. Martin's Coffee Maker, I don't think he uses this kind of approach either.

One thing that bothers me right off is the solution that the person comes to in the CRC article you link to. The Customer/Order collaboration is not something I'd consider worthwhile, not as written anyway. There's nothing particularly interesting in that model about a Customer that deserves class status. The only thing interesting about being a "customer" is that there's one or more orders associated with that Person.

The college model also. There's a great deal that can, and probably should be shared between Student and Professor. Furthermore, what happens when you have a Professor taking a class, as is very often allowed for free on college campuses?

I suppose it might be a worthwhile practice, one element in the design toolkit. I don't think it should be the only way you approach design at the least though. Frankly, I find the commonality/variation analysis approach more useful. It seems to me to model very closely what we do in classifying abstractions during everyday life.

Edit: Just read half that second blog and I have to say I agree with it quite a lot. I'll have to read the rest and see what it's offering in terms of learning.

share|improve this answer
Error: Line 2: Invalid hyperlink! –  Cracker Jul 3 '11 at 22:05
SE software hosed it. It was working fine on preview. Here's the link in text form: objectmentor.com/resources/articles/CoffeeMaker.pdf –  Crazy Eddie Jul 4 '11 at 2:22
add comment

My opinion is that classes should added (and removed) as you code to separate concerns and reduce dependencies. Being fluent in design patterns are probably a good bet to see possibilities for refactoring and simplification.

Classes generally, in my experience, doesn't fall neatly into noun/verb categories but rather you'll end up with a mix of noun/verb classes along with different pattern classes (factories, singletons, strategy patterns etc) and other manager classes that addresses an aspect of your application.

The key thing is that your goal should be to able to look at a class and deduce what it does and modify that by only changing that class. The more code for an aspect of your application is spread out amongst classes the more difficult it becomes to follow, manage and extend it.

share|improve this answer
add comment

Your Answer


