views:

210

answers:

10

I am on the quest to be a good OO-developer. OO intrigues me, because I understand the patterns, know why composition gives you more flexibility then inheritance, and more of such wisdom. However, I came to the conclusion that I know how to implement a factory of a singleton, but that I do not know how to come up with a robust OO design.

I have a bunch of books

  1. Design Patterns by the GoF
  2. AntiPatterns Brown et al.
  3. Refactoring by Fowler
  4. Code complete 2

They might be very good books, but they don't teach you to architect an application. I am often paralysed by some very basic decisions (example). I am looking for a book that teaches the when and why. There are many books about hammers and nails, but I have yet to find a book that tells you something about their practical relationship.

What book was most instrumental in making you a confident OO-architect/designer?

+1  A: 

Actually doing programming is a bigger help than reading about doing programming.

"paralysed by some very basic decisions" is a symptom of a deeper problem -- over-engineering. Until you build a lot of stuff, you don't really know which decisions matter and which don't matter.

The best way to get the necessary experience is to build a lot of stuff.

Code Kata is very, very important. http://slott-softwarearchitect.blogspot.com/search/label/code-kata

Also, I collected a bunch of code kata that I have used into a single, large project. http://homepage.mac.com/s_lott/books/oodesign.html

S.Lott
Although this is not a book they look like well-documented and well-motivated use cases. thnx for the pointer
Exception e
shahkalpesh
Functional software systems also struggle with issues of large-scale design and information hiding. The Design Patterns book has been characterized by some as ways of doing FP in OO. Well, I'm still waiting for the corresponding book on achieving OO information hiding and controlled reuse in FP...
Pontus Gagge
OO is not replaced by functional. Functional OO programming is what I do. I'm a heavy user of Stateless objects in Python. There is no "1 good way" to do anything, so that's not an objection to OO. OO is not "losing value" in any sense of the word. You're learning about functional, but you still know about Objects and will still use them in a functional style.
S.Lott
@Exception e: A "book" for code kata is silly. It would go out of date every few hours. The other link *is* a book. I don't get your comment and I don't understand why "book" is so important. Books are web sites pressed into paper, aren't they?
S.Lott
shahkalpesh
@shahkalpesh: (1) This is off-task for this question. (2) Comments aren't an easy way to address this. The FP/OO question has already been asked on Stack Overflow, search for and read those questions first. Feel free to add comments to get more information. If necessary, consider asking a new question on this FP/OO topic.
S.Lott
@S.Lott: have you read Meyer's "Object-oriented software construction" like several people with more votes than you suggested and do you think it is a "web sites pressed into paper"? (I suppose you don't want to discuss this in a comment). Also, do you think your writings are better at explaining OOA/D than Meyer's highly regarded "Object-Oriented Software Construction" *book*?
Webinator
@WizardOfOdds: Yes, I've read Meyer's book. Twice. No, it's pretty stable, static stuff on how to do OO well from fundamental principles. Hence the need to invent a new language. My book doesn't make a big effort to "explain" OOA/D; it is a series of exercises based on some prior knowledge of OOP, and it just dives in and does it. It's some narrative on what problem is being solved and some design details. Build a bunch of stuff. Learn by doing.
S.Lott
+3  A: 

The best book I ever read about OO is Bertrand Meyer Object Oriented Software Construction.

Its huge but it was very useful for me. It covers every single aspect of OO design IMVHO.

Alexander Poluektov
Could you tell me what to expect from Bertrand Meyer's book? I read that you could see it as a rationale for the Eiffel language. I don't know Eiffel but for example does he show the importance of delegates and how they are a fist class citizen of Eiffel, or does he really treat subjects like discovering classes and responsibilities?
Exception e
Eiffel is very secondary topic in his book. Despite that most examples are written in Eiffel, I think you should experience no difficulties while reading it. Some features are, of course, specific to Eiffel (notably Design-by-Contract built-in features), but they are perfectly readable, and would be useful in whatever language you are working on. (BTW I don't know Eiffel either).
Alexander Poluektov
+1  A: 

I fully understand your situation. Also own three of those books ;) I'd suggest the Head First edition. Object-Oriented Analysis and Design. This will get you on the right tracks. The GoF book is great but of no use until you get the basics through your head and the Head First book will take care of that. Cheers :)

Peter Perháč
Thnx, it makes me feel I am not alone. I always thought the Head First series were meant to give a give a too basic though gentle introduction. I will look into this suggestion!
Exception e
A: 

Although leaning towards Rational UP I've found these two to offer a lot of insight into OO design.

  • Applying UML and Patterns - Craig Larman
  • UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design - Jim Arllow & Ila Neustadt
Bedwyr Humphreys
+1  A: 

Robert C. Martin "Agile Software Development: Principles, Patterns and Practices" that explains you the principles of OO

Eric Evans: "Domain Driven Design" deals with how to make a good design that corresponds to your business problem

Martin Fowler: "Patterns of Enterprise Application Architecture" for basic principles on enterprise architecture

bertolami
+1  A: 

The only way to find out if a design is robust is to implement it. There is no single book that will teach you how to produce implementable designs, it comes down to experience and talent. However, I do second the vote for Bertrand Meyer's book - just be aware it won't turn you into an OO design god.

anon
+1  A: 

Craig Larman's Applying UML and Patterns summarized a lot about what I had learned from experience. What I like about it is that it addresses all the aspects of software design -- which includes things like iterative design and development. Don't stare too hard at the use of UML: design descriptions are a means towards an end, and I found Larman's approach fairly pragmatic. You can't just code: you have to communicate your intentions (and understand what is needed). UML and cleanly designed, well commented code are some of the means towards that end.

And, of course, as others mention: no book will make you a good developer or designer. But it might help accelerate the process.

Pontus Gagge
+3  A: 
  1. "Object-oriented software construction" by Bertrand Meyer

Most fundamental work about object-orientation ever published. This is absolutely must have book for every "object-oriented" programmmer.

2. "Object-Oriented Analysis and Design with Applications" by Grady Booch et al

Not so formal as Meyer's book, but this book can open your eyes on many questions in object-oriented world and in software development in general

3. "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma et al.

This is famous "Gang of Four" book about design patterns

4. "Refactoring: Improving the Design of Existing Code" by Martin Fowler et al.

This is another classical book. First part perfectly describe many problem that modern software developer may faced during his work: code smells, readability vs performance, premature optimization drawbacks and many other topics.

5. "Thinking in Java" by Bruce Eckel

This book may help many beginners not only in Java language but in object-oriented way of thinking too.

6. "Touch of Class: Learning to Program Well with Objects and Contracts" by Bertrand Meyer

Excellent textbook by famous author.

Sergey Teplyakov
A warning about Booch. The book is written in a sort high brow manner, ( In this book, he tends to write using a grammar and vocabulary intended to impress intelligensia. ) which makes it very hard to read. The content is more about laying out the problems with design rather then showing actual techniques to solve them. So it does not have many heuristics.
HandyGandy
@HandyGandy: is this why you recommended "Designing Object Oriented C++ Applications Using The Booch Method", as it would fill that gap?
Exception e
A: 

For a starter, I suggest Head First Object Oriented Analysis and Design. It guides you to build an OO application in a simple intuitive step by step method.

Emad