Thinking about components

Cnblogs: Blogs about Components Github: Thinking about components

The words written in the front

I wrote the front end for years, used various component libraries, and wrote components myself. However, I did not have a deep understanding of the concept of component, so I referred to a lot of materials and combined with my own understanding to make a summary and summary. So, I have this article, from what is component, to what is componentization design in software, to what are the advantages and challenges in component design, and finally how to build a set of excellent component system. Everyone’s idea is not the same, my induction may not be perfect, only as your reference, but also welcome you to add.

What is a component?

This is our real life, the most image of the most appropriate object.

Figure 1: it is a system driven by gears. Each gear exists independently. If a gear fails, we just need to replace it with a good one, and the system can work again.

Figure 2: is a personal PC motherboard, we are also particularly familiar with, for each component inserted in the motherboard of a separate function (such as graphics card, CPU and so on), if a bad one, can be replaced with a good, through the slot replacement, can also run up.

So there are many component entities in life. Let’s look at these definitions of components:

1. A combination of parts for assembling the whole machine, component or component

2. A group of components assembled together to form a functional unit in an electronic or mechanical device

3. The often more or less repetitive parts of a product (such as a bookcase or cupboard) that are assembled

4. One of several parts that can be assembled or reassembled

These are all things we can see, we can touch, and then we go out of the reality of the representation, up to a higher level to see the problem (this is also called abstract)

Figure 3: it is a complete functional department diagram of the company. It’s a structure that’s made up of people who are responsible for the various functions that drive the company. We can abstract this a little bit. Each of the smallest functional leaders is a minimal component, which is assembled into a department component; Together, these components drive the company’s system.

We summarized and sorted out the information and came to the following conclusions:

1. In terms of appearance and function, they are independent parts, which may be parts or originals

2. Behaviorally, they have the property of assembly and can be combined with other components

3. It can be reassembled and reused

Of course, we do software design by referring to reality, abstract into software design, and then according to the landing environment, to achieve the componentized design idea, predecessors have been on the road, to explore the land, also obtained some practical theories. Such as component-based Software Engineering (CBSE) or component-based Development (CBD) software Development paradines, If you’re interested, you can check it out for yourself.

These are the previous definitions of components in software:

1. An opaque functional entity that can be assembled by a third party and conforms to a component model. — Carnegie Mellon University

2. It is a software entity with relatively independent functions, interface specified by contract, and obvious dependence on context, which can be independently deployed and assembled in the software system. — Computer Encyclopedia

3. Is an assembly unit, it has a reduced specification of the interface, and explicit dependency environment. Builds can be deployed independently, assembled by third parties. — Works on software components

4. As self-contained, programmable, reusable, language-independent software units, software components can be easily used to assemble applications. — Baidu Baike

5….

Each conclusion addresses the abstractions of its own stable software domain, and we can see more definitions of the concept of a component. So let’s make a summary of these conclusions what are the properties of components?

1. Highly cohesive, opaque — You don’t need to know how to make this thing, just how to use it

2. Contract to the outside world – With specifications, know that something gives you what you need and becomes what you want

3. Functional independence — a relatively general description of how something is to be used

4. Environment dependency – Environment dependency is important

5. Reusable — can be used multiple times

6. Assemblable — You can make other things with other things

What components should be in a component system?

Atomic components: Atomic-level components, single function, cannot be further split.

Composite component: a group of components that perform a function.

Slot components: Infrastructure provided for the assembly of components to complete a function.

Extend component: Derive a new component from an existing component, add new capabilities to the existing component, or change the functionality of the existing component.

Adaptive components: Use adaptive components to encapsulate different components to ensure the consistency of external contracts

Once you have a component definition, you know what a component is, what features it has, and finally, what categories of components are there in the system. We know about components, but then, how do we apply componentized design ideas to design our systems?

What is component design philosophy?

The demand scene is domatized and the scene field is modularized to meet the requirements of the system, and the maximum reuse of the stable field is taken as the purpose, so that it can build an independent solution of the whole system through combination and splitting

As shown in figure:

Examples (using front-end systems) :

For example, we need to make a simple front-end active system, which requires logging in to the system, viewing activities, creating activities, modifying activities, and deleting activities.

Step 1: Domain the requirements scenario

Login functions — Form submission, View activity — Data display, Create activity — Form Submission, Modify activity — Form Submission, Delete Activity — User behavior. We abstract these functions into three domains: forms, data presentation, and user behavior.

Step 2: Split the scene domain module

By simply splitting an example from a form field, we can split the form field into many modules, such as text input module, password input module, radio module, multiple selection module, drop-down selection module, and so on

Step 3: Summarize commonalities and analyze differences

Use the text input module and the password input module as examples. We need to generalize the commonalities: they can all be inputs. Analyze the difference: one input text is visible and one input text is not. The conclusion: Design an input text component, open the contract to the outside world, and if you tell me you need to make the input invisible, I’ll do some internal processing to cover things up.

Output components:

Component: Input component

Contract: Whether the input needs to be occluded

Function: Input text

Domain: Form input usage

Design Significance:

Component design in this way, if the whole system has such a stable field, then the meaning of these components is the best for the system, not only meet the needs, but also can maximize the reuse of functions.

Benefits of componentized design

1. Reusable, for a function independent and single component, do not need to spend other resources, can directly use components to achieve the effect

2. Expansion and replacement, for system maintenance and update, can be extended through the base components, and then can be replaced by components to update the system

3. The possibility of complex cooperation, independent separation of modules and components, the separation and combination of components to build a complete system, so that large-scale project cooperation is possible.

4. Improved efficiency, which includes more efficient management of software complexity, faster time to market, as well as higher productivity (iterative efficiency), higher quality, and so on

The challenge of componentized design

1. The time and effort required to develop components.

Developing a component is not a single feature or page, and the cost of time and effort required to develop a component is far greater than the cost of just completing a feature.

2. Development of nondescribable requirements.

Demand for software phase, in the real development, can’t be all requirements specifically, so for these uncertainty, not describe the requirements of development, is a great challenge for a component, because the area is not stable, may eventually abstract component is uncertain and changes, component changes caused by such costs are rising sharply.

3. Conflict between usability and reusability.

There is no fixed measure of the resulting components in the system. It may be that components are fully available at this stage, but it is up to the developers themselves to determine whether future changes and outbreaks need to be proactively reserved and extended to achieve a higher level of reusable conflict.

4. Component maintenance.

Component maintenance can be ignored in small projects, but in large projects, if maintenance needs to find traces of their own code by code, then such component design and development is not ideal, but contrary to the original dream of component design.

5. Reliability and fault tolerance.

Because the components are relatively independent, we do not know the internal changes, so we measure whether a component is reliable except whether it meets my needs, and whether the component is unreliable and unexpected reaction mechanism can accurately locate and degrade fault tolerance (losing some functions and ensuring the perfection of other functions).

6. The challenge of sustained growth.

Component development is to reduce all kinds of burdens in development, but in the continuous growth of components, components themselves will also become a burden, whether there is a perfect handling mechanism for their burden, can be held in the continuous growth.

7. Component specifications.

The development style of each siege lion is different, and the specification of components is of Paramount importance in such a collaboration, reducing the cost of multiple sets of understanding.

8. Parse the “kernel” of the component.

The robustness of the core brain is the soul of the whole system. This is not to say, hang up directly game over! There are real challenges, but we can solve these challenges through a series of methods and specifications to make componentized design better serve our system.

How to design a good component system?

There are two directions for building component systems: Designing a set of components that meet the requirements of the system Designing a set of components that can be used in general

List some factors to consider in either direction:

1. Unified closing and management components

For any system, rapid iteration and growth is bound to bring explosive growth of components, if the components can not be unified closed, it may bring low utilization rate of repeated development of components (may be 80% the same as a component function, only need to expand an atomic component can solve the problem. Or not knowing there is a similar component somewhere else that can be satisfied leads to secondary development). Good management maximizes the advantages of component development, while bad management leads to the question, “What’s the point of adding more complexity to componentized development?”

2. Component upgrade and update, and even replacement can be controlled

It’s a great development experience to iterate, to throw away old baggage and embrace a new era. But will also bring, development for a while fun, XXXXX (we experience). Each component upgrade, before there is no complete scheme, it is bound to consider the compatibility of components, otherwise EVERY time I iterate a new component, the components used are not compatible, I need to rework from scratch to replace the used components. That’s it. However, only after a complete gray scale scheme can be implemented, such as the overall upgrade of the 2.0 version of components, can the new features be used, and there are enough components upgrade and migration schemes to ensure that the upgrade has no impact. This control maximizes the benefits of component development.

3. Fault tolerance, processing of fault tolerance schemes for core and non-core components.

Fault tolerance, also divided into many ways, in the traditional Window large system, the fault tolerance of core components is particularly low, because some are core components, such as CPU, lose this can not play. But for USB slots, audio output slots and so on, you have a very high fault tolerance, so it doesn’t matter if you break, my system runs. It’s just that I will disable the functionality provided by your component. Therefore, component fault tolerance needs to be evaluated for the system itself. There is no unified solution.

4. Security, in addition to the impact of external exposure contracts, should be sandbox internally

This is just like the browser, I’m only affected by my own conventions and contracts, otherwise nothing else can affect me. In this way, there will be no non-intrinsic changes, and the components themselves will have problems, decouple everything, and achieve inner convergence and independence.

