Chapter 4
A standard object-oriented solution
Overview
This chapter gives us the problem discussed in Chapter 3, "an urgent need for flexible code", gives a preliminary solution. This is a reasonable initial attempt that can solve the problem quickly. However, it missed an important system requirement: the flexibility required when the CAD / CAM system continues to evolve.
In this chapter, I describe a solution based on object-oriented object. It is not big, but it really can work.
Note: In the main part of this chapter, I will only show an example of Java code. The corresponding C code example is at the end of this chapter.
Use special means to solve the problem
Considering the two different CAD / CAM systems described in Chapter 3, "Problem for Flexible Codes". How can I build an information-cutting system that makes it look the same regardless of which CAD / CAM system uses?
Through thinking how to solve this problem, I am inference if I can solve the problem of the slot, then I can use the same scheme to handle the problem of shear blocks, holes. Through the thinking of the slot, I found that I can easily gently gently. That is, I will have a SLOT class. In the face of the V1 system, I will generate a derived class for it. When I face the V2 system, I will generate another derived class for it. As shown in Figure 4-1.
Figure 4-1 Design of Tank
By expanding every type of characteristics, I completed this solution, as shown in Figure 4-2.
Figure 4-2 Original solution for information analysis
Of course, Figure 4-2 shows a quite high-level design. Each V1xxx class will communicate with the corresponding V1 library, while each V2xxx class will communicate with the corresponding object in the V2 model.
If you look at every class separately, this solution is easier to imagine.
L V1Slot can be implemented by remembering the model itself from which it is dominated and it is implemented in the ID of the V1 system. Thus, when a method of V1Slot is called to obtain information, this method will have to invoke a sequence subroutine in V1 to obtain relevant information.
l V2slot will be implemented in a simpler way, that is, each V2SLOT object will contain a corresponding slot object in the V2 system. Thus, when the object is queried to some information, it will simply transmit this request to the OOGSLOT object and send the response to the customer object that previously issued a request.
Figure 4-3 shows a more detailed diagram including V1 and V2 systems.
Figure 4-3 Initial program
I will provide code examples for two classes in this design. These examples are only used to help you understand how to achieve this design. If you think you can implement this design, please skilled the next Java code example (C code example in the end of this chapter).
Example 4-1 Java Code Segment:
Instantiate V1 characteristics
// Code pieces of instantiation feature
// Do not provide error inspection - use only as a demonstration
/ / Each characteristic object needs to know the model number and characteristic ID corresponding to it.
// to get information when receiving the request
/ / Note How this information is transmitted into the constructor of each object.
// Open the model
Modelnum = v1OpenModel (ModelName);
NELEments = V1GETNUMBEROFELEMENTS (Modelnum);
Feature features [] = new feature [MAXFEATURES];
/ / Do every characteristic in the model
For (i = 0; I / / Determine the current feature and create an appropriate property object Switch (V1getType (Modelnum, i)) { Case Slot: Features [i] = new v1slot (Modelnum, VlgetId (Modelnum, i)); Break; Case Hole: Features [I] = New VLHOLE (Modelnum, VlgetId (Modelnum, i)); Break; } } Example 4-2 Java code segment: Implementation of V1 method // modelnum and myid are private members // They contain information about the corresponding model and characteristics (in V1) Class v1slot { Double getX () { / / Call the appropriate method for V1 to get the information required. note: / / In order to get information, this method can actually call several methods in V1 Return V1GetxForslot (Modelnum, MyID); } } Class vlhole { Double getX () { / / Call the appropriate method for V1 to get the information required. note: / / In order to get information, this method can actually call several methods in V1 Return V1GETXFORHOLHOLE (Modelnum, MyID); } } Example 4-3 Java Code Segment: Initializing V2 characteristics // Code pieces of instantiation feature // Do not provide error inspection - use only as a demonstration / / Each characteristic object needs to know its corresponding characteristics in V2 // to get information when receiving the request / / Note How this information is transmitted into the constructor of each object. // Open the model MyModel = V2OpenModel (ModelName); Nelements = mymodel.getNumeLements (); Feature features [] = new feature [MAXFEATURES]; (to be continued) Example 4-3 Java Code Segment: [1] Initializing V2 characteristics (continue) OOGFEATURE * OOGF; / / Do every characteristic in the model For (i = 0; I / / Determine the current feature and create an appropriate property object OOGF = MyModel-> getElement (i); Switch (OOGF-> mytype ()) { Case Slot: Features [I] = New V2Slot (OOGF); Break; Case Hole: Features [i] = new v2hole (OOGF); Break; } } Example 4-4 Java Code Segment: Implementation of V2 method // OOGF is the corresponding characteristic object in V2 Class v2slot { Double getX (} { // Call the appropriate method of OOGF to get the required information. Return OOGF-> getX (); } } Class v2hole { Double getX () { // Call the appropriate method of OOGF to get the required information. Return OOGF-> getX (); } } In Figure 4-3, I increased the methods required for several characteristics. Note how they are different from the type of character. This shows that I have not used polymorphism in the entire feature system. However, this is not a problem, because in any case, this expert system always needs to know the type it has, it requires different types of information from different types of characteristics. This brings up the point thing I am not so interested in Polymorphism of the features. Rather, I need to plug and play with different CAD / CAM systems without changing this expert system. I want to do - transparently handle multiple CAD / CAM versions - give me a few points, this is not a good solution: Repeat in the method - I can easily imagine those methods that call V1 systems, there will be many similarities between them. For example, the V1GETX and Hole V1GETX in Slot will be very similar. Messy - it is not always a good indication, but use this program, it is another factor that enhances my discomfort. High coupling - this scheme is high coupling because each characteristic is indirectly associated with each other. These relationships indicate that if we happen, we are likely to modify all features: - Need a new CAD / CAM system. - Modify an existing CAD / CAM system. Low internal gathering - cohesive is quite low because the method of performing core functions is dispersed in these classes. However, my most concerned question appeared in the time of observing characteristics. What happens when the third version of the CAD / CAM system occurs. The combination explosion will kill us! Look at the third line of the graph in Figure 4-3. l There are five types of characteristics here. l Each class has two classes, each CAD / CAM system. l When the third version is added, each group will have three classes instead of two classes. l I have no longer ten classes, but fifteen classes. Can affirm, maintain such a system, I will not get any fun! A trap of analysis: premature attention too much details. In the development process, a general problem that we analyzed is to fall in the details. This is natural because the details are easy to handle. Details solutions are usually obvious, but it is not necessarily the best start. How long is it to be delayed before the embracing detail? In this case, I reach a goal: a common API for feature information. At the same time, I also define the object from the perspective of responsibilities. However, the cost I paid for this is to create a special case for everything. When I get a new special case, I will have to implement them in the same way, and therefore pay high maintenance costs. This is my first shy solution, I will start hate it. Compared to the more logical reasons gave above, my intuition has contributed to this feeling. I think there is a problem in this. In this case, I strongly felt that there must be a better solution. However, even after two hours, this is still the best solution I can think of. As you will see it later, this problem is my general way. Pay attention to your intuition For design quality, the intuition of the stomach is a powerful indicator. I suggest developers to learn to listen to their intuition. Speaking of the stomach, I refer to that when you see something you don't like, your feelings in your stomach. I know that this sounds unscientific (it does not scientifically), but my experience often tells me that whenever I don't like a design, a better design is in a corner. Of course, sometimes there are several different corners nearby, and I can't always determine where it is hidden. to sum up I showed how easy it is to solve this problem if you use Special-Casing to everything. It allows me to increase additional methods without changing the status quo. However, this also has several disadvantages: height repeat, low cohesion, and class explosions (from future changes). Excessive trust inheritance will result in more high maintenance costs than this need (or at least, than I think it should be needed). Supplement: C code example Example 4 -5 C code snippet: Instantiate V1 characteristics // Code pieces of instantiation feature // Do not provide error inspection - use only as a demonstration / / Each characteristic object needs to know the model number and characteristic ID corresponding to it. // to get information when receiving the request / / Note How this information is transmitted into the constructor of each object. // Open the model Modelnum = v1OpenModel (ModelName); NELEMENTS = V1GETNUMBEROFELEMENTS (MAXFEATURES); / / Do every characteristic in the model For (i = 0; I / / Determine the current feature and create an appropriate property object Switch (V1getType (Modelnum, i)) { Case Slot: Features [i] = new v1slot (Modelnum, VlgetId (Modelnum, i)); Break; Case Hole: Features [i] = new VLHOLE (Modelnum, VlgetId (Modelnum, i)); Break; } } Example 4-6 C code snippet: Implementation of V1 method // modelnum and myid are private members // They contain information about the corresponding model and characteristics (in V1) Double Vlslot :: getX () { / / Call the appropriate method for V1 to get the information required. note: / / In order to get information, this method can actually call several methods in V1 Return V1GetxForslot (Modelnum, MyID); } Double Vlhole :: getX (} { / / Call the appropriate method for V1 to get the information required. note: / / In order to get information, this method can actually call several methods in V1 Return V1GETXFORHOLHOLE (Modelnum, MyID); } Example 4-7 C Code Segment: Initializing V2 characteristics // Code pieces of instantiation feature // Do not provide error inspection - use only as a demonstration / / Each characteristic object needs to know its corresponding characteristics in V2 // to get information when receiving the request / / Note How this information is transmitted into the constructor of each object. // Open the model MyModel = V2OpenModel (ModelName); NELEments = mymodel-> getNumeLements (); Feature * features [MAXFEATURES]; OOGFEATURE * OOGF; / / Do every characteristic in the model For (i = 0; I (to be continued) Example 4-7 C Code Segment: Initializing V2 characteristics (continue) / / Determine the current feature and create an appropriate property object OOGF = MyModel-> getElement (i); Switch (OOGF-> mytype ()) { Case Slot: Features [I] = New V2Slot (OOGF); Break; Case Hole: Features [i] = new v2hole (OOGF); Break; } } Example 4 -8 C code snippet: Implementation of V2 method // OOGF is the corresponding characteristic object in V2 Double v2slot :: getX (} { // Call the appropriate method of OOGF to get the required information. Return OOGF-> getX (); } Double V2Hole :: getX () { // Call the appropriate method of OOGF to get the required information. Return OOGF-> getX (); } [1] Translator Note: The purple code snippet does not correspond to the original text in the electronic book of the author, which is supplemented with the C code snippet of this chapter.
