I've been studying OOP in conjunction with Zend's MVC implementation for the past few months. I'm pretty new to programming, generally, but I feel strongly that I should learn things the 'right' way, which for me means to make sure I understand why things are done the way they are. I.e., I have found that in learning how to do something (anything, say music), the best way to learn how to do something is to know why it's done that way in the first place.

Anyway, I have been struggling very hard with understanding how to develop my own business models (i.e., the M of MVC), and I have decided it's not because I don't understand OOP in general, because I've studied it for several months and I don't think the concepts are very difficult to grasp. I find the examples I've studied very intuitive, actually. The problem for me, I think, lies in the process of translating my own problems into object oriented solutions. The examples in books (that I've read so far) are too obvious, so the process of translating the problem into objects isn't very difficult. What I think I might be missing is a high-level abstracted process. Some kind of list of steps or questions that every object-oriented solution must answer on the highest level.

If you had to describe such a process in no more than five steps, what would they be and why? What is the most effective process in translating any problem into an object-oriented solution?

closed as too broad by Dan Pichelman, Ampt, jwenting, ChrisF Oct 15 '14 at 11:28

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    OOP aint always all that ... – Job Sep 4 '11 at 1:50
  • In your studying of OOP have you read anything about design patterns yet? – Zoredache Sep 4 '11 at 5:47
  • 1
    I recommend you read Eric Evan's book about Domain Driven Design when you have a difficult time creating models. See also @Simon Stellings answer. The book covers this process quite in detail. – Falcon Sep 4 '11 at 7:53
  • @Zoredache I have come across the concept of design patterns, as well as a few examples of some, like singleton, factory, and MVC itself (which, in Zend's implementation is also front controller). However, that was my next move, so to speak. I picked up Martin Fowler's book on enterprise patterns and I've only read a part of the introduction so far. Is the a clear, easy to read introduction you would recommend? – user25791 Sep 4 '11 at 10:58
  • @Falcon I had a question about php/MySQL and date formatting on SO the other day, and I would have chosen your answer but it was only a comment, for what it's worth. – user25791 Sep 4 '11 at 11:01

Finding a suitable model isn't always straight forward. It is one of these things which require more experience than plain knowledge. However, the following simple recipe might help you to get over an initial mental block.

It was originially described in this paper by Abbott and is frequently referred to as "Abbott's textual analysis".

  1. Write a plain text specification.
  2. Identify classes: Nouns are good candidates.
  3. Find the attributes: Adjectives/adverbs are good candidates.
  4. Find the operations: Verbs are good candidates.
  5. Find the associations between classes.
  6. Refine.


Nouns, verbs and adjectives are marked.

The library contains books and journals. It may have several copies of a given book. Some of the books are for short-term loans only. All other books can be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of the staff may borrow up to 12 items at one time. Only members of the staff may borrow journals.

A first analysis iteration would yield:


  • Library
  • Book, Journal
  • Copy
  • Loan
  • Library Member
  • Item
  • Staff Member

From here on, you can think about which class needs which attributes and methods to implement the behaviour and then refine that model increasingly.

  • 1
    Good answer. In addition to Abbott's paper, I recommend Eric Evan's book on Domain Driven Design. It teaches how to create an ubiqitous language for the project and how to distill a powerful model from it. – Falcon Sep 4 '11 at 7:55
  • I'm drawn to this answer because I studied linguistics a little bit and it makes good intuitive sense to me without much effort, however I'm afraid of it for the same reasons because I've found that too much analogy can lead me astray. – user25791 Sep 4 '11 at 11:08
  • @Falcon +1 for recommending a book with Kandinsky cover art. – user25791 Sep 4 '11 at 11:18
  • @tbj1982: You're absolutely right. It is a simple heuristic, and the results should be treated with that in mind. It's not the golden bullet, but it may be a helpful starter. – blubb Sep 4 '11 at 11:40

In my opinion, taking TDD approach is natural and efficient:

  1. Write down specific requirements (Given, When, Then)
  2. Translate each requirement (most important one first) into a unit test.
  3. Write least amount of code in order to pass the test written in #2.
  4. After passing the test, refactor your code according to SOLIDD design principles.
  5. After #4, make sure your code still pass all tests written.
  6. Repeat 2-5.

With this process, you can gradually produce testable code with sound design. You might think at first that writing test is unnecessary but that activity actually helps you build sound architecture.


Here's steps I use in c++ code:

  1. decide class name
  2. decide constructor parameters and data members.
  3. decide member function names and prototypes
  4. make it independent of other classes
  5. The design is done, and everything else is just the implementation.

The reason for (1) is that it defines the scope of what functionality belongs to the class. The reason for (2) is that it defines how the class communicates with the outside world. The reason for (3) is that it defines how to choose which functionality of the class is needed in each situation. The reason for (4) is that it allows class to be used in many different situations. The reason for (5) is that it defines the border between design and implementation.

  • +1 for naming. It's amazing how much just adding names can organize thought processes, since you're implicitly bringing in all of the knowledge of the "real world" with it. – Mark Brackett Jun 23 '13 at 16:05