The power of perspective--the principle of OO design

In the article "Oo Design principles Summary" I raised a question: how to better use these principles. How to abide by these principles in practice, the use of three perspectives to think about the question is one of the answers;

The contents of this article include:

1. Why do we dwell too early on the details? What is the nature of the problem.

2. Life-saving straw--martin Fowler Three-layer perspective theory

3. Three-layer perspective--back to the OO design principles

Why we dwell too early on the details. What is the nature of the problem.
Early attention to detail in design is almost a quagmire for most programmers, and it's my own malady. Just like I started working soon to do an automatic update of the system, the design meeting of the development team boss decided to use the FTP protocol to complete, you know what I think in the head. --"Indy component does not seem to support Chinese" ...

There are probably two reasons for the premature attention to detail: 1. Experienced, extrapolate, Gangjumuzhang, various techniques very familiar 2. No experience, only know the technical details, it is difficult to jump out of the shackles of thinking; I know I am the latter, and it is now.

People are inert, people habitually do their own proficiency in things. So when it comes to design, when the big frame lacks the ability to grasp, subconsciously I prefer to think about the details. This is lazy, all technical details, problems are no doubt (we do not do scientific research), or there are questions you can easily get answers whether it is the development of documents or in the community. The details of the solution are always obvious, but not necessarily the best starting point.

Sometimes I really want to design, I want to avoid falling into the "details of the mud" but I still inadvertently pull the details, this is why. Analysis of their own, I know this is because my thinking is tiled, there is no level, all the problems stirred together, when the design is inevitably the pays top academics of the muddy,.

Thinking no hierarchy This is the essence of the problem, I want to do a good job of design, and the way of thinking flaws become my life door, what should I do. To tell the truth I have been on the detour, and do not know whether this road is the right one.
"Good people in the pursuit of even confused, but will eventually realize that there is a path." "Faust"-----
Life-saving Straw--martin The theory of three-layer angle of view Fowler

Martin Fowler, in his book UML Distilled, mentions a three-layer perspective (Perspective): A conceptual perspective, a statute perspective, and a visual perspective.

Using three different perspectives to see software development, we can get a description like this:

Conceptual perspective: to present the various concepts in the field of study, to arrive at a conceptual model should be as little as possible or not to consider its implementation, this point of view to answer the question is: software to be responsible for what. It's a strategic conclusion.

Protocol perspective: We are now considering software, but we are concerned with the interface of the software rather than the implementation. The question to be answered in the view of the Statute is: how to use the software. This level is concerned with the communication of the various parts of the software.

Implementation: At this point we are thinking about the code itself but in many ways we may be better at using a protocol perspective, where the software communicates in the implementation layer at the protocol level.

Perspective helps us to divide issues into layers and isolate

From the above description we clearly see that the "Software development" of the design involved in the problem has been divided into three different levels, at each level we have to have specific thinking results. We do not go down a level when there is no maturity at the top, and in accordance with this principle, details are isolated from the walls of thought.
The following question is, in the design process, three kinds of perspectives on the level of the problem can play a role.
Three-layer perspective-back to the OO design principles

Conceptual perspective we get the various concepts of the domain, the object to be responsible for what. This is a high-level strategy, which is usually highly abstract and is a strategic conclusion, the key point: it is stable. As long as the concept is unchanged, the requester is separated from the details, and the details of the problem should be deferred as much as possible. Focusing on what the object does, not how it is done, hides these details and helps us avoid the details of premature intervention. The best way to focus on what the object is doing is to define the object's responsibility, and to understand the object is to think of it as something responsible.

The object is a set of methods that can be called by other objects or objects themselves (i.e., behavior, how to use software?); objects are responsible I just need to focus on the public interface of the object-this is the communication channel where I ask the object to do some work. As long as the object's interface tells us it can do a certain duty, it doesn't care how the object works. Focusing on motivation rather than implementation is the basic OO design principle, which hides the implementation behind the interface and actually decouples the object's implementation from their objects.

Implement perspective, objects are code and data, and computational interaction between them (how does the software fulfill its responsibilities?) We started to discuss the implementation details when we came here.

To summarize, look at the objects from Martin Fowler's three perspectives:

At the conceptual level, an object is a set of responsibilities

At the protocol level, an object is a set of methods that can be called by other objects or objects themselves

At the implementation level, objects are code and data, and their computational interactions

Here we need to rethink the fundamentals of OO:

From the concept level to the statute layer our thinking results are abstract, they are abstract concepts, is one of the actions, we in the concept layer is the object of the responsibility of the clarity, at the level of the statute we see how the different responsibility of the object is how to collaborate. Collaboration is a contract between an object and an object. How the responsibility of the object is divided. The object should be responsible for itself, the object should be as single as possible, this is the SRP principle. The protocol layer we define is the interaction between objects, that is, interfaces, attention to interfaces rather than implementations, we did.

The concept layer is the most stable, the level of the statute, the realization is the most unstable. Therefore, high-level modules should not be dependent on the lower modules, both of which should be dependent on abstraction. The details should depend on abstraction, which is the dip principle. The implication of this principle is that there is a coupling between objects only at the conceptual level and not in the implementation hierarchy.

All of the interactions we define are using the base class, and if implemented, a subclass cannot completely replace the base class. That's not all the interaction contracts are having problems. A subclass derived from a base class should support all the behavior of the base class, and the subclass must be able to replace the base class, which is the LSP principle.

It can be seen that the responsibility and interaction of the object are defined as early as possible, in which we do not consider when the specific object was created and mapped into our design process, the application of the creation design pattern is often in the late design.

Conclusion: In the article "Oo Design principles Summary" I raised a question: how to better use these principles. How to abide by these principles in practice, the use of three perspectives to think about the question is one of the answers; When designing, attention should be focused on high-level relationship; In the face of object design and development process, it can improve our design ability and avoid getting bogged down in detail.

Attached: Martin Fowler's writings, "UML distilled", refer to the paragraphs of three perspectives (perspective):

Following the lead of Steve Cook and John Daniels (1994), I say that there is three perspectives you can use in drawing C Lass Diagrams-or indeed any model, but this breakdown is the most noticeable in connection with class diagrams. Conceptual.
If you take the conceptual perspective, you draw a diagram that represents the concepts in the domain under study. These concepts would naturally relate to the classes that implement them, but there is often no direct mapping. Indeed, a conceptual model should is drawn with little or no regard for the software that might implement it, so it can Considered language-independent. (Cook and Daniels Call this the essential perspective.) Specification.
Now we is looking at software, but we is looking at the interfaces of the software and not the implementation. object-oriented Development puts a great emphasis on the difference between interface and implementation, it is ofte N Overlooked in practice because the notion of class in an OO language combines both interface and implementation. This was a shame, because the key to effective OO programming are to program to a class ' s interface rather than to its imple Mentation. There is a good discussion of the first chapter of Gamma, Helm, Johnson, and Vlissides (1995). You often hear the word ' type ' used to talk about an interface of a class; A type can has many classes that implement it, and a class can implement many types. implementation.
In this view, we really do has classes and we are laying the implementation bare. This was probably the perspective used most often, but many ways the specification perspective was often a better one to Take.

Understanding perspective is crucial to both drawing and reading class diagrams. Unfortunately, the lines between the perspectives is not sharp, and most modelers does not take care to get their perspecti ve sorted out when they is drawing. Although I ' ve found it often does not matter too much between the conceptual perspective and the specification Pers Pective, it's very important to separate the specification perspective and the implementation perspective.

As I talk about class diagrams further, I'll stress how each element of the technique depends heavily on the perspective .

Perspective is not part of the formal UML, but I had found it extremely valuable when modeling and when reviewing models. The UML can is used with all three perspectives. By tagging classes with a stereotype (see page), you can provide an indication of the perspective. You mark classes with <<implementation class>> to show the implementation perspective, and with <<TYPE&G T;> for the specification and conceptual perspectives.

UML distilled Second Edition A Brief Guide to the standard Object Modeling Language

Martin Fowler Kendall Scott

Publisher:addison Wesley

Second Edition August 18, 1999

Isbn:0-201-65783-x, 224 pages

  http://www.cnblogs.com/me-sa/archive/2008/04/19/1154014.html