Framework Design Experience-do not make too many assumptions about the framework

Frameworks are often produced like this: We have a lot of experience in developing a certain type of applications and have developed some of these types of applications. We summarize the common features of these types of applications, extract it to a high level for reuse. This "High Level" is the prototype of the framework. With the accumulation of our experience, the framework will continue to improve and develop. The framework, as its name implies, is the skeleton of an application. The quality of the framework selected directly determines the quality of the application built on it. After a framework is determined, we add "blood" and "meat" to the gap of the skeleton to become an application.

The Framework comes from applications, but is higher than applications.
What I want to talk about today is that, because the framework originated from applications, we often unconsciously make many assumptions about the framework when refining the framework. These assumptions come from some potential "rules" or constraints in the specific application of the incubator framework. Why? Because we often hope that after the framework is used, it is very easy to rebuild the application that incubated the framework based on the framework. This simplicity may occur in two situations: first, you have successfully abstracted a very good framework; second, the framework you abstracted is closely coupled with the application of the incubator framework. Without the experience of designing the framework, it is inevitable that we fall into the second situation.

The closely coupled framework and the application of the incubator framework, in other words, is the assumption that the framework has made many specific applications. The most direct consequence of designing a framework in such an environment with too many assumptions is that it reduces the reusability of the framework. The purpose of refining the framework is to make it reusable in similar applications, and designing the framework based on too many assumptions will greatly reduce this beautiful goal.

A very specific phenomenon that the framework has made many assumptions for the application is that the framework has gone beyond the proxy and has taken over what the application was supposed to do. This is a typical thankless approach. The more advanced the framework, the more simple it may make the development of an application easier, but it will add unnecessary constraints and burden to other applications that want to use the framework more.

The framework only does what to do, and what to do depends on the judgment of the designer. the correctness of the judgment depends on the experience and ability of the designer.

When designing a framework, we often provide many built-in components in the framework. However, the framework should not force the application to use any of the most important and core components. Instead, the framework should allow applications to provide custom implementations of components to replace the built-in components. This can be easily achieved through the interface design and exposure of components. For example, our framework can specify which fields must be included in the message header messageheader, but the framework cannot force messageheader to include only these fields. This difference is exactly the difference between interfaces and implementations (classes. The framework provides a series of interfaces and the interconnectivity between these interfaces to form a skeleton; the application implements these interfaces to form "blood" and "meat" to fill the skeleton to get an "organism ".

I have talked so much about it. Here are two examples. These two examples are about esframework.
In the first example, esframework was positioned as an application framework for some time and expected to be applicable to all C/S applications. Therefore, esframework contains a lot of application-related things, esframework becomes more and more complex and huge. Just as the medicine that can cure hundreds of diseases cannot cure any disease, the framework that can satisfy all applications will hardly be used by any application. The solution to this error is to locate esframework in a simple communication framework, which will greatly broaden its reuse scope. (For more details, see the latest esframework development-esframework System)

The second example is that in earlier versions of esframework, there is an enumeration named servicetype, which classifies all messages. To be honest, this classification is very suitable for IM systems, but it is not necessarily suitable for other C/S systems. Esframework also provides a built-in message processor (details) for this servicetype category ). How stupid this approach seems to be! In later esframework versions, esframework does not interfere with how messages are classified, and the message processors that should not exist are also deleted. Instead, you can use datadealerbaglist to add any message processor to the application, as long as the application correctly matches the message processor with the message type.

After the two examples are completed, let's conclude that our first experience is: do not make"Too many", Rather than: Do not make"Any. A framework without any assumptions. from another perspective, it is a 10 thousand-capable framework that can solve any problem. We know that such a framework does not exist, even if it exists, it is also useless.
Do not make"Too manySo what is "too many? With many features/components, we can tell at a glance whether it should exist in the framework or be handed over to the application. However, there are also some features/components, and their location is not so clear. At this time, the trade-offs of designers are required. This trade-offs are exactly what best reflect the internal strengths of designers. No wonder some people say that software design is also an art, because you may encounter trade-offs anytime, anywhere! (EachProgramThey all want to be architects, but the architects are not so good, because architects, like an artist, need to make a lot of appropriate trade-offs. If anyone can make the same level of decision as you do, the decision you design will be worthless. The beauty of Software art comes from trade-off ))