Code automatic generation and abstraction
Hoping (original)
basic concepts
Abstract importance in software development is self-evident. If a system has the right abstraction, then this system is more likely to understand, it is easier to maintain, and it is more efficient to develop, and most important is more easier to make things. Grady Booch even thinks that abstraction is the most effective means of cope with software complexity. When facing a complex system, only one layer of abstraction level (of course, if it is correct abstraction), then the system will immediately become clear, simple, understand, develop, and maintain it easier. However, it is worth noting that although there is a correct abstraction, it can greatly reduce the difficulty of understanding, development and maintenance, but if you want to get a correct, suitable abstract is very difficult.
When the code is automatically generated, most people may immediately think of such a situation: as long as the system's needs are acquired, the system is automatically generated from these requirements. This idea is very good, but in the current level of scientific development (this technology is not only software technology, it is still closely related to the biological foundation of people). There is a huge gap between demand and accurate formal specifications that automatically convert to code. This conversion work can only be completed independently by people. Therefore, this technology can only be a myth in the current. Our code automatically generated in this article is for a relatively limited area, that is, demand has been correctly understood and converted into an abstract model in the field of solution. The code automatically generates is not to replace some software development of the system, it is just a tool that supports abstract tools.
Field Specific Language (DSL)
In fact, everyone is inadvertently using this tool in the daily software development. When we use the object-oriented language to develop software, we work on an abstract level. With this abstraction, the software we have written will be more expressive, it is more concise. For example: When we write down the following code line: Class Cat Extends Animal. We want to express Cat Is A Animal, object-oriented languages provide us with strong support. This abstract implementation details are completed by the compiler, we don't have to care. In this way we can develop and communicate in a higher, more direct, easier to understand abstract levels, and greatly reduce opportunities for errors. When we use a language that supports generics or AOP, we work on another abstract level. For example: When we write down the following code:
Template
T add (t, t)
We want to express the sum of the variables of two types T, regardless of the specific type of Types. Think about it, if the language does not support this expression specification, how many similar ADD methods do we have to write. With this expression of the expression, we can express our intentions directly, and the specific conversion work has a compiler. Also, if we have developed software development in the environment that supports AOP, we only need to use the AOP language specification provided by this environment definition of our hopes (it is an abstraction), the surplus code is written and inserted. Help us from this environment. Although the compiler or the development environment is actually a large amount of repetitive code in the underlying generation, the abstraction specification of these code is only one, and it is the only abstract specification based on the development, maintenance, and communication. Repeated implementation details are invisible to developers and are consistent with the abstract specification. It can be said that in the head of the developer, it is not repeated. Therefore, it is strongly supported "Once and Only Once" and DRY principles. Imagine if the language does not provide this description specification, then we have to write how many embarrassments, difficult to understand, repeated code can describe the concept we want to express. The abstraction mentioned above is some relatively universal mechanism, so it is generally supported by language. It is also a generality of its effectiveness. In general, some of the above abstraction mechanisms are only for the developer group, and expression using these abstract mechanisms is also generated by the compiler to generate the underlying execution code. However, there is an abstract expression more important, and its role is to communicate and communicate between developers and customers. Say it is important because it is closely related to whether the system to be developed can truly meet the customer needs closely. This abstract expression is closer to specific problems, and therefore also referred to as domain-specificilage (dsl). For example, if we develop a financial system, then we can use a financial term and its relationship to portray some of the business logic in the financial field, then not only expressly concise, more, more important, more important, customers It is more likely to understand and communicate more easily with customers. Again, if we have to develop a scientific computing system, if we have a set of vocabulary describing the scientific calculation, it will not be easy, naturally, and more efficient. After this DSL, the rest is to implement a compilation / interpreter yourself to automate DSL into target languages. Since this DSL is generally limited to a particular field, it is not difficult to compile the compilation / interpreter.
A keen readers will certainly find that we support the object-oriented (OO), generic (GP) or aspect-oriented (AOP), in fact, is also one of DSL. Only, they are more generous, and are unrelated to the fields of the actual problem facilities. Their role is to improve the abstract levels described in some general issues, and also provide a foundation for the abstracts of the problem.
Self-up and down?
Writing here I suddenly remembered a very interesting question, that is, everyone is often arguing from top to develop and develop. It is generally believed that some of the top-down development methods is more objective, and it is also natural. In fact, it is very risky, one is that there are many pre-imperative purposes that are likely to be itself, and when these pre-envision is implemented to the bottom layer or unable to be achieved. The result is generating a system with a large amount of redundancy, ugly adhesive layer code. The bottom-up method of using DSL thinking has a lot of benefits that you may have not thought. You can implement a single word in some DSL first, then implement some more units, and try to combine these elements into larger domain logic, and the system implemented according to this method is more simple, clear, clean, Even more easily reuse. In general, if you want to use DSL development, dynamic language is very useful (Python, Ruby is a good choice, in www.martinfowler.com/bliki, Martin Fowler's relationship between dynamic language and DSL In-depth, interesting description). Since the bottom, it is actually changing, expanding the development language, making it suitable for the problem facing. When you have the development of a software system, you just put the procedures you think directly to the implementation language, and you have continuously enhanced the language, making it more close to the procedures you think, and expressed more simple Directly. For example: You will think that if there is this operator in the language, it is clearer, it is clearer, concise, then you will build it. In this way, language and programs will evolve together until both can form a perfect match relationship. Finally, your program seems to be developed using language specifically designed. When language and programs are suitable for each other, the written code will be clearer, fewer, more effective.
It is worth noting that the design is designed to be top-down designed, and the same procedure is not imposed on different order. When designed from bottom to do, you will often get a procedure for design and from top. The resulting unique Monolithic program, but a more "big" language with more abstract operators and a more "small" program written in this language. In addition, the abstract operators in this language are also easy to reuse in other similar programs, and the written programs are more readily read, more readily understood.
There is also a point worth mentioning, that is, the bottom-up development method can get feedback from the code as soon as possible, and reconstruct it in time. We may have already known that design patterns are generally a target, here I think it is: DSL is often a good restructuring goal.
Abstract, library and DSL
C Father Bjarne Stroustrup often emphasizes the "library to expand the language, think with the library" (http://www.artima.com/intv/Elegance.html has recently been interviewed by Bjarne Stroustroup, he once again emphasized this again Issue), in fact, emphasizing the importance of DSL and the downward development. The library is a form of DSL. An example of the scientific calculation library listed by Bjarne Stroustrup is the DSL in the field of scientific calculations. The process of building a library is actually moving in an abstract direction of more abused problems. Understand this, we are not difficult to understand that Bjarne Stroustrup has always emphasized the importance of building an elegant and efficient library because generics provide a solid foundation for building this abstraction.
Not only C , there are many other libraries (such as: Java). These libraries provide strong support when we develop software development. However, these libraries often only realize some general fundamental issues in the field. Therefore, in some specific issues, these libraries may not be used directly to express expression. At this point, you should consider establishing a specific library specific to yourself. in conclusion
As a developer, what should we do? As this article began, the abstraction is very good, but it is very difficult to find abstraction that is suitable for your hand. It should be a process of continuously getting feedback from code writing, then correcting, then writing a loop feedback from code, which is why I think it is more effective to develop down. We should not be limited to only use a tool, a kind of development environment, but think more about these tools, the idea of developing the environment. We should focus on cultivating yourself to explore abstract abilities. This capabilities are cultivated to both need well and customer communication, but also need solid, superb software capabilities.
In addition, the recent thermal unpleasant technology MDA, its core thinking is actually DSL, but I don't be optimistic about the practice of engraving all domain models for it to try to use a language. With it, it is better to gradually evolve a mini DSL and a DSL compilation / interpreter that is specific to yourself, based on this DSL, which may be more direct, more lightweight, more clearly More effective, more targeted, and more economical J
references
[1] Eric Steven Raymond, The Art of Unix Programming
[2] Eric Evans, Domain-Driven Design: Tackling Complexity In The Heart of Business Software
[3] Andrew Hunt, David Thomas, The Pragmatic Programmer: from Journeyman To Master
[4] GRADY BOOCH, Object-Oriented Analysis and Design with Application
