System Architect study note _ Chapter 9 _ serialization

Chapter 9 component-Oriented Software Design

9.1.1 terms and concepts

1. Component

The features of components are as follows:

Independent deployment unit.

As a third-party assembly unit.

No (external) visible status.

Independent deployment means that it must be completely isolated from its environment and other components.

Atomicity: components must not only have good cohesion, but also clearly describe their dependencies and services.

Cache has the following features: when it is cleared, it may not only reduce performance, but has no other consequences.

Building is essentially stateless. it is meaningless to load copies of multiple components in the same operating system process. At most, a copy of a specific component exists.

In many systems, the construction is implemented as a large-granularity unit. The wage management service program is a component, and the wage data is only an instance (object ), the practice of separating "models" and "instances" that are not easy to change avoids a large number of maintenance problems.

2. Object

The features of an object are as follows:

An instance unit with a unique identifier.

It may be in a status, which is externally visible.

Encapsulates your own status and behavior.

An explicit instantiation scheme is called a class, and an implicit instantiation scheme is implemented by cloning an existing object, that is, a prototype object.

All new objects must be set with an initial state. The code for creating and initializing objects can be part of a static process-class, called constructor.

If this object is used to create and initialize an object, it is called a factory.

The method specifically used to return other newly created objects is called the factory method.

3. Components and objects

A component usually contains several classes or unchangeable prototype objects. It also includes a series of objects.

However, components do not have to contain Class elements. They can even not contain classes, but can have traditional process bodies or even global variables.

The object created by the component-more specifically the reference to these objects-can be separated from the component and visible to the customer of the component. Component customers generally refer to other components.

A component can contain multiple class elements, but a class element can only belong to one building. It usually makes no sense to split a class and deploy it.

4. Modules

The maturity of the modular method marks its support for the separation compilation technology, including the correct type check capability across modules.

A module does not have the concept of Instantiation. In any case, a module can contain multiple classes. The inheritance relationships between classes are not limited by the limitations of the module boundaries.

The module itself can be used as the simplest component. These libraries are functional, not object-oriented.

A resource can be parameterized into a component. You do not need to change the component code to reconfigure the component. For example, you can use resource configuration to implement localization settings.

In some cases, a module is not suitable as a component. The component does not have an externally visible state, but the module can explicitly use global variables to make its State visible.

5. white box abstraction, black box abstraction, and reuse

In the white box abstraction, the Implementation Details of components can be modified by inheritance. In the white box abstraction, the implementation details are completely visible to the outside world.

In most systems, Application Programming interfaces (APIS) are equivalent to the black box reuse of these interfaces.

White box reuse cannot be easily replaced by other software because it depends on details.

A software component is an assembly unit with standardized interface conventions and explicit context dependencies. software components can be independently deployed and assembled by any third party.

6. Interfaces

An interface is a set of named operations.

A component can have multiple interfaces, each of which provides a service.

Do not introduce similar interfaces repeatedly.

The implementation of standardization may fail to achieve the optimal performance due to the clumsy bureaucratic "committee design" problem. The non-technical nature of market competition may also lead to the unsatisfactory results.

Interface standardization is the standardization of message formats, modes, and Protocols. XML provides a unified data format.

7. Explicit context dependency

The specific requirements for the deployment environment are called context dependencies.

8. Component Scale

Maximizing reuse also has a potential drawback-the explosive growth of context dependencies.

The more context dependencies, the fewer customer components that can meet the requirements of the component environment, reducing availability.

The component designer needs to find a balance between the two, and the evolution of the environment must be considered to make the component more vulnerable.

9.1.2 standardization and standardization

If context dependency can be widely supported, it is not a disadvantage.

1. General Market and Professional Market

Standardization in the general market is very difficult. To meet everyone's needs, network standards are the best example.

The standardization of the professional market is as hard as that of the general market. due to the small number of people involved, the market economy mechanism is not easy to play a good role.

2. Standard Component System and standardization

To play the role of standardization, We must minimize the number of other competing standards.

9.3 component framework

9.3.1 Architecture

The core components of the component architecture include interaction between components and the external environment, role of components, interface of standardized tools, and user interface of end users and deployers.

1. Role of the Architecture

The architecture is about the overall view of a system. It defines the overall immutability, specifies an appropriate framework, and limits degrees of freedom, the overall function, performance, reliability, and security considerations can be placed aside.

3. component system architecture features

The component system architecture consists of a set of platform decisions, a set of building frameworks, and the interoperability design between the component frameworks. A platform is an infrastructure that allows you to install components and component frameworks on it.

A component framework is a dedicated architecture that often implements some protocols to connect components.

Most atomic components will never be deployed independently, even though they can be deployed independently.

An atomic component is usually deployed in an integrated manner.

4. layered component architecture

The traditional vertical hierarchy increases abstraction and application-related properties from the bottom up.

Horizontal layering reduces the correlation between performance and resources and increases the correlation between structures.

Lightweight architecture focuses on one issue rather than covering all issues. If lightweight components support better scalability, their business value will be very great.

6. Component and Generative programming

The actual component boundary must be precisely controlled, including interfaces and required interfaces, and static dependencies between other components must be precisely controlled.

9.3.2 context-related combination construction framework

COM + adds the concept of a leasing thread "Suite", allowing only one thread to stay at a time, but multiple threads can stay in the "Suite" in sequence ".

Objects in the same transaction domain share a separate logical thread and a collection of separately shared transaction resources. Once a thread returns from the transaction domain, the transaction is either committed or terminated.

In COM +, if two components share a set of compatible contextual attribute sets, they can be considered to be in the same domain.

9.3.3 component development

Asynchronous Problem

The event distribution mechanism is responsible for receiving these event objects and sending them to other component instances of interest to them.

Multithreading

Multithreading mainly focuses on better allocation of program execution. The method to maximize performance does not rely on multithreading at all. Instead, it tries its best to process users' requests as quickly as possible.