Self-written framework 9: The ideal open source framework and design principles

The ideal open source framework
? She was supposed to be small, simple, to meet simply is Beautiful
? She should be good at growing up, and as she expands, she can get more and more plump.
? She should be a good tool to support, why take the time to do the tools can do things?
? She should be self-assembled, that is, as far as possible out of the configuration, but with a dependency can be used, the elimination of dependency disappears the automatic processing mode
? She should be modular, all content can be entered into the Jar package and released as a whole, and can support the hot deployment, can drive the car to change tires
? She should be in support of horizontal deployment, want to add the server, want to reduce the server
? She should have a good knowledge of the accumulation system, so that the use of the tiny framework of the more people use stronger, more use more cool
? She should be easy for enterprises to reduce development costs, easy for the technical manager to control the development progress, easy for developers to quickly get started
? She should avoid duplication of effort, and all software participants should not repeat things.
? She should be self-managed, it's best not to let the programmer configure the configuration that
? She should be a kind of "the crowd to find him 1100 degrees, suddenly look back, the person is in, lights dim place" development Framework

Design according to this goal
? Although the overall volume is relatively large, each of its modules is very small, making it very easy to master
? Its various components can be easily extended, through the expansion can continuously improve the processing capacity of the system
? Its tools have been very powerful, and it has become even more powerful.
? Whether it's a console or a filter, a Servlet, whether it's a process component or a UI component, or a UI component package, and so on, it can be self-assembled.
? Web Engineering is just a collection, except for configuration files and pom dependencies, there should be nothing else
Support for horizontal scaling while supporting the 7x24-hour operation
Start the team from the pyramid to the dumbbell type of change, high and low level of their respective roles
In the vast majority of cases, the only thing to do is to rely instead of configuring

To build the framework--design principles carding

1. COC principles

Tiny framework in the design of the full consideration of this principle, usually through a certain agreement to greatly reduce the amount of configuration or development, will generally be used. So in the tiny framework of the expansion, development, configuration process, will often find some "unspoken rules", if the use of these "unspoken rules", will play a multiplier effect. No tag comment user icon: Cskang Cai Shaokang Published: Convention over Configuration (CoC) – Convention is better than the collocation principle simply put, it is to use some well-known configuration methods and information as internal default rules. For example, Hibernate's mapping file, if the contract field name and class attributes are consistent, basically can not do this configuration file. Your app only needs to specify convention information, which reduces a lot of convention and has to spend time and effort on the long-winded things, configuration files in many cases the impact of the development efficiency.

There are few profiles in rails (but not no, database connection is a profile), and rails ' fans are 10 times times more efficient than Java development, which is probably the reason. MAVEN also uses the COC principle, when you execute the mvn-compile command, you do not need to refer to where the source files are placed, and after the compilation of the class file is not specified anywhere, this is the COC principle.

2. DRY"Don't repeat yourself" principle

The builders of the tiny framework have always hated doing things that are repetitive, so it's very inappropriate for developers to have duplicate content when developing based on the tiny framework. To this end the tiny framework has done a lot of work to avoid programmers violating dry principles, so in the tiny framework, all the work is done once enough. No tag comment user icon: Cskang Cai Shaokang Published:

Dry--don ' t repeatyourself Principle, literal translation "Do not repeat yourself" principle ^_^

Dry, in short, is not to write duplicate code. The principle itself is simple, but, for Ooad, it is of great significance.

The method used by dry is abstraction: abstracting the common things and extracting the code into one place. This avoids writing duplicate code.

As a typical example of a dry, if you need to initialize a member when a class is constructed, and then initialize it after something has been done, you can abstract the "initialization" into a method initial () and call it where it is constructed and needed.

While extracting duplicate code is a good start to take advantage of dry, the essence of dry is that a requirement is done with a part. When you try to avoid repeating the code, in fact, you should be using a piece of code to complete a requirement.

Why use the dry principle? Dry will bring great benefits to code maintenance. In the case of class initialization, assuming that the class modifies, increases, decreases, or modifies the member, if you do not write initial (), you may have to modify at least two places, and there may be inconsistencies in the modification, and maintenance costs are greatly increased. and write the initial () method, then as long as the central Modification initial () on the line.

Since dry is about "a method to achieve a requirement", is it possible to apply dry to demand analysis? Well, the answer is yes, and, personally, that's a very good idea. Multiple repetitive requirements can result in multiple duplicate or similar classes, resulting in duplicate code. So dry is not only applicable to the code, it is a widely applicable principle.

3. Subtraction subtraction principle

The subtraction principle is the one we put forward, meaning to do subtraction to the programmer. Generally, the lower the programmer, the shorter the working time, the weaker the skill, and the less experience. But in the actual work, you will find that the more the lower the programmer to do the more things, the more skills to use. Tiny builders believe that this is the reason why programmers are inefficient and poor in quality. So we think that the programmer should be subtraction, the more the bottom of the programmer to do things to be more single, the simpler.

4. subordinate obedience to superior principle

Maybe someone is laughing, this is the principle? Indeed, it is the principle, but the original subordinate service superiors are hanging on the mouth, and the tiny framework from the framework of the restrictions, so that subordinates must serve the superiors. These two points are mainly embodied in the process and page implementation, the superior manager can do the subordinate work content to implement the mandatory requirements, the difference is that the process is to adopt explicit inheritance, and the page is implicit inheritance of the way

5. Single principle

Almost everyone familiar with the tiny framework might ask the same question: why did tiny have so many projects? The builders of the tiny framework are also deeply aware that this will increase the amount of integration work, but the benefit of this is that a single principle can be enforced so that a module only solves the problem that a single module should solve, thus avoiding the problem of having different problems together to solve the problems caused by the beard and eyebrows. It also avoids inappropriate dependencies and template references.

6. Modular and automatic assembly principles

General software development, the entire integration process requires people to be careful, to match this with that, a little careless there will be the emergence of such problems tiny framework builders also often know this to the integration of the difficulties and the software development testing the enormous workload, so throughout the tiny framework of the construction process , we pay great attention to the automatic assembly of the integration process, which is required to be thrown in without tube and automatically integrated by the framework. Tiny framework builders know very well that modularity plays a role in the development, height, integration, release, and maintenance processes of software development, and is costly to save or spend. Therefore, the concept of business unit is proposed so that all content related to the module can be put together.

7. Centralized configuration principles

In the work of tiny builders for many years, the problem of being configured is often troubled, there are many problems in the development period due to improper configuration, in the test during the release and upgrade process, there are a lot of problems caused by improper configuration. In the tiny framework we have done a lot of work on the configuration, one is the COC method, if not, then the system default value; One is the centralized principle: the need to configure the needs of human needs to be centralized unified configuration; one for the configuration that does not require manual intervention, it is integrated in the jar package, As part of the publisher's published item.

Welcome to the framework Forum: Http://web.j2ee.top . The Code and framework information in this example will be shared in the forum. "Self-write framework" member QQ Group: 228977971, let us work together to understand the mystery of the framework!

Self-written framework 9: The ideal open source framework and design principles