Yijing and software development

In head first design patterns, the design principles of tips are Taiji as icons.

Taiji is the National Quintessence of China. Do foreigner also think that the essence of Taiji is dark and the idea of software development?

Everything has Yin and Yang, and software architecture development has relatively fast changes and remains unchanged. Software Project Development is to turn customers' needs into deliverable software. For this purpose, our programmers have come up with a variety of management methods and technical ideas. Undoubtedly, the OO idea is a magic weapon to cope with the ever-changing customer needs. But is oo actually a silver bullet? What are the three major features of OO ideas? :-) All kinds of interviews and exams will ask this question. Of course, IT training institutions also tell students: encapsulation, inheritance, and polymorphism! Channels, but not common channels. You know encapsulation, inheritance, polymorphism, and can also write instance code in a standardized and concise manner. But do you write loosely coupled programs?

For beginners who have many syntaxes, please use semantics. If you do not believe it, you can ask them how they understand the following principles:

The interface here represents an abstract semantics, rather than the interface or abstract class of a specific language. It only needs to be able to achieve the effect of "polymorphism" when running, you can complete the semantics of object replacement.

The original name of Yijing is Changjing. It refers to the learning of changes. In the past, it was immutable. Now it can be changed, but it cannot be tested in the future. In fact, no matter how it changes, there is a principle, we also need to design a relatively stable and scalable framework to meet the changing customer needs.The design principle is your "Sutra ". Beyond the language model. OCP, LSP, dip, ISP, carp, and dump are all described in this book by instructor Li Jianzhong of webcast.

Another principle of easy change is "change without harming people". Similarly, when business needs change, the software must change in quantity to adapt to requirements, the key is the price of this change and the system fluctuation. Our design principle is not to let us come up with the contract and the customer's signing requirements in the face of the customer's needs, saying, "Why do we need to change it now "? There is no constant demand to actively embrace this change. From a three-dimensional perspective, the requirement has been voided at the moment the customer signs the change. What is the last hexagrams of Yijing? This is the truth. A good design can isolate changes from the main line of the system, so that the amplitude of the shock is only within the predictable component module.

The third principle of change is "Don't use more". No matter how instructive your design principles are, what an excellent design model your software uses, the demand changes you can respond to are limited. You can carefully consider this one, and try to control the baseline of the changes or changes before the software is delivered. Otherwise, the software cannot be delivered, and the customer complains for a few days, developers complain.