Feature of Good Design (1)
Code reuse Code reuse
– Challenge: tight coupling between components, dependencies on concrete classes instead of interfaces, hardcoded operations
– Solution: design patterns
- Challenges: tight coupling between components, dependence on concrete classes rather than interfaces, hard-coded operations
- Solution: Design Patterns
• However, sometimes making components more complicated
However, it sometimes complicates the component
– Three levels of reuse: a piece of wisdom from Erich Gamma
- Three Levels of Reuse: The Wisdom of Erich Gamma
• Lowest: classes
Minimum: Category
• Highest: frameworks
Highest: frame
• Middle level: design patterns
Middle level: design patterns
Feature of Good Design (2)
Extensibility
Change is the only constant thing in a programmer’s life
- Change is the only constant in a programmer's life
• We understand the problem better once we start to solve it
Once we start solving problems, we understand them better
• Something beyond your control has changed
Things have changed beyond your control.
• Objectives/requirements have changed
Objectives/requirements have changed
– Prepare for possible future changes when designing an architecture
- Designing structures to prepare for possible future changes
Good Design Principles (1) Good Design Principles (1)
Encapsulate what varies Encapsulate what varies
– Identify the aspects of your application that vary, and separate them from what stays the same
- Identify different aspects of the application and distinguish them from the parts that remain the same
– Main goal: minimize the effect caused by changes
- Main objective: to minimize the impact of change
– Isolating program parts that vary in independent modules, protecting the rest
-Isolates different parts of the program in separate modules and protects the remaining parts
– Encapsulation on a method level
- method level encapsulation
– Encapsulation on a class level
- class-level encapsulation
Good Design Principles (2) Good Design Principles (2)
Program to an interface, not an implementation Program to an interface, not an implementation
– In other words, depend on abstractions, not on concrete classes
- In other words, relying on abstraction, rather than concrete classes
– The design is flexible enough if you can easily extend it without breaking existing code
- The design is flexible enough if you can easily extend it without breaking existing code
– A possible approach
- Determine what exactly one object needs from the other: which methods does it execute?
Determine exactly what one object needs from another: what methods does it perform? - Describe these methods in a new interface or abstract class.
Describe these methods in a new interface or abstract class. - Make the class that is a dependency implement this interface.
Enables classes that are dependencies to implement this interface. - Make the second class dependent on this interface rather than on the
concrete class.
Make the second class dependent on the interface instead of the concrete class.
Good Design Principles (3) Good Design Principles (3)
Favor composition over inheritance Prioritize composition over inheritance
– Challenge of inheritance
- The challenge of succession
• A subclass can’t reduce the interface of the superclass
Subclasses cannot reduce the interface of a superclass
• When overriding methods you need to make sure that the new behavior is compatible with the base one
When rewriting methods, you need to make sure that the new behavior is compatible with the base behavior
• Inheritance breaks encapsulation of the superclass
Inheritance destroys the encapsulation of superclasses
• Subclasses are tightly coupled to superclasses
Subclasses are tightly coupled to superclasses
• Trying to reuse code through inheritance can lead to creating parallel inheritance hierarchies
Attempts to reuse code via inheritance may result in the creation of parallel inheritance hierarchies
SOLID Principles
SOLID 1: Single Responsibility Principle
A class should have just one reason to change
A class should have only one reason to change
– Try to make every class responsible for a single part of functionality,and make that responsibility entirely encapsulated
- Try to make each class responsible for a portion of the functionality and completely encapsulate that responsibility
• Main goal: reducing complexity, and reducing risks
Main objective: to reduce complexity and minimize risk
SOLID 2: Open/Closed Principle Open/Closed Principle
- Classes should be open for extension but closed for modification
Classes should be open to extensions but closed to modifications
– Keep existing code from breaking when implementing new features
- Preventing existing code from breaking when implementing new functionality - A class is open if it can be extended by subclasses
A class is open if it can be extended by subclasses - A class is closed if it is 100% ready to be used by others
A class is closed if it is 100% available for use by others - A class can be both open (for extension) and closed (for modification) at the same time
A class can be both open (for extensions) and closed (for modifications)
– Not necessary to be applied for all changes
- No need to apply all changes
SOLID 3: Liskov Substitution Principle Richter's Substitution Principle
-
When extending a class, ensure the capability of passing objects of the subclass in place of objects of the parent class without breaking the client code
When extending a class, it is guaranteed to be possible to replace objects of the parent class with objects of the subclass without breaking client-side code -
The subclass should remain compatible with the behavior of the superclass
Subclasses should remain compatible with the behavior of superclasses
– When overriding a method, extend the base behavior rather than replacing it with something else entirely
When rewriting a method, extend the basic behavior instead of replacing it with something else entirely -
Especially critical when developing libraries and frameworks
Especially important when developing libraries and frameworks -
A set of checks
Group I inspections- (a) Parameter types in a method of a subclass should match or be more abstract than parameter types in the method of the superclass.
The parameter types in subclass methods should match or be more abstract than the parameter types in superclass methods. - (b) The return type in a method of a subclass should match or be a subtype of the return type in the method of the superclass.
The return type in a subclass method should match or be a subtype of the return type in a superclass method. - (c) Types of exceptions should match or be subtypes of the ones that the base method is already able to throw.
The exception type should match or be a subtype of an exception type that the base method can already throw. - (d) A subclass shouldn’t strengthen pre-conditions.
Subclasses should not reinforce prerequisites - (e) A subclass shouldn’t weaken post-conditions.
Subclasses should not weaken postconditions - (f) Invariants of a superclass must be preserved (least formal rule of all)
Invariants of superclasses must be preserved (at least all formal rules) - (g) A subclass shouldn’t change values of private fields of the superclass.
Subclasses should not change the values of private fields of the superclass.
- (a) Parameter types in a method of a subclass should match or be more abstract than parameter types in the method of the superclass.
SOLID 4: Interface Segregation Principle
Clients shouldn’t be forced to depend on methods they do not use
Implementation code should not be forced to rely on methods they don't use
– Make interfaces narrow enough that client classes don’t have to implement
behaviors they don’t need
- Make interfaces narrow enough so that implementation code classes don't have to implement behavior they don't need
– Break down “fat” interfaces into more granular and specific ones
- Decomposition of "fat" interfaces into more granular and specific interfaces
SOLID 5: Dependency Inversion Principle
- High-level classes shouldn’t depend on low-level classes, and both should depend on abstractions
Higher-level classes should not depend on lower-level classes, and both should depend on abstractions - Problem: business logic classes tend to become dependent on primitive low-level classes
Problem: Business logic classes tend to rely on primitive low-level classes - Suggestion: changing the direction of dependency
Recommendation: change the direction of reliance - Approach
- Describe interfaces for low-level operations that high-level classes rely on, preferably in business terms
An interface describing the low-level operations on which the high-level class depends, preferably in business terms - Make high-level classes dependent on the interfaces, resulting in a softer dependency
Make higher-level classes dependent on interfaces, resulting in softer dependencies - Low-level classes implement the interfaces, dependent on the business logic level
Low-level classes implement interfaces that depend on the business logic level
- Describe interfaces for low-level operations that high-level classes rely on, preferably in business terms