5. Documentation, component self-description, functionality, and external contracts

No documentation is no self-introduction, who knows who you are, what you can do, can not be competent for my solution.

6. Trust, component development to any developer, must reduce the possibility of risk, and comprehensive testing.

The ultimate implementer of component design is the developer, and if a component is introduced into the entire system build without being evaluated or fully tested, it introduces a significant risk that you will spend more time controlling the problem later on. This is also a problem that qualified software development engineers need to evaluate.

7. Adapter and glue code: package more complex composite general components. Adapter design and glue code should be combined to ensure compliance with component specifications

Reuse of components and assembly between components will surely lead to the emergence of more components and more complex components, which will naturally lead to higher complexity. But based on the component specification and development specification of this system, you can use more glue code to adapt into the model consistent with the components of this system, so that you and I are the same, learning and using costs are not high. In many industries, the original class of a component is created, and the basic functions and contracts of the component are defined. All components will inherit this original class to achieve the consistency of components.

8. Friendly, more developer-friendly, cheaper to learn and use

In software development, the downstream consumers are the programmers, the believers who carry forward what you build, and your preaching needs to be more friendly. Otherwise, the coarser voice will appear in the programmer’s heart, “You come up to give me a stick, write write write to give me a stick, also play an egg!”

9. Stability, everything to stability, away from dangerous code

I believe that every company will amway such thinking, production code is able to experience the wind and rain, is able to carry the mountain. Your components have to do the same, too many problems, eventually it becomes unmaintainable, too expensive, all kinds of weird problems, etc., and then you get killed.

10. Distinctive, unique system has its own characteristics and highlights

This is generally optional, after all, you want to wheel, may be predecessors have made N, you have what characteristics to let others to choose you, use you. Is it because of love? Is it love?

11. More in line with user habits

Stand in the perspective of others to think about the problem, to know what others need, in order to let others can not leave you.

Design a set of components that meet the requirements of the system (Requirements Oriented Component Development)

The first element: demand as the center, to meet the demand as the measurement standard

1. Excavate the components in line with the system to make basic components and sample components.

The components of a system are rarely built from scratch, because of the cost. In the rapid iteration of business, some third-party libraries and packages that provide atomic components are generally selected to form a component system that meets the requirements of the system by packaging the components of the third party.

2. Build requirement components to adapt to the component model and requirement specification of the existing system

Different components define their own different external interface contracts, and the ever-changing contracts can cause clutter, confusion, and error. No matter which side of the component, and even their own components, need to comply with the system’s component model specification.

3. Optional expansion, support expansion and contraction in the scope of demand scalability

In the development of requirements components, there is a clear understanding of requirements evolution and even rollback. On this basis, optional extensions can be built into component development, and requirements can be scaled and rolled back.

4. Don’t design more than enough

Everything is subject to demand, satisfaction is the best.

5. Higher self-description, component design is more coupled to requirements, requiring more description

Due to the complexity of the business coupled with more unique rules, such components require more self-descriptive content.

Designing a common set of components (Component development for reuse)

The first element: take the general as the center, solve similar problems with abstract commonness as the measurement standard

1. Relational stable domain abstractions

General, that is, stable, consensus-forming areas. So a generic component is also a component abstracted from a stable domain

2. Make components generic

A generic component is an application created to solve a particular problem, and this application is generalized to relate to more general business objects

3. Control complexity and readability

The more common a component is, the more reusable it is, but the more complex the pair, and the less readable it is

4. The consistency

Unified interfaces and contracts, and even unified external exception exposure, will only be possible if everyone is more consistent

Adaptability to 5.

Adding a configuration interface to a component provides a possibility for component scaling

In view of the challenge of component design, we have never stopped the pace of progress because of the challenge, so combined with the experience and understanding of predecessors and their own development, for want to build a set of excellent component system to provide a guide and reference.

Afterword.

I have done analysis on all front-end components on the market, which has indeed solved our high efficiency in a common scenario. However, after understanding the components themselves and looking at all components objectively, I found some problems as follows:

1. Lack of underlying capacity. Based on scenario-based components, only in the suitable scene to find the appropriate scene components, but a scene is changing, although finally we can enumerate all the scenes, whether this change can be met in one way.
2. Component replacement capability. Many of the scene components in the market are assembled by many small scene components. Can we directly replace the component without changing the component itself in the same way of contract through external exposure method?
3. The ability to extend and spawn, the smallest scene component, is there a way to spawn variants. Buttons, for example, can expose “controlled patches” that I can turn into any shape, straight, square, round, oval, etc., instead of just writing to death and waiting for iterations.
4. And so on…