75.JAVA Programming Idea--design paradigm

75.JAVA Programming Idea--design paradigm

Introduce to you important but not so traditional "paradigm" (pattern) programming methods.

Perhaps the most important step in the evolutionary process toward object-oriented programming is the advent of the design paradigm. It was defined as a "milestone" in the book "Designpatterns", written by Gamma,helm and Johnson (published by Addison-wesley in 1995). The book lists 23 different ways to solve the problem. We are ready to follow a few examples to reveal the basic concepts of the design paradigm. This may arouse your desire to read the book Design Pattern. In fact, the book is now a must-have reference for almost all OOP programmers. The examples in the book are written in C + +.

The latter part of the note contains an example of the evolution of the design, starting with a more primitive approach, gradually evolving and improving, and slowly becoming more logical and appropriate design. The Program (simulation garbage classification) has been evolving, and can be used as a prototype of its own design-a solution for specific problems, and then a gradual improvement, making it one of the most flexible solutions to that type of problem.

1 Concept of the paradigm

At the very beginning, the paradigm can be imagined as a particularly intelligent, self-adapting technique that solves certain types of problems. In other words, it is similar to someone who needs a full understanding of a problem. After understanding all aspects of the problem, finally put forward a set of the most common, most flexible solution. The specific problem may have been seen and resolved before. However, the former plan may not be the most complete, and you will see how it is expressed in a paradigm.

Although we call it the "design paradigm", they are not actually confined to the design field. Thinking "paradigm" should be divorced from the traditional sense of analysis, design and implementation of the thinking way. Instead, the "paradigm" is to express a complete set of ideas in a program, so it can sometimes appear in the analysis or advanced design stages. This is interesting because the paradigm has a form that is directly implemented in the form of code, so it may not be desirable to expose it before a low-level design or implementation (and in fact, unless it really enters those stages, it is generally unaware that it needs a paradigm to solve the problem).

The basic concept of paradigm can also be seen as the basic concept of programming: adding a new layer of abstraction! As long as we abstract something, it is tantamount to isolating a particular detail. And the most compelling motive behind this is "isolating the changes that have taken place in the constant." Another reason for this is that once we find that some part of the program may change for one reason or another, we generally want to prevent those changes from reproducing other changes within the code. This not only reduces the cost of maintenance of the code, but also makes it easier for us to understand (the result is also to reduce overhead).

The most difficult part of designing a powerful and easy-to-maintain application project is finding what I call a "lead change." This means finding the most important thing that is causing the system to change, or changing the angle to find the part that pays the most and the most expensive. Once the "lead change" is discovered, you can set a focal point for yourself and start your own design around it.

So the ultimate goal of the design paradigm is to isolate the changed content in the code. If you look at it from this point of view, you will find that some design paradigms have actually been adopted. For example, inheritance can be imagined as a design paradigm (similar to a compiler implementation). Inside an object that has the same interface (that is, something that remains constant), it allows us to express differences in behavior (that is, what is changing). Compositing can also be imagined as a paradigm, because it allows us to modify-dynamic or static-to implement the object of a class, and so can modify how the class works.

In the book "Design Patterns", you can see another paradigm: "inheritors" (i.e. Iterator,java 1.0 and 1.1 irresponsibly call it enumeration, i.e. "enumeration"; Java1.2 's collection is changed back to "inheritors"). When we traverse through the collection, selecting different elements individually, the inheritors can effectively hide the implementation details of the collection. With inheritors, you can write out common code to take some action on all elements of a sequence without worrying about how the sequence is built. In this way, our generic code can be used with any collection that can generate a successor. _

1.1 List

Perhaps the simplest design paradigm is the "list" (Singleton), which provides one (and only one) instance of the object.

1.1.1 Code

final class Singleton {

privatestatic Singleton S=newSingleton (47);

privateint i;

Private Singleton (intx) {

I = x;

}

Public static Singleton GetHandle () {

return s;

}

Public intgetValue () {

return i;

}

Public voidsetValue (intx) {

I = x;

}

}

Public class Singletonpattern {

Public staticvoidmain (string[]args) {

Singleton s = Singleton. GetHandle ();

System. out. println (s. GetValue ());

Singleton s2 = Singleton. GetHandle ();

S2. SetValue (9);

System. out. println (s. GetValue ());

Try {

//Can ' t do this:compile-time error.

//Singleton s3 = (Singleton) s2.clone ();

} Catch (Exceptione) {

}

}

} /// :~

The key to creating a list is to prevent the client programmer from creating an object in any way other than what we provide. All builders must be set to private, and at least one builder should be created to prevent the compiler from automatically synchronizing a default builder (it will intelligently create a "friendly"--friendly, rather than a private one).

You should decide how to create your own objects at this time. Here, we chose the static creation method. But you can also choose to wait for the client programmer to issue a create request and then dynamically create it according to their requirements. In either case, the object should be saved as a "private" property. We provide access through a common approach. Here, GetHandle () produces a handle to the singleton. The remaining interfaces (GetValue () and SetValue ()) belong to the normal class interface.

Java also allows you to create an object by cloning (clone). In this example, setting the class to final prohibits cloning from occurring. Because Singleton is inherited directly from object, the Clone () method retains the protected (protected) property and cannot use it (forcing use causes a compile-time error). However, if we inherit from a class structure that has overloaded the clone () method with the public property and implemented the Cloneable, Overload clone () is required to disable cloning, and throws a clonenotsupportedexception (cloning violation is not supported). Also overload clone () and simply return this. Doing so can be confusing because the client programmer may mistakenly assume that the object has not been cloned and still manipulate the original. Note that we are not limited to creating only one object. You can also use this technique to create a finite object pool. However, in that case, you might need to resolve the sharing problem with the objects in the pool. If unfortunately you really encounter this problem, you can design a set of programs to achieve the registration of shared objects and deregistration.

1.2 Paradigm Classification

The book "Design Patterns" discusses 23 different paradigms and classifies them according to three criteria (all of which involve areas that may change). These three criteria are:

(1) Create: How objects are created. This usually involves the isolation of object creation details, so that you do not have to rely on objects of a specific type, so you do not have to change the code when adding an object type.

(2) Structure: Design object, meet the specific project limit. This involves how objects are connected to other objects to ensure that changes within the system do not affect these connections.

(3) Behavior: An object that manipulates a particular type of action in a program. This requires that we encapsulate the actions we want to take, such as interpreting a language, implementing a request, traversing it in a sequence (as in the case of an inheritor), or implementing an algorithm. This chapter provides an example of the paradigm of the "observer" (Observer) and the "accessor" (Visitor).

Design Patterns uses a section for all of these 23 paradigms, accompanied by a large number of examples, but mostly written in C + +, a few written in Smalltalk (if you read this book, you know this is not really a big problem, Because it's easy to translate basic concepts from two languages into Java.

75.JAVA Programming Idea--design paradigm