Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I realized I have a difficulty creating OOP designs. I spent many time deciding if this property is correctly set it to X class.

For example, this is a post which has a few days: http://codereview.stackexchange.com/questions/8041/how-to-improve-my-factory-design

I'm not convinced of my code. So I want to improve my designs, take less time creating it.

How did you learn creating good designs? Some books that you can recommend me?

share|improve this question
    
What's your current level? I suppose you know about design patterns? –  ACNB Jan 29 '12 at 20:38
    
Not at all, in fact, I started reading some of them in PluralSight course: pluralsight-training.net/microsoft/Courses/… –  Darf Zon Jan 29 '12 at 20:45
1  
On of the most influential books in software design is ''Design Patterns: Elements of Reusable Object-Oriented Software''. It's still worth reading, although it's a bit dated now. You can also start reading the [en.wikipedia.org/wiki/Software_design_pattern](wikipedia articles). These software design patterns do not only provide you with a good solution for common problems, but are also part of the professional terminology now. –  ACNB Jan 29 '12 at 20:54
    
1. write - 2. review (including reading literature and sites like P.SE) - 3. refactor - 4. repeat –  HorusKol Jan 29 '12 at 22:29
    
there is no substitute for experience, there are no short cuts to this kind of knowledge –  Jarrod Roberson Jan 30 '12 at 2:04

4 Answers 4

up vote 13 down vote accepted

Designing systems is one of the things that you can only get better at by doing. Of course, it does help a little to read about good design - the recommend general object-oriented design book is the Gang of Four's Design Patterns: Elements of Reusable Object-Oriented Software. There are also other books on design patterns and principles for different types of systems and within different domains.

It's also best to get other people involved. After you create a design, present the problem(s) you are solving and the design to other people for a critical review. Listen to their feedback and have a dialog with them, focusing on why you made the decisions you did. As you are implementing the solution, you'll realize other problems with your design. Make note of these and learn from them. It might also be a good idea to work with other people to review the implementation against the design and requirements as well, and have a critical discussion of the reasons why you have done the things you did.

Although I typically find it best to sit down with other people face-to-face, specific design questions can be asked about here on Programmers. There are also Stack Exchange sites for code reviews and implementation questions.

share|improve this answer

From the looks of the codereview question you asked, you're at the stage of overdoing it. I think it is a rather common problem among people who discover the importance of good design.

It is actually a natural and probably even necessary step with any skill you pickup. As you start to learn something, the more you advance in the knowledge of a skill and the more you apply it, the better your results and it seems as though you were headed straight for mastery. The problem is, that your new target becomes not the quality of your results, but how much knowledge you have accumulated on your skill.

True mastery of a skill involves the understanding of when to use it and when not to. Overusing that skill is probably the only way to develop such understanding. Sure, you can read about this, but reading is no substitute for experience.

For one thing, reading about design patterns is a bad start IMHO. Reading about OO design principles, such as SOLID and GRASP is better. After getting acquainted to them, study of common design patterns is a good idea, because you will see how those principles can be applied to form concrete idioms.

It is claimed, that when patterns emerge in the use of a language, then the language actually lacks a feature. While this statement is very radical, there is a lot of truth in it. Therefore I would suggest, you look at and play around with other languages to gain a better understanding of the concepts you are seeking to employ, and also to learn about new concepts. A shortlist would be Squeak, Ruby and Lisp.
As for List, my personal recommendation is Structure and Interpretation of Computer Programms, which taught me a great deal about design, by showing me how effortlessly one can create robust solutions to complex problems, with little more than clear abstraction and (de)composition in a top-down manner.

So here's what I suggest:

  1. write code (and try to understand what makes it bad)
  2. read code (and try to understand what makes it good)
  3. exchange knowledge with other people. put your ideas to the test.
share|improve this answer
    
This is excellent advice! I am totally at the point of over applying my design pattern knowledge, as can be seen in my discussion with Kevin here –  TheSilverBullet Sep 13 '12 at 10:27

As others have mentioned, you will only get good with practice and experience. There isn't really that much of a shortcut you can take.

The fact that you look back at your stuff and you don't like what you've written, already puts you ahead of the curve compared many other people in our profession. While you are trying to improve yourself, the rest of us work with people who would write a 500-line function with 20 parameters, all passed in by reference and 15 of them being [in/out] and those people think they are the bomb because they got that mess to work.

When it comes to software design, it's not black and white, either design is good or bad. No matter how much experience you have, you will go back to some of your old code and think, "what was I smoking when I wrote this?" The key is constant evaluation of things and frequently going through the thought exercises to evaluate what makes good code good and bad code bad.

Finally, although nothing replaces practice, it's always a good idea to always keep reading blogs/books/this site because other other people will point out different perspectives that you may not have considered.

To start I would recommend these books:

  • Agile Principles, Patterns and Practices in C# - I'm 3/4th through this book myself. One of the main points the author makes, and I agree 100% with that, don't start off solving a problem by looking for a design pattern to apply. Keep things as simple as possible and evolve the code into a pattern, if the alternative starts to becomes more complicated than that.
  • Head First Design Patterns - I haven't read this book and in IMO many Head First series are targeted specifically for newcomers to the field. So they tend to be on the simpler side, but I've heard/read many good responses from others about that book
share|improve this answer
    
+1: "Keep things as simple as possible" ... "Evolve the code into a pattern..." –  kevin cline Jan 30 '12 at 3:50

Up-front design is never as good as out-back design. Just test, code, and refactor. When things are ugly, and you're not sure how to clean it up, then see if some design pattern will help. Practice this for a while and soon other developers will be asking how you come up with such clean designs.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.