[Software Engineering] design module

Chapter 6 Design module

6.1 Design principles

• modular （module） And components (component)
  • modular ： Define input 、 Program entities for output and properties
  • artifacts ： Reusable software components

Design principles It refers to the guidelines for decomposing system functions and behaviors into modules 6 Three important principles :

modularization 、 Interface 、 Information hiding 、 Incremental development 、 abstract 、 generality

modularization

modularization It is a principle to separate the irrelevant parts of the system , So that each part can study independently , Also known as separation of concerns

• If the principle is applied properly , Each module has its own unique purpose , And relatively independent of other modules

– Each module will be easier to understand and develop

– Fault location is simpler (because there are fewer suspect modules per fault)

– System modification is simpler (because a change to one module affects relatively few other modules

• To determine if the concerns are well separated , We use two concepts to measure module independence ： Coupling degree and Degree of cohesion

Coupling degree

coupling Measure how closely different modules depend on each other .

There is a strong dependency between the two modules, which is called Tightly coupled , There is less dependency between two modules, which is called Loose coupling , Modules that do not have any dependencies are called Uncoupled . The looser the coupling , The smaller the connection between modules , The more independent the module is .

The strength of the coupling depends on the following factors ：

（1） A reference from one module to another **

Such as module A Call module B So module A The function of depends on the module B The function of

（2） To transfer data

（3） Exert control

（4） Interface complexity

Indirect coupling

Both modules can work independently without the existence of the other , This indicates that there are no connections between the modules , The lowest degree of coupling .

Data coupling

If two modules exchange information with each other through parameters , And the information exchanged is just data , So this kind of coupling is called data coupling . Data coupling is the simplest form of coupling , The coupling between modules is low .

Tag coupling

The parameters passed between the two modules are data structure variables , For example, array names in high-level languages 、 Record name, file name, etc , This connection between modules is called tag coupling .

This coupling should be avoided or eliminated by other methods in the design , But sometimes because of other functions , Tag coupling is inevitable .

Control coupling

What is passed between the two modules is Control information , Such as switching value 、 Logo, name, etc , The coupling between these two modules is called control coupling .

Public coupling

A group of modules all access the same The common data environment , Then the coupling between these modules is called common coupling . A common data environment can be a global data structure 、 Shared communication area 、 The common footprint of memory 、 Files on any storage medium, etc .

If a module only transmits data to the public data environment , The other module only extracts data from the public data environment , Then this kind of public coupling is called loose public coupling , Here's the picture a Shown

If the two modules transmit data to the previous public data environment and extract data from it , Then this kind of coupling is called close common coupling , Here's the picture b Shown .

Such as using common coupling , Loose public coupling should be used as far as possible

Content coupling

Content coupling is the highest degree of coupling , If , Content coupling occurs between the two modules ：

① One module directly accesses the internal data of another module .

② The first mock exam module does not pass through the normal entrance to another module .

③ Part of the program code of the two modules overlaps

Degree of cohesion

cohesion It's a measure The degree to which various elements in a module are closely combined with each other . The more cohesive a module is , It indicates that the stronger the association between the elements within the module

To gather by chance

Each element inside the module is functionally irrelevant or loosely related .

Accidental cohesion is considered the worst kind of cohesion , The drawback is that ： The module is not easy to understand , Difficult to maintain , Not easy to reuse .

Logical cohesion

The tasks completed by a module are Logic The same or similar class is called logical cohesion . The called module in the figure below is a logical cohesion module , It determines to execute corresponding functions according to the input control information

Time converges

A module contains the information required in Same time period Multiple tasks performed in , The cohesion of the module is called time cohesion . for example , The initialization of multiple variables is implemented in the same module .

advantage ： There is no need to select parameters , All tasks can be executed in any order , The logic is simple .

shortcoming ： This module combines many unrelated tasks , Once the module fails , It is difficult to directly determine which task failed .

Process cohesion

The processing elements within a module are related , And it has to be Execute in a specific order , It's called process cohesion . for example , When using flow chart to divide modules , If the loop part of the same process is completed in the flowchart 、 Judgment part 、 The calculation part is divided into 3 A module , Then this 3 The first module is the process cohesion module .

6.2 Object oriented design method

Process oriented :SP

object-oriented ：OOP

An overview of object-oriented design principles

You must take one

Principle of single responsibility

In software system , A class is only responsible for the corresponding responsibilities in a functional area

In terms of a class , There should be a reason for his change

The responsibilities of the class mainly include two aspects ： Data responsibility and behavior responsibility , Data responsibility is embodied by its attributes , And the responsibility of behavior is embodied by its methods . The principle of single responsibility is to achieve High cohesion 、 Low coupling Guidelines for , It can be found in many code refactoring techniques , It is the simplest but most difficult principle to apply , The designer needs to discover the different responsibilities of the class and separate them , The multiple responsibilities of discovery class require designers to have strong analysis and design ability and relevant reconstruction experience .

Example ：

Opening and closing principle

A software entity should Open to expansion , Turn off for changes .

That is to say, when designing a module , This module should be able to be extended without modification , That is to change the behavior of this module without modifying the source code . In the definition of opening and closing principle , Software entity can refer to a software module 、 A local structure of multiple classes or an independent class

Richter substitution principle

All reference base classes （ Parent class ） Must be able to transparently use objects of its subclasses

If you can use base class objects in software , Then you must be able to use its subclass object . Replace the base class with its subclass , The program will not produce any errors or exceptions , The reverse is not true , If a software entity uses a subclass , So it doesn't have to be able to use base classes .

Richter substitution principle is one of the important ways to realize the open - close principle , Because where base class objects are used, subclass objects can be used , Therefore, try to use base class types to define objects in your program , The subclass type is determined at run time , Replace the superclass object with a subclass object

Dependence Inversion Principle

– Dependence Inversion Principle (Dependence Inversion Principle, DIP) Is defined as follows ：

• High level modules should not rely on low level modules , They should all depend on abstraction . Abstractions should not depend on details , Details should depend on abstractions .

– Another expression is ：

• To program for an interface , Don't program for implementation .

– Simply speaking , The principle of dependency inversion means ： Code depends on abstract classes , Don't rely on specific classes ; To program against an interface or abstract class , Instead of programming for specific classes .

Composite reuse

Try to use object combinations , Instead of inheritance to achieve reuse

Dimitar's law

Also known as the minimum knowledge principle – There are many ways to define it , Several typical definitions are as follows ：

•(1) Do not mix “ A stranger ” speak .

•(2) Only communicate with your direct friends .

•(3) Every software unit has the least knowledge of other units , And limited to those software units closely related to the unit .

Demeter's Law means A software entity should interact with as few other entities as possible . such , When a module is modified , It will affect other modules as little as possible , Expansion will be relatively easy , This is a limitation on communication between software entities , It requires limiting the width and depth of communication between software entities .

6.3 Object oriented design pattern

** Design patterns （Design pattern）** It's a set that's been used over and over again 、 Most people know

Of 、 Catalogued 、 Summary of code design experience .

Why advocate design patterns ？

The root cause is for code reuse , Increase maintainability .

Design patterns contribute to the understanding of frame structures , Mature frameworks often use multiple

Design patterns .

• Design patterns are divided into three major types from the perspective of application

– Create pattern

– Structural mode

Behavioral patterns

Create a model of design

Single case model

Ensure that a class has and only has one instance , Provide a global access point

Factory method (Factory Method)

The parent class is responsible for defining the public interface for creating objects , Subclasses are responsible for generating concrete objects , Delay the instantiation of the class to the subclass

Abstract factory (Abstract Factory)

Provide a unified creation interface for a product family . When you need a family of products , You can select the corresponding series from the abstract factory to create a concrete factory class

Builder pattern (Builder)

Separate the construction of complex objects from their representation , The same build process can create different representations . Allows users to build complex objects simply by specifying their type and content , The user does not know the specific internal construction details

Archetypal model

adopt “ Copy ” An existing instance to return a new instance , Instead of creating a new instance . The copied instance is what we call “ Prototype ”, This prototype is customizable . Prototype patterns are often used to create complex or time-consuming instances , Because in this case , Copying an existing instance makes the program run more efficiently ; Or create equal values , It's just the same kind of data with different names

Structural design pattern

• Structural patterns are about the structure of classes and objects , It uses inheritance mechanisms to combine interfaces or implementations （ Class structure pattern ）, Or by combining some objects , In order to achieve new functions （ Object structured mode ）

– synthesis （Composite） Pattern ： Define an interface , Make it available to a single object , It can also be applied to object groups composed of multiple single objects

– decorate （Decorator） Pattern ： Add some additional responsibilities to an object dynamically , It's like adding decorations to an object , Perfect its function

– agent （Proxy） Pattern ： In software system , Some objects sometimes cross the network or other obstacles , And can't or don't want to directly access another object , Direct access will bring unnecessary complexity to the system , At this time, an intermediate layer can be added between the client program and the target object , Let the proxy object do everything instead of the target object , This is the agency （Proxy） Pattern

– Enjoying yuan （Flyweight） Pattern ：Flyweight Is a shared object , It can be used in different contexts at the same time （Context） Use

– appearance （Facade） Pattern ： Appearance patterns provide a higher level for subsystems 、 A simpler interface , Thus, the complexity and dependency of the subsystem are reduced . This makes the subsystem easier to use and manage . The facade assumes responsibility for interacting with classes in the subsystem

– bridge （Bridge） Pattern ： The purpose of the bridge pattern is to separate the abstraction and implementation of the problem , Solve the problem of explosive subclass growth by using aggregation instead of inheritance

– Adapter (Adapter) Pattern ： Adapt the interface of a class to the interface expected by the user . An adapter allows classes that cannot work together because of interface incompatibility , The approach is to wrap the class's own interface in an existing class

Behavioral design patterns

• Focus on solving the communication relationship between class entities , I hope to describe a control process in an object-oriented way

– template method （Template Method）： An algorithm step is defined , And allow subcategories to provide implementation for one or more steps . Let subcategories without changing the algorithm architecture , Redefine some steps in the algorithm

– The observer （Observer） Pattern ： Defines one to many dependencies between objects , When the state of this object changes , Multiple objects receive notifications , Opportunity to give feedback

– iterator （Iterator） Pattern ： Provides a way to access elements of an aggregate object in sequence , Without exposing the internal representation of the object

---

The singleton pattern

Characteristics of singleton design pattern ：

1. The singleton design pattern ensures that a class has only one instance ;

2. To provide a global access point to access instances of this class of objects .

The most important thing about singleton mode is to Ensure that a class has only one instance and that the class

Easy to access .

A global class makes an object accessible , But doing so will not prevent

You instantiate multiple objects .

1. In order to avoid other programs creating too many objects of this class , It is forbidden to build other programs first

Create an instance of this object （ Privatize the constructor ）.

2. In order to facilitate other programs to access the objects of this class , You have to customize one in this class

object , from 1 It can be seen that the object is static Of , And provide access to the outside world .

Hungry Chinese style ( summary )

Object preload , Threads are safe , When the class is created, the object is generated ,

Calling the method to get the object instance is fast , The code is concise .

Slacker type ( summary )

Object delay loading , Efficient , Instantiate objects only when they are used , if

Improperly designed threads are unsafe , The code is relatively complex , First addition

The reaction is not fast when loading class objects .