Views on the consistency of the level of abstraction

Source: Internet
Author: User

What abstract

In fact, abstraction is a very iffy thing. In fact, we write a lot of code around, are process-style writing.
We all know that the three basic principles of object-oriented are: encapsulation inheritance and polymorphism. We are often brainwashed by these textbook definitions over and over again.
But in my opinion, it's not. I think object-oriented programming is ultimately an abstraction, a process of modeling. Modeling here is more than just a model for common parlance.
So what is abstraction? My understanding is that abstraction is in a business or a series of business, identifying some of the ways we think we can make a single class, and correspond to the methods that provide it . In fact, this sentence is not said, but it is very difficult to explain the abstract. Specifically, you can look at my article about abstract

Why abstract

Of course, abstractions are not just as simple as they say. Because of a business process, you may have 1000 abstract ways.
Good abstraction, I think the first must be modular.

Modularity: Just do one thing and try to do it well in a place. For example, to calculate the price of an order, we try to do it in one place. Instead of counting here, wait for another place to count. (The main good thing is that it is convenient to maintain in the future, and the problem is easy to troubleshoot)

Of course, one result of modularity is a good package that encapsulates one thing in a class. Easier to deal with extensions.
In fact, abstraction is much like the form of small components. Divide the entire business into small components and then finally combine them.
A good abstraction is also a point that can be a good extension of the abstract things, which requires experience and feeling.

What is called abstract level consistency

First, in the dimension of a class, the method of a class must have an abstract consistency.

Abstract consistency: The whole pattern of things should be done in the same dimension

As an example:

    public class OrderComposeService{        public void  composeOrder(){            //TODO        }        public void  composeSku(){            //TODO        }    }

Our OrderComposeService main function is to combine orders, but composeSku() this method is composeOrder() not at the same level of abstraction as this one.

In fact, for the abstract consistency of the class method, I am still very vague now. If anyone has an accurate description, hope to be able to guide under.
Then there is the abstraction consistency of the method dimension

    public void composeOrder(B b){        composeSku();        calculateShipping();        createPageage();    }

In composeOrder this method, three sub-methods are above the same level of abstraction. But if it appears

     public void composeOrder(B b){        List list = new ArrayList();        Map
  
   
    
    map = new HashMap
   
    
     
    ();        for(A a : list ){            map.put(a.getId,a);        }        composeSku();        calculateShipping();        createPageage();     }
   
    
  
   

This method, like the one below, destroys the abstract consistency of this method in the middle of an extra section. The code for abstract consistency reads as if it were a native requirement. Code that is abstract consistent, whether in readability or in extensibility or in the troubleshooting of problems, is better than one. This is also the reason why the comments are less, the code itself is a comment.

Problem

Of course, some of the problems are that the private methods inside the method can change a lot. Refer to my last question [about business layering]
(http://segmentfault.com/q/1010000002631646 "About business tiering").

Of course, if the requirements are simple, or the business unit is very heavy code does not need to consider so much.

May I ask what you think of this?

Reply content:

What abstract

In fact, abstraction is a very iffy thing. In fact, we write a lot of code around, are process-style writing.
We all know that the three basic principles of object-oriented are: encapsulation inheritance and polymorphism. We are often brainwashed by these textbook definitions over and over again.
But in my opinion, it's not. I think object-oriented programming is ultimately an abstraction, a process of modeling. Modeling here is more than just a model for common parlance.
So what is abstraction? My understanding is that abstraction is in a business or a series of business, identifying some of the ways we think we can make a single class, and correspond to the methods that provide it . In fact, this sentence is not said, but it is very difficult to explain the abstract. Specifically, you can look at my article about abstract

Why abstract

Of course, abstractions are not just as simple as they say. Because of a business process, you may have 1000 abstract ways.
Good abstraction, I think the first must be modular.

Modularity: Just do one thing and try to do it well in a place. For example, to calculate the price of an order, we try to do it in one place. Instead of counting here, wait for another place to count. (The main good thing is that it is convenient to maintain in the future, and the problem is easy to troubleshoot)

Of course, one result of modularity is a good package that encapsulates one thing in a class. Easier to deal with extensions.
In fact, abstraction is much like the form of small components. Divide the entire business into small components and then finally combine them.
A good abstraction is also a point that can be a good extension of the abstract things, which requires experience and feeling.

What is called abstract level consistency

First, in the dimension of a class, the method of a class must have an abstract consistency.

Abstract consistency: The whole pattern of things should be done in the same dimension

As an example:

    public class OrderComposeService{        public void  composeOrder(){            //TODO        }        public void  composeSku(){            //TODO        }    }

Our OrderComposeService main function is to combine orders, but composeSku() this method is composeOrder() not at the same level of abstraction as this one.

In fact, for the abstract consistency of the class method, I am still very vague now. If anyone has an accurate description, hope to be able to guide under.
Then there is the abstraction consistency of the method dimension

    public void composeOrder(B b){        composeSku();        calculateShipping();        createPageage();    }

In composeOrder this method, three sub-methods are above the same level of abstraction. But if it appears

     public void composeOrder(B b){        List list = new ArrayList();        Map
  
   
    
    map = new HashMap
   
    
     
    ();        for(A a : list ){            map.put(a.getId,a);        }        composeSku();        calculateShipping();        createPageage();     }
   
    
  
   

This method, like the one below, destroys the abstract consistency of this method in the middle of an extra section. The code for abstract consistency reads as if it were a native requirement. Code that is abstract consistent, whether in readability or in extensibility or in the troubleshooting of problems, is better than one. This is also the reason why the comments are less, the code itself is a comment.

Problem

Of course, some of the problems are that the private methods inside the method can change a lot. Refer to my last question [about business layering]
(http://segmentfault.com/q/1010000002631646 "About business tiering").

Of course, if the requirements are simple, or the business unit is very heavy code does not need to consider so much.

May I ask what you think of this?

In fact, the project has been done over the years, experienced and learned a lot of design, such as: to give you documents to write exactly according to the document and even the method name in each service has specifications, but not strictly to how to achieve them, I think this is the half-blank coding There is a complete fill in the blanks coding even said that the method of invocation has reference documentation, so that you do the purpose is to call who who fills in, this is completely filled in the blanks coding, the need to design their own to achieve, I think it is all-inclusive coding ah, small companies a lot of such And there is an inherited project that already exists and has its own architecture, and we do it to perfect it and plump it; the company has a new case to start from scratch, your team has the structure of PG has QA, this should be considered more normal.

The above mentioned examples have not found a problem, in addition to strict restrictions on what you want to do and what you can only do, in fact, in the team development of your role in determining the direction of the framework, do the UI just care about the view, even they just look at the js CSS Pure UI Oh! The service only cares about the foreground and his interaction, how he interacts with DAO. Do DAO only care how to give the service told me to the DB, how to give the db thing to the service.

Said these may think I digress too serious, not really! The example I mentioned above could not contain all, just a small part, just like the design pattern, I once saw someone say "what design patterns Ah, a lot of this so-called design patterns in other languages have no meaning" (I do Java), he said some of the right, Just as China has been fastidious about imperfection from ancient times, what does that say? "Avenue 50, Day Yan 49, stay chance, go to a together", don't noisy! I'm not looking at fairy-story novels!

What I want to say is not perfect! People are not perfect, things are not perfect, with your knowledge, experiences, experience always look perfect from the past to find out the imperfect side, so we still do not bother to pursue the perfect, if the perfect there will not be how many kinds of design patterns, a enough, and what NoSQL, There is also the MVC framework, MVC is just a mainstream, and many are not named (because they may not have a good name at all).

Well, the question of the Lord I have not seriously reply to this is not right, said above is to say a truth, do their own in this moment think is the right thing can, later things can be appropriate to think, but you actually have a length of this later, think is always not too far.

Here's the answer to the question.

public void composeOrder(B b){ List list = new ArrayList(); Map map = new HashMap (); for(A a : list ){ map.put(a.getId,a); } composeSku(); calculateShipping(); createPageage(); }

This code, you think and context inconsistencies, "about business stratification" of the post deliberately to see the next, someone mentioned with Helper,manager,facade to do that part of the "disharmony" code is right, even if you are prepared with XX to do all can, is not a name? What we want is a kind of thought! I realized that this "disharmony", I went to make it look "harmonious" point Bai.

In fact, we write a lot of code around, are process-style writing.

I very much agree with this sentence, remember that before learning Oo, the teacher and I speak a lot of language are process, function, program, method, Java is object-oriented, sounds tall, but the actual? It's like watching CCAV at home every day, but how about going out? There is always a gap between reality and imagination.

The real use of the time is always easy to figure out the "tedious" OO code, such as the following paragraph

class 我{ N种牛X的属性。。。 public void 做超人(){ 无敌了。。想到什么都写这里 }}

A method is Superman, cattle are not cattle? Why don't you think about it when you write it, you have to have a red underwear to change it? What would Superman do? Do you have an optical class that has a laser in your eyes? The Force is infinite? Well, that's the least of the human body science involved. You can fly! We're here to reuse the human body! Superman, isn't there a woman? But there's one thing that women can't do, Oh!

class 她{ N种牛X的属性。。。 public void 做超人(){ 无敌了(比“我”差一点 ,有件事不能做!)。。想到什么都写这里 }}

PS: I am a man, so the above did not write male Superman, hehe.

All right, female Superman is miserable. We let her do one less thing, but they are all Superman! How can I write 2 classes? I'm going to write one! But I am a Superman method Ah, how to do? In this way, we have to inherit the advantages of male Superman! No, let's just reload and do Superman's method. The following will not be written, polymorphic children are coming out.

Above the spoof, a lot of concepts work more than a few people understand, in fact, the concept will not be remembered is very clear, but all know is how, I also remember is not very clear, but is casually write, even see may have problems, but always from an angle to see can say through!

Isn't that the design? Isn't that just layering? Isn't that what you do? Learn Java at the beginning of the OO concept, in fact, I always feel and the phrase "Tao can road, very way" very same, the Tao is not that they say things the same, but the kind of description of the feeling is very similar, some things may be said not clear, but you understand that this is imaginative achievement here inexpressible Ah, Before in Segmentfault saw an example (human play poker drive and so on ...). To help say how to write class, or Segmentfault not many people, or many people do not see this problem, I dare say if there are 100 people let them write, there may be 101 ways, you can not ask a person can only write one.

Say these, write may be a bit miscellaneous a bit messy, big guy to see a happy is over, haha.

What you're talking about is the concept of structured programming, and the basic idea is that the process of each layer is similar to the catalogue of a book, from the whole book to the chapter to the section.
While object-oriented, there is a case where an object requests a service from another object. But there is a subtle difference from structured programming. It's more like a logic circuit made up of different chips. There is not necessarily a subordinate relationship between the various objects, but more emphasis is placed on the attribution of knowledge and the responsibility of different objects.
NetEase Open class has a programming paradigm course, if you have the patience to read, should help you understand the problem.

  • Contact Us

    The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

    If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

    A Free Trial That Lets You Build Big!

    Start building with 50+ products and up to 12 months usage for Elastic Compute Service

    • Sales Support

      1 on 1 presale consultation

    • After-Sales Support

      24/7 Technical Support 6 Free Tickets per Quarter Faster Response

    • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.