some
Object-oriented design
law
Bob Tarr
Outmyth translation
Law 1: Priority use (object) combination, not (class) inheritance
[Favor Composition Over Inheritance]
combination
n
(Object) combination is a multiplexing method for obtaining new functions by creating an object that combines other objects.
n
Entrust the function to an object combined to obtain new features.
n
Sometimes, it is also called "aggregation" or "inclination", although some authors give special meaning to these terms
n
E.g:
Fly
Aggregation: An object has another object or is responsible for another object (ie, an object contains another object or part of another object), and the aggregate object and owner have the same lifecycle. (Translator Note: The so-called "same life is dead" relationship, see the introduction part of the DESIGN PATTERNS: Elements of Reusable Object-Oriented Software.)
Fly
Tolerant: A special type of combination. For other objects, the contained objects in the container are invisible, and other objects can only access the contained objects through the container object. (COAD)
n
The included can be implemented in two ways:
Fly
By Reference
Fly
By value
n
C allows you to be included based on values or references.
n
But in Java, everything is referenced!
Advantages and disadvantages of combination
n
advantage:
Fly
The container class can only be accessed by an interface that is included.
Fly
"Black Box" is multiplexed because the internal details of the object are not visible.
Fly
Good containerity.
Fly
Realization is relatively small. (Translator Note: It is relatively less dependence between the object and the container object)
Fly
Every class is only focused on a task.
Fly
By getting a reference to other object references to other types of objects, (objects) can be dynamically defined during operation.
n
Disadvantages:
Fly
Thus, there is too much object in the system.
Fly
In order to use multiple different objects as a Composition Block, you must be carefully defined.
inherit
n
(Class) inheritance is a multiplexing method for obtaining new functions by extending an existing object.
n
The generalization (super class) can explicitly capture those public properties and methods.
n
Special classes (subclasses) are achieved by additional properties and methods.
Advantages and disadvantages of inheritance
n
advantage:
Fly
It is easy to perform new implementations because most of them can inherit.
Fly
Easy to modify or extend those achievements.
n
Disadvantages:
Fly
Destroy the encapsulation because this will expose the details of the parent class to the child class.
Fly
"White Box" is reused because the internal details of the parent class are often visible for subclasses.
Fly
When the implementation of the parent class, the subclass has to change it.
Fly
The implementation from the parent class inheritance will not change during operation.
COAD rules
For all the criteria of the following, they can use inheritance:
n
Subclasses express "Is a special type of ..." instead of "is a role played by ...".
n
An example of a subclass will never need to transmute as an object of other classes. n
Subclasses are expanded for their parent class, rather than rewriting or abolishing (NULLIFY).
n
Subclasses are not extended for those functions that are only a tool class.
n
For a classes in the actual problem domain, their subclasses refer to a role (Transaction) or device.
Inheritance / Combination Example 1
n
"It's a special type of ..., not" is a role played by ... "
Fly
failure. Passengers are a role that people play. Agent is also.
n
Never need to transform
Fly
failure. Over time, a subclass example of a Person may turn from Passenger into an agent, and then go to the Agent Passenger.
n
Expand, not retroactive and abolishment
Fly
by.
n
Do not expand a tool class
Fly
by.
n
In the problem domain, specifically refer to a role, transaction or equipment
Fly
failure. Person is not a role, trading or device.
Inheritance is not applicable!
Use a combination to save!
Inheritance / Combination Example 2
n
"It's a special type of ..., not" is a role played by ... "
Fly
by. Passengers and agents are all roles of special types of people.
n
Never need to transform
Fly
by. A Passenger object will remain unchanged; Agent object is also.
n
Expand, not retroactive and abolishment
Fly
by.
n
Do not expand a tool class
Fly
by.
n
In the problem domain, specifically refer to a role, transaction or equipment
Fly
by. Personrole is a type of role.
Inherit is available here!
Inheritance / Combination Example 3
n
"It's a special type of ..., not" is a role played by ... "
Fly
by. Book and purchase are a special type of transaction.
n
Never need to transform
Fly
by. A RESERVATION object will remain unchanged; the Purchase object is also.
n
Expand, not retroactive and abolishment
Fly
by.
n
Do not expand a tool class
Fly
by.
n
In the problem domain, specifically refer to a role, transaction or equipment
Fly
by. It is a transaction.
Inherit is available here!
Inheritance / Combination Example 4
n
"It's a special type of ..., not" is a role played by ... "
Fly
failure. Book is not a special type of Observable.
n
Never need to transform
Fly
by. A RESERVATION object will remain unchanged.
n
Expand, not retroactive and abolishment
Fly
by.
n
Do not expand a tool class
Fly
failure. Observable is a tool class.
n
In the problem domain, specifically refer to a role, transaction or equipment
Fly
not applicable. Observable is a tool class, not a class of a problem domain. .
Inheritance is not applicable!
Summary of inheritance / combination
n
Combination and inheritance are important reuse methods
n
In the early days of OO development, inheritance is overused
n
Over time, we find that priority use combination can get a more reuse and simple design.
n
Of course, it can be inherited to expand the set of composable classes.
n
Therefore, the combination and inheritance can work together
n
But our basic law is:
Priority use of object combination, not (class) inheritance [Favor Composition over Inheritance]
French 2: Programming for interface, not (interface)
[Program to An Interface, Not An Implementation]
interface
n
The interface is an object that is known when the other object is called.
n
An object can have multiple interfaces (actually, the interface is a subset of all methods of the object)
n
The type is a specific interface of the object.
n
Different objects can have the same type, and an object can have a plurality of different types.
n
An object can only be understood by other objects through its interface.
n
In a sense, the interface is in a very limited manner, "is a ..." expression as "a support for this interface ...".
n
The interface is the key to implementing pluggability
Implement inheritance and interface inheritance
n
Implementation inheritance (class inheritance): An implementation of an object is defined according to the implementation of another object.
n
Interface Inherit (Sub Type): Describes when an object can be used to replace another object.
n
The inheritance mechanism of C is independent inheritance and refers to the inheritance of the interface.
n
C achieves the inheritance of the interface by inheriting pure emptive.
n
Java inherits the interface with a separate language constructor -Java interface.
n
Java interface constructors are easier to express and implement those designs focus on object interfaces.
Benefits of interface
n
advantage:
Fly
Client does not have to know the specific class of its use of objects.
Fly
An object can be easily replaced with another object of (realized the same interface).
Fly
The connection between the object does not have to hardbonize (hardwire) to a specific class object, thereby adding flexibility.
Fly
Loosens Coupling.
Fly
Increase the possibility of reuse.
Fly
Improve the chance of (object) combination, because the object being included can be any class that implements a specified interface.
n
Disadvantages:
Fly
The complexity of the design is slightly increased
(Translator Note: The interface represents the relationship of "..." (Likea), inherits the relationship of "... is ..." (ISA), combining the relationship of "..." "(HASA).)
Interface instance
n
This method refers to other classes that can be driven by vehicles without having to care about it actually (car, ship, submarine, or other object that implements imaneuverabre).
Law 3: Open - Closed Fault (OCP)
Software composition entities should be scalable, but cannot be modified.
[Software Entities SHOULD BE OPEN for Extension, Yet Closed for MODIFICATION]
Open-Closed
n
Open-Closed Law Thinks that we should try to design a module that never needs to change.
n
We can add new code to extend system behavior. We cannot modify existing code.
n
Modules that meet OCPs need to meet two standards:
Fly
Scalable, "Open for Extension" (Open for Extension) - The behavior of the Open for Extension - module can be expanded to meet new needs.
Fly
It is not allowed to change the source code of the "Closed for Modification" (Closed for Modification) - The source code of the module is not allowed. n
How can we do it?
Fly
Abstraction
Fly
Polymorphism
Fly
Inheritance
Fly
Interface
n
All modules of a software system cannot meet OCP, but we should work hard to minimize these modules that do not satisfy OCP.
n
Open-Closed Law is the true core of OO design.
n
In line with this rule, it means the highest level of reusability and maintenance (Maintainability).
OCP example
n
Consider the following methods:
n
The above functions work is to calculate the sum of the prices of the various parts in the form array.
n
If Part is a base class or interface and uses a polymorphism, the class can easily adapt to new types of components without having to modify it.
n
It will comply with OCP
n
But when calculating the total price, if the financial department promulgates the motherboard and memory, how to do it.
n
How is the following code?
n
Is this in line with OCP?
n
When each Financial Department proposes a new pricing strategy, we have to modify the TotalPrice () method! This is not "closed". " Obviously, the changes in the strategy mean that we have to modify the code in some places, so how should we do it?
n
In order to use our first version of TotalPrice (), we can merge the pricing policy into the getPrice () method of the Part.
n
Here is an example of a Part and ConcretePart classes:
n
But now whenever the pricing strategy changes, we must modify each subclass of Parts!
n
A better idea is to adopt a PricePolicy class that inherits it to provide different pricing strategies:
n
It seems that what we do is to postpone problems into another class. But use this solution, we can dynamically set the pricing policy by changing the Part object, dynamically set the pricing policy.
n
Another solution is to enable each ConcretePart to get its current price from the database or attribute file.
Single selection
The Single Choice PrinciPle is an inference of the OCP.
Single option:
Regardless of, a software system must support a set of options, ideally, only one class can know the entire alternative collection in the system.
Law 4: Liskov Replacement Law (LSP)
Using a function of a reference to a base class (super class) must be able to use them without knowing the specific derived class (subclass) object type.
[Function THAR USE Referennces To Base (Super) Classes Must Be Aable To Use Objects of Derived (SUB) Classes without Knowing IT]
Liskov replacement
n
Obviously, the Liskov replacement method (LSP) is based on the "polymorphism" I know.
n
E.g:
n
Method DrawShape should work with any subclass of Sharp hypends (or if Sharp is a Java interface, the method can work with any class that implements the Sharp interface)
n
But when we have to be carefully treated when you implement subclasses, we will not intend to violate the LSP. n
If a function does not meet the LSP, it may be because it explicitly references some or all subclasses of the superclass. Such functions also violate OCP because when we create a new subclass, you have to make changes to code.
LSP example
n
Consider the following Rectangle class:
n
What will the Square class now? Obviously, a square is a quadrilateral, so the Square class should be derived from the Rectangle class. Let us take a look!
n
Observe available:
Fly
The square does not need to use high and wide as an attribute, but in turn, it will inherit from Rectangle. Therefore, every Square object is wasting a point of memory, but this is not a major problem.
Fly
The SETWIDTH () and setHeight () methods inherited are not really suitable for Square because a square is the same. So we will need to rewrite SetWidth () and setHeight () methods. Have to rewrite these simple methods may be an inappropriate inheritance.
n
The Square class is as follows:
n
It is not bad. But let us inspect!
n
Test program output:
n
It seems that we violate the LSP!
n
Where is the problem here? The programmer who wrote the Testlsp () method made a reasonable assumption that changed the width of Rectangle and keeping it high.
n
When passing a Square object to such a method, it is obviously a violation of the LSP
n
Square and Rectangle classes are consistent and legitimate. Although programmers make a reasonable assumption for base classes, the methods they have written will still lead to the failure of design models.
n
You can't look at the solution in isolation, you must look at them according to the reasonable assumptions you designed by the user.
n
A square in a mathematical sense may be a quadrilateral, but a Square object is not a Rectangle object because a Square object is inconsistent with a rectangle object!
n
For behavior, a Square is not a Rectangle! A Square object does not have a polymorphic feature between a Rectangle object.
to sum up
n
Liskov replacement rule (LSP) clearly shows that all ISA relationships are related to behavior.
n
In order to keep the LSP (and together with the open-closed method), all subclasses must meet the desired behavior of the use of the base class.
n
A subtype must not have more restrictions of Base Type, which may be legitimate for the base type, but may violate the LSP!
n
LSP ensures that a subclass can always be used in places where their base categories!
