10 Top Tips for Good Object-Oriented Design
•Download as PPTX, PDF•
0 likes•631 views
This document provides 10 tips for good object-oriented design: 1) favor an object-oriented, message-based approach; 2) favor composition over inheritance; 3) understand the continuum of abstraction from instances to interfaces; 4) use abstract classes to model abstractions; 5) don't expose state on interfaces; 6) program to interfaces, not implementations; 7) use inheritance for specialization, not extension; 8) understand and apply design patterns; 9) recognize that OO breaks down at application boundaries; and 10) make objects and values immutable when possible.
Recommended
More Related Content
Viewers also liked
Similar to 10 Top Tips for Good Object-Oriented Design
Similar to 10 Top Tips for Good Object-Oriented Design (20)
Recently uploaded
Recently uploaded (20)
10 Top Tips for Good Object-Oriented Design
- 1. 10 TOP TIPS for good object-oriented design
- 2. WHO AM I? • Founder of Cambridge Software Craftsmanship Community • Developer and Technical Lead at Red Gate Software • Twitter: @alastairs • http://www.codebork.com/ • alastair@alastairsmith.me.uk
- 3. 1. OBJECT-ORIENTATION MESSAGE-ORIENTATION • Values are passed between objects as messages • Tell objects, ask values • “Don’t call us, we’ll call you” • State is only there to support behaviour
- 4. 2. FAVOUR COMPOSITION OVER INHERITANCE • Loose coupling • Strategies, Adapters, Composites and more are your friends
- 5. 3. THERE IS A CONTINUUM OF ABSTRACTION Instance Class Abstract Class Interface
- 6. 4. USE ABSTRACT CLASSES • Not every abstract concept should be an interface • Model all your abstractions at the right level
- 7. 5. DON’T EXPOSE STATE ON INTERFACES • Interfaces are contracts of behaviour • State is data
- 8. 6. PROGRAM TO THE INTERFACE, NOT THE IMPLEMENTATION • Loose coupling • Assume nothing about the implementation of the interface
- 9. 7. INHERITANCE IS FOR SPECIALISATION • Use composition for extension • Specialisation is like evolution
- 10. 8. KNOW YOUR PATTERNS • Design Patterns are our bricks and mortar • Use GoF as a reference only
- 11. 9. AT THE BOUNDARIES OF AN APPLICATION, OO BREAKS DOWN • Use value objects to convey state out of the core of the application • Do not reuse abstractions in different modules • Use hexagonal architecture to separate concerns
- 12. 10. MAKE YOUR OBJECTS AND VALUES IMMUTABLE • Easier comparisons when testing • Both have a concept of equality • Thread safety in multi-threaded systems • Less complex implementation
- 13. ANY QUESTIONS? Thank you for listening!
Editor's Notes
- Applies to all OO languages, but some refer to C# language features
- Alan Kay himself has said that, if he were designing Smalltalk again, he would call it Message-Oriented Programming rather than Object-Oriented Programming, because of the confusion rife over what he and the other designers of Smalltalk meant.The magic in object-orientation lies in the collaboration between objects, their behaviour, the messages they send to one another; not their state. Objects are often designed in terms of their properties rather than their behaviours: e.g. a Car has four wheels which allow it to travel from A to B, rather than the behaviours of adding a new passenger and travelling to a destination. This is why TDD (and, more specifically, Outside-In TDD as described in GOOS) works so well: it places the focus on the behaviour of the system under test, and not its state.
- GoFDesign Patterns. Composition provides more flexible designs, because your components are more loosely-coupled: you can re-arrange them into whatever shape you need, much like LEGO. This works because of message-oriented programming: passing messages between objects via method calls leads to much more composable designs
- Think about the words used for these different concepts, and their dictionary definitions:Class: “a number of persons or things regarded as forming a group by reason of common attributes, characteristics, qualities, or traits”Abstract: “thought of apart from concrete realities, specific objects, or actual instances; expressing a quality or characteristic apart from any specific object or instance”Interface: “a common boundary or interconnection between systems, equipment, concepts, or human beings.”A class is an abstraction! The only concrete thing you have is an instance of a class.
- But, ensure they are well-defined:Common stateCommon behaviours – implementing multiple interfacesCohesiveIf you’re dealing with Animals, you almost certainly won’t need an abstraction for Dog, much less a springer spaniel; a dog is instead an instance of an animal. (RG Note: In SOC, there 8.3x as many interfaces as abstract classes.)
- This is a leaky abstraction: by exposing an element of state it makes assumptions about the implementation of the interface. The only way to extend data (i.e., adding new data items) is through inheritance. Putting properties on interfaces encourages inheritance of interfaces, which breaks the Interface Segregation Principle, and makes your abstraction even more leaky.Again, think about the word “interface” in terms of its dictionary definition. A Graphical User Interface or Command-Line Interface has behaviour, not state: push button, enter text, run command, display results. You interact with interfaces, via their behaviours, and through those behaviours observe something about its state.
- GoFDesign Patterns.Helps ensure loosely-coupled, composable code that is easy to test, because you’re interacting with the behaviour of collaborators, you’re not relying on their current state too.
- “Inheritance is a tremendously powerful tool for sharing implementation details and specializing behaviour. But the fact that you only get "one shot" at inheritance in a single-inheritance world means that you’ve got to take that shot carefully and make sure you're using that power to its best ability.” – Eric LippertDo not add or modify behaviour through inheritance, use composition instead.Evolution: structural adaptation to a particular function for use in a particular environment
- Know what problems they solve, where they can be applied appropriately, etc. Knowing the appropriate application of a pattern is more important than knowing the pattern itself. Know how to spot a poorly-implemented pattern.GoF is great as a reference book, but is perhaps too dry to learn the patterns from. Try other texts, such as Head First Design Patterns or Holub on Patterns to learn the patterns in context.
- Use mapping techniques (e.g., AutoMapper) to convert between the models at the boundaries and the rich domain objects powering the applicationHexagonal architecture == ports and adapters from GOOS. See also Ian Cooper’s talk “TDD: Where did it all go wrong?”