What do you think?
Rate this book
Designing Object-Oriented Software
Practical and down-to-earth in approach, this bestseller explores the art of designing object-oriented software. It offers basic design principles and a specific design process that can be applied to any software programming effort even those not using object-oriented programming languages or environments.
Covers the concepts of object-oriented technology, presents a process to apply those concepts, the tools to use throughout the process, and examples to put it all together.
For developers of object-oriented software.
368 pages, Paperback
First published July 1, 1990
6 people are currently reading
168 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 6 of 6 reviews
November 2, 2013
It's fun to read a book written when the "waterfall" design process wasn't yet considered inherently evil. The book leans very heavily on inheritance, much more so than I feel is considered good practice today, however the book's message about the value of OO and how to think about it and design a maintainable system is still very relevant.
March 8, 2013
If you ever plan on learning C++, Java or Objective-C READ THIS FIRST. It is by far the best explanation and treatment of object-oriented programming I have read. It will save you a ton of headache in the course of learning an your first object-oriented language.
January 5, 2018
Considering this book was written before many of the most the popular OO languages like Java, C#, Ruby, Python; even existed, it feels pretty contemporary. It talks heavily about arguably suboptimal concepts like multiple inheritance and getting the upfront design right but I think we can take most of the ideas and apply them to Agile environments, that is, we still do planning on Agile even though incremental, iterative development is at the heart of the process. We don't necessarily have to write a full blown upfront design, but we can use the elaborated techniques described in this book to come up with good, supple and flexible feature/system designs easy to refactor down the road.
Most of these concepts have stood the test of time.
You're presented with notions like who controls what, spreading system intelligence as evenly as possible rather than encapsulating most behaviour in a single class, wrap classes inside subsystems (modules) to reduce coupling and increase cohesion.
The authors thoroughly break down the building blocks of OOP in a way you wish you had learned before you've ever saw an OO language:
- Inheritance is just about factoring out common functionality into a single place.
- Objects communicate with each other by sending messages.
- Messages have a name and may include arguments.
- Objects handle messages by executing methods.
- The set of messages an object can respond to is known as behaviour.
- When two or more kinds of objects can respond to the same message by executing different methods which have the same message name, you get polymorphism.
It was great to read a book from the time when a lot of the stuff we now take for granted had to be factored into the design like: classes for handling Arrays, graphic operations, fixed/floating point numbers, etc. Things we today get from programming frameworks with a rich library of built-in functionality, it gives you an idea of where we're coming from being a refreshing reminder of what things the underlying platform is doing for you.
Most of these concepts have stood the test of time.
You're presented with notions like who controls what, spreading system intelligence as evenly as possible rather than encapsulating most behaviour in a single class, wrap classes inside subsystems (modules) to reduce coupling and increase cohesion.
The authors thoroughly break down the building blocks of OOP in a way you wish you had learned before you've ever saw an OO language:
- Inheritance is just about factoring out common functionality into a single place.
- Objects communicate with each other by sending messages.
- Messages have a name and may include arguments.
- Objects handle messages by executing methods.
- The set of messages an object can respond to is known as behaviour.
- When two or more kinds of objects can respond to the same message by executing different methods which have the same message name, you get polymorphism.
It was great to read a book from the time when a lot of the stuff we now take for granted had to be factored into the design like: classes for handling Arrays, graphic operations, fixed/floating point numbers, etc. Things we today get from programming frameworks with a rich library of built-in functionality, it gives you an idea of where we're coming from being a refreshing reminder of what things the underlying platform is doing for you.
September 12, 2024
A lot of valuable insights on the design process of an architecture for your code.
The biggest insight is to follow this process:
1- Classes: Identify your classes. Use noun or noun phrases to name them.
2- Hierarchy: Identify your hierarchy. Which classes share common behavior.
3- Responsibility: What is the responsibility of each class. Try to distribute the responsibility evenly.
4- Dependency: What classes depend or need other classes.
5- Subsystem: Based on the dependencies and responsibilities define subsystems which are a collection of classes that work together to deliver a feature.
The biggest insight is to follow this process:
1- Classes: Identify your classes. Use noun or noun phrases to name them.
2- Hierarchy: Identify your hierarchy. Which classes share common behavior.
3- Responsibility: What is the responsibility of each class. Try to distribute the responsibility evenly.
4- Dependency: What classes depend or need other classes.
5- Subsystem: Based on the dependencies and responsibilities define subsystems which are a collection of classes that work together to deliver a feature.
Read
July 11, 2012added
Want to read
January 5, 2015i want to design a software
This entire review has been hidden because of spoilers.
Displaying 1 - 6 of 6 reviews