Some object-oriented design rules
Bob Tarr Translation Outmyth
Law 1: Priority use (object) combination, not (class) 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 of the combination to obtain new features.
n Sometimes also known as "aggregation" or "inclination", although some authors give special meaning to these terms
n, for example:
F Aggregate: 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 its 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.)
F Inclusion: 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:
F According to reference (by reference)
F according to value (by value)
N C allows you to be included based on values or references.
n But in Java, everything is referenced by the object!
Advantages and disadvantages of combination
n Advantages:
F containers can only be accessed by interfaces that are included.
F "Black Box" multiplexed because it is not visible to the internal details of the object.
F is good.
F Implementation is relatively small. (Translator Note: It is relatively less dependence between the object and the container object)
F Every class is only focused on one task.
F By getting a reference to other objects that have the same type, (object) can be dynamically defined during operation.
n Diffility:
F thus leads to too many objects in the system.
F 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 Ultrafial (Class) can explicitly capture those common attributes and methods.
n Special classes (subclasses) are achieved by additional properties and methods.
Advantages and disadvantages of inheritance
n Advantages:
F is easy to perform new implementation because most of them can inherit.
F is easy to modify or extend those implementations.
n Diffility:
F destroyed encapsulation because this exposes the implementation details of the parent class to the child class.
F "White Box" is reused because the internal details of the parent class are often visible for subclasses.
F When the parent class is achieved, the subclass has to change. F The implementation of inheritance from the parent class will not change during operation.
COAD rules
For all the criteria of the following, they can use inheritance:
The N subclass expression "is a special type of ...", rather than "is a role played by ...".
An instance of the N subclass will never need to transmute as an object of other classes.
N subclasses are expanded for its parent class, rather than rewriting or abolishing (NULLIFY).
The N subclass does not extends only those functions that are only a tool class (Utility Class).
N For a class in which the actual problem domain is, the subclass is specifically referred to as a Role, transaction or device.
Inheritance / Combination Example 1
n "is a special type of ..." instead of "is a role played by ...
F failed. Passengers are a role that people play. Agent is also.
n Never need to transform
F failed. 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
F pass.
N Don't expand a tool class
F pass.
n In the problem domain, specifically, a role, transaction or equipment
F failed. Person is not a role, trading or device.
Inheritance is not applicable!
Use a combination to save!
Inheritance / Combination Example 2
n "is a special type of ..." instead of "is a role played by ...
F pass. Passengers and agents are all roles of special types of people.
n Never need to transform
F pass. A Passenger object will remain unchanged; Agent object is also.
N expand, not retroactive and abolishment
F pass.
N Don't expand a tool class
F pass.
n In the problem domain, specifically, a role, transaction or equipment
F pass. Personrole is a type of role.
Inherit is available here!
Inheritance / Combination Example 3
n "is a special type of ..." instead of "is a role played by ...
F pass. Book and purchase are a special type of transaction.
n Never need to transform
F pass. A RESERVATION object will remain unchanged; the Purchase object is also.
N expand, not retroactive and abolishment
F pass.
N Don't expand a tool class
F pass.
n In the problem domain, specifically, a role, transaction or equipment
F pass. It is a transaction.
Inherit is available here!
Inheritance / Combination Example 4
n "is a special type of ..." instead of "is a role played by ...
F failed. Book is not a special type of Observable.
n Never need to transform
F pass. A RESERVATION object will remain unchanged.
n extension, not retro and abolish F.
N Don't expand a tool class
F failed. Observable is a tool class.
n In the problem domain, specifically, a role, transaction or equipment
F does not apply. Observable is a tool class, not a class of a problem domain. .
Inheritance is not applicable!
Summary of inheritance / combination
N combined with inheritance is an important reuse method
N in the early days of OO development, inheritance is excessively used
N Over time, we find that priority use combination can achieve reuse and simplicity better design.
n of course, can be inherited to expand the set of composable classes.
n So 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
The N interface is an object that is known when it is called other objects.
n An object can have multiple interfaces (actually, the interface is a subset of all methods of the object)
N-type is a specific interface of the object.
N Different objects can have the same type, and an object can have multiple 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 Interface is the key to implementing pluggability
Implement inheritance and interface inheritance
n Implement 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.
The inheritance mechanism of N c is both inheritance and refers to the inheritance of the interface.
N C achieves the interface inherit 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 achieve designs that focus on object interfaces.
Benefits of interface
n Advantages:
F Client does not have to know the specific class of its use of objects.
F An object can be easily replaced with another object of (realized the same interface).
The connection between F objects does not have to hardbonize (hardwire) to an object of a specific class, thereby adding flexibility.
F loosen coupling.
F adds the possibility of reuse.
F Raise the chance of (object) combination because the object being included may be any class that implements a specified interface.
n Diffility:
The complexity of F design is slightly increased.
(Translator Note: The interface represents the relationship between "..." (Likea), inherits the relationship of "... is ..." (ISA), combining the relationship of "..." (HASA).) Interface instance
n The method refers to some 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 Act Think we should try to design a module that never needs to change.
n We can add new code to extend the behavior of your system. We cannot modify existing code.
n The module that meets OCP needs to meet two standards:
F Extension, "Open for Extension" (Open for Extension) - The behavior of the Open for Extension - module can be expanded to meet new needs.
F cannot be changed, ie "Closed for modification" (the source code of the module is not allowed to be modified.
n How can we do it?
F abstraction (Abstract)
F polymorphism
F inheritance (inheritance)
F Interface (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 Method is the true core of OO design.
n Combine this rule means the highest level of reusability and maintainability.
OCP example
n Consider the following methods:
N The above function is to calculate the sum of the prices in the various components in the form array.
n If Part is a base class or interface and uses a polymorphism, the class can be easily adapted to the new type of components without having to modify it.
n which will comply with OCP
N But when calculating the total price, if the financial department promulgates the motherboard and memory should use additional fees, how will it be done.
n What is the following code?
N This is in line with OCP?
n When each Finance is proposed, 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 One better idea is to use a PricePolicy class, by inheriting it to provide different pricing strategies: n seems that we have done will postpate to 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, for example:
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 a subclass, you must be cautious to make sure we don't inadvertently violate the LSP.
n If a function does not meet the LSP, it may be because it explicitly references some or all of the 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 Now, how will the Square class? Obviously, a square is a quadrilateral, so the Square class should be derived from the Rectangle class. Let us take a look!
N observation available:
F 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.
F inherited SetWidth () and setHeight () methods are not truly 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.
The n Square class is as follows:
n is not bad. But let us inspect!
n Test Program Output:
n It seems that we violate the LSP!
n Where is the problem? The programmer who wrote the Testlsp () method made a reasonable assumption that changed the width of Rectangle and keeping it high.
N generate problems when passing a Square object to such a method, obviously violating 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 cannot look at the solution in isolation, you must look at them based on the reasonable assumptions you designed by users.
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 From 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 (LSP) clearly shows that all ISA relationships are related to behavior.
n In order to keep LSPs (and with open-enclosed, all subclasses must meet the desired behavior of the use of the base class.
n One subtype must not have more restrictions in 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!
