Criticize Code that has been written for five years without understanding of interfaces, reflection, delegation, and design patterns (Technical)

Original article address:I have been writing code for five years without understanding of interfaces, reflection, delegation, and design patterns-for beginners (talking about beauty generators without talking about code generators)

There are three articles in jri, which are the most terrible and can be calledTrilogy of misleading newcomers:

1. colloquial reflection technology-suitable for beginners

2. Speaking of shanzhai SOA in the vernacular, there is less confusion and more understanding. Is your program architecture SOA?

3. I have been writing code for five years without understanding interfaces, reflection, delegation, and design patterns-writing it to beginners (talking about beauty generators without talking about code generators)

I believe everyone has read it, whether it's entertaining or eager to learn from it.

There are serious mistakes in article 1, which refer to deprecated hydrology. For related errors, see Xiao Zhao's article: Talk about the vernacular reflection technology and other articles (technical articles ).

In article 2nd, SOA was never used at all, but the brain jumped out to educate new people. For criticism, see SOA in my eyes and Application Experience in practical projects.

The first article is the most empty one. Do not understand ...... But I wrote the code for five years. I am a beginner of "education", but I don't have any practical content. This is also the subject of my criticism.

 

It is really difficult to criticize the article "do not understand interfaces", because the figure in this article is related to the four principles below and the theme he wants to talk about. Other words are nonsense.

For the figure, the so-called "Beauty builder", whatever its vulgarity, I think it is also the point that won the applause of the following group of spectators, however, when we carefully look at the figure and the six paragraphs in the figure, we will find that it has no educational significance.

First, this is a flowchart rather than a UML diagram. Without the combination of UML diagrams, it is difficult to understand the interfaces, inheritance, and composite relationships in the examples. Therefore, there is no such thing as technical rigor.

Well, let's take a look.

 

Why can input parameters be interfaces instead of variables and classes?

This involves the principles of method design, but is irrelevant to the interface design principles.

In a large number of design practices, we found that when declaring the parameter type of a method, we should specify the weakest type as much as possible and define interfaces on the base class, in this way, you can enter a wider range of parameter types, making it more flexible.

Jri's text is vague. He just took out a small experience, but he did not know why. Let alone he could explain it to beginners.

 

Here we talk about the inline function, which is to make gold based on stone and water, then make a diamond, and finally generate a beauty, that is, the final return value. In the end, we still split a complicated method into three simple methods. According to the idea of Jiri, the code should be as follows:

Public class mmconverter
{
Public mm convertfromstonetomm (istone stone, water)
{
VaR Gold = convertfromstonetogold (stone, water );

VaR diamond = convertfromgoldtodiamond (gold );

Return convertfromdiamondtomm (diamond );
}

Gold convertfromstonetogold (istone stone, water)
{
Return new gold ();
}

Idiamond convertfromgoldtodiamond (gold Gold)
{
Idiamond diamond = diamondfactory. creatediamond ("Shanghai ");

Console. writeline (diamond. Quality );

Return diamond;
}

MM convertfromdiamondtomm (idiamond diamond)
{
Return new mm ();
}
}

Clearly, we can see that this split is a process-oriented approach, which is irrelevant to the interface design.

 

This section has the most comments, which are discussed as follows:

1) "The system has a clear output ". Because the type range of the system input parameters should be as wide as possible, after thinking backwards, we think that the output of the system (that is, the return type) should be as narrow as possible, try not to limit it to a specific type. In addition, during the 10-year coding career of July, the return type seems to be clear after repeated and repeated code machine-type programming.

However, he is only half right. We need to understand that he has been engaged in procedural programming for more than half a decade. Without polymorphism (including override and overload), Giri naturally returns what he thinks is needed.

Let's take an example to illustrate whether to return filestream or stream by writing an IO operation method? I must be honest and I have no final conclusion. Unless I know in advance that it must be an I/O operation on a file, I will definitely return filestream directly. Otherwise, please return the object at the stream level.

I was thinking, if the method only returns different types, it is also an overload, so it will not be final. I will write a few overload methods for several types. This is the most aggressive approach. It is a pity that C # cannot do this only when il is allowed.

2) "It is impossible to output oil here. Should I output diamond as soon as it is output? This sentence is not clear to me. Who can help me explain those fans that are quite "auspicious?

3) In addition, I am puzzled by the phrase "of course there can be multiple outputs, such as REF and out. We know that ref and out are language-based and solve the problem of passing a copy of the parameter to the method or the parameter reference itself, it has nothing to do with interfaces and OO designs.

Here is the poor display of auspicious sun. Do we really need to use ref and out to return multiple outputs in the factory method? It is not necessary, or it is a bad design that will undoubtedly mislead beginners.

In the OO design, if multiple outputs are required, we can upgrade the variable to the class level so that the value of this variable can be set before the method is returned, to achieve the same effect. Alternatively, for multiple outputs, You can abstract them into two attributes of an object so that the method can return the object type.

For ref and out, I have worked on VB6 for two years. I have a deep understanding of this. In the process-oriented programming model, ref is frequently used.

In this case, July wrote the program for 10 years. Although C # is also in use, it is still based on the process-oriented programming method, just abstract a piece of code into a method. In the abstract process, due to the original process-oriented programming model, but he was not sure how to reconstruct it according to the OO idea, he had to use ref in a large number to remove the east wall and complete the west wall.

 

This comment is the most confusing, because according to his flowchart, I cannot find the meaning of "interface" in the sentence "interface is not correct", and I cannot mention "intermediate processing and conversion ".

Based on my experience, make the following two guesses:

1) Some programmers do not develop good terms and do not distinguish "interfaces" from "interface methods". Therefore, they often say "I will expose an interface for you to call ", the other party can also understand.

2) If yoy is really dealing with interface compatibility issues, the "intermediate processing and conversion" mentioned here is nothing more than the following modes: adapter, proxy, facade, and bridge. Adapter and proxy are the easiest to think of because they can handle most of the interface compatibility issues. But girI is still at the stage of procedural programming (though he may not admit it). I think he should refer to facade here. I have gone over his other hydrology, which is a series of articles on general permission and big wicked behind closed doors, which only contain pictures and advertisements without thinking and implementation, from the encapsulation of database operations, I roughly confirmed my guess.

I have added hyperlinks under the above patterns to point to the design patterns series I wrote earlier. If you are not familiar with the design patterns, click to learn about the relevant technologies.

 

Let's take a look,

Drawing a bunch of figures, this is more reliable, it is a simple factory, it should be a huge book, the result is a sentence "this is the so-called interface, it is so simple", describe perfunctory.

I gave the following implementation:

Code
Public interface idiamond
{
String quality {Get; set ;}
}

Public class diamondinshanghai: idiamond
{
Public String quality {Get; set ;}

Public diamondinshanghai ()
{
This. Quality = "good ";
}
}

Public class diamondinhangzhou: idiamond
{
Public String quality {Get; set ;}

Public diamondinhangzhou ()
{
This. Quality = "bad ";
}
}

Public class diamondfactory
{
Public static idiamond creatediamond (string address)
{
Idiamond diamond = NULL;

Switch (address. tolower ())
{
Case "Shanghai ":
Diamond = new diamondinshanghai ();
Break;
Case "Hangzhou ":
Diamond = new diamondinhangzhou ();
Break;
}

Return diamond;
}
}

 

I said that this section is full of nonsense, and those who are pretty cool will be upset. After talking about it for a long time, we still need to split thousands of rows of methods into several small methods. You don't need to say that new people still know that they need to write programs like this.

 

Let's take a look at the so-called four principles that he summarized, and the water is even greater. The four principles are big hats and there is nothing wrong with them, but they are not clear at all, let's analyze it one by one:

1.Principles of division of labor and clear responsibilities: Each device has a clear division of labor and should have a clear functional positioning. What to do should be done, and the responsibility positioning should not be messy. You cannot expect a car to fly, and the plane should dive into the bottom of the sea, what should I do? A function should not be written too long. It also tastes like this. Everything should be well differentiated. Don't write thousands of lines of code.

Comment: As we often talk about it, let's talk about how to split thousands of rows of methods into several small methods again.

2.Clear Input and Output principles: Each device has a clear input and output, and even has Threshold restrictions and strict input and output parameters. What should I stream in? What kind of processing is done, and what is streaming? To put it down, a function that we write every day is similar to a subsystem developed by our company. Every function and every subsystem should have a clear function positioning, it should not be repeated and should not be disorganized.

Comment: The range of method parameters and return values: the parameter type should be as wide as possible. However, the return type is not necessarily narrow. Giri believes that output needs to be strictly controlled, which is too narrow. It is a process-oriented approach. In the OO world, the output type can be wide or narrow, I have explained why in the 3rd note above.

3.Interface and standard principles: The incoming calibers, threads, materials, outbound calibers, threads, materials, etc. should all be in some industry specifications. Otherwise, after a device architecture is completed, it should be transferred to the next device for processing, isn't the stream no longer available? Or you can use a special pipe in the middle to connect the two devices. The two pipes have standard connections with these devices, just like some computer adapters, for example, what is USB conversion.

Comment: What is this? Why can't the industry standards flow down? The pipe and USB mentioned later are actually an adapter in the design mode. Oh, I understand, Jiri is trying to tell us to create a class A object, but a Class B object is needed later.

Is the stream really stuck? If a is derived from B, will the stream not pass? Of course, the stream can pass. What actually requires an adapter is that a does not derive from B.

4.Replaceable, upgradeable, and updatable principles: A large chemical plant often performs some repairs, upgrades a device, or equipment. You cannot upgrade the entire chemical plant, it seems that it takes tens of billions of dollars to build a large-scale chemical plant. The money is pulled by train and several trains can also be pulled. If you don't want to update it, you can update it. Do you want, no.
For example, if a screw in our car is broken, I can choose the same type of screw produced by Company A or the same type of screw produced by Company B. This is because of these screws, all have the same functions and can meet the required specifications.

Comments: The replaceable, upgradeable, and updatable principles here are the hot swapping of components. It is irresponsible for new users, because it involves interface-oriented programming. All parts must be made into factories. Each class we want to write should be: interface. method (); instead of a specific class. method ();. Have you ever written an interface-oriented program on July? Can you tell when an interface is used and when an abstract class is used? Have you ever performed the design phase behavior of components?

Of course, I am always reflecting on the granularity of the design patterns and interfaces entrusting these technologies? Is it necessary to describe the complex scenarios of chemical plant maintenance equipment? Can a cannon beat mosquitoes or a chicken knife?

 

I finally finished writing it. I felt two words: pain. After reading the articles in jri, I often run my questions when I look at them without saying anything about the typos and sentences. When I am going to explain them in depth, I am vague and have no design ideas, let alone UML diagrams and code implementation. The Flowcharts are so dazzling that they do not have practical significance. The subjective consciousness is so heavy that many places cannot afford to think.

In the article "do not understand interfaces", the idea of auspicious day is summarized as follows:

1. Input and Output. The former is wide and the latter is narrow (in fact, the latter is inconclusive)

2. The factory is required to generate an object for US (the word factory is what I said, not in the original article)

3. You need to split a method with thousands of lines of code into a small method with a single function (you don't need to say this, just like saying that the Coal Ball is black)

4. You need to provide a mechanism to automatically generate different objects (what mechanism? Not mentioned)

5. a usb pipe is required (how can this problem be achieved? Not mentioned)

The topic in this article is "code written for beginners who have not understood interfaces, reflection, delegation, and design patterns for five years-writing to beginners (talking about beauty generators without talking about code generators)". but what can beginners learn from this sentence? It is a waste of time to look for a book.

Auspicious day is a programmer who has been writing programs for more than 10 years. However, it is a joke to hear such a person talk about interfaces, commissions, factories, and OO on the basis of process-oriented. In addition, he dared to speak out without words, but he was also a slide across the world. It took me one night to analyze his article and further understand him.

Finally, I advise beginners to buy a copy of what you must know if you really want to understand interfaces, delegation, and other technologies. net, you can also choose CLR via C #. These are the most important concepts in terms of language and design. Do not be ruined by the logs of July.

Download the sample code in this article: program.zip