. NET Design Pattern (1): the beginning

. NET Design Pattern opening

-- One of the. NET design patterns series

Terrylee, December 06, 2005

Preface

It has been several months since I joined the Design & Pattern team. I am ashamed that I have never written any essay about the Design Pattern and have been approved by wayfarer, the Enterprise Library series is included on the team's homepage. It's not that you don't want to write such a essay, nor do you have no time to do it. You just need to learn the design mode and write the articles in the design mode. Garden Lu Zhenyu The instructor's design pattern series and wayfarer's design path are the classics in the design pattern. However, as wafarer said, he was confused by his desire to express his ideas. He thought twice and decided to write this essay to explore and summarize the design model, the name is "exploring the design model". If you say something too well, you should record the course of your own learning the design model. However, I still hope you can get the guidance from your predecessors!

Design Mode

Is the design pattern a rule?

There is no road on the ground, and when there are too many people, it will become the road. The design pattern is like this. It is the inheritance of experience, not a system. It is discovered by our predecessors and has formed a general solution for a certain type of problems, rather than a qualitative rule; it is not as practical as an algorithm.

Is the design mode an architecture?

The architecture and model should be a process of mutual coverage, but in general, the architecture is more concerned with the so-called High-Level Design, the focus of pattern is the application of the "criterion or guiding Scheme" extracted from experience in design. Therefore, the pattern of different problem domains is formed when the problem is considered at different levels. The goal of the mode is to separate the unchanged and changed parts of the common problems. The unchanged part forms a pattern. Therefore, pattern is a "criterion" for empirical extraction, which is verified once in practice and has different patterns at different levels, from language implementation to architecture. At different levels, the model provides different levels of guidance.

Design patterns, the eternal path of software?

There is no answer to this question. Some of them are just discussions. Let's take a look at the experiences of a senior in combination with architecture:

Like the building structure, the software also has many "internal forces ". Like architectural design, software design should also try to relieve internal forces in the system to make the system stable and angry. All software design should start from this.

Any system needs to change, and any system will die. As a designer, we should embrace and take advantage of changes, instead of escaping from changes.

Good software can only be "generated" but not "created". All we can do is to use a relatively good process and try to make the software develop in a good direction.

Do I need a design pattern?

The answer is yes, but do you need to determine whether the application of the model is excessive? I have to admit that there are many talented programmers in the world who can include six design patterns in a piece of code, or do a good job of design without having. But our goal is to pursue an effective design, and the design model can provide a reference model and design method for this goal.

We do not need to set GOF's design pattern as the standard, but it is the right choice to make rational use of the design pattern. Many people have read GOF's Design Patterns and are familiar with these 23 models. But what's important is not how many models you have memorized, but how to use them in practice. It is worthwhile to familiarize yourself with a certain pattern for effective design, because soon you will find that this pattern is really good in design, most of the time it makes your design easier.

In fact, few software designers may abandon the design model, and blindly exaggerate the functions of the design model, but more. You must talk about the "Mode" and cannot become a good architect. Really good designers, know how to judge the timing of using the model. Another problem is that many people who have entered the software design field are often confused about the design model. For them, the idea of OO has not yet been established because they do not have the practical experience of the project, and the design model is too advanced. In fact, even very experienced programmers do not dare to boast the rational application of various models. [-- From wayfare's design path]

Postscript

I have already written a lot of theoretical articles about the design model. I don't want to copy them any more. I just want to record the above paragraphs, use it to start the series of exploration design patterns. [Now renamed as. NET design mode]