Drink Remodeling Series [3]--Method, field promotion and reduction

This article introduces 4 refactoring strategies, namely, the promotion method, the decrease method, the Elevation field, and the lower field.
Since these 4 refactoring strategies have some similarities, I put them in one article to explain.

Defined

Here are the definitions of these 4 strategies

Promotion method: This method should be promoted to the base class when the subclasses ' methods describe the same behavior.
Reduction method: When the behavior in the base class is related only to individual subclasses, the behavior should be reduced to subclasses.
Ascending field: When a field in a subclass describes the same information, the field should be promoted to the base class.
Decrease field: When the fields in the base class are used only for individual subclasses, you should reduce such fields to subclasses.

The above definition is more boring, the reader can not need care text content, because this is my own understanding, you should have their own understanding.
Next, I want to introduce the focus of this article-semantics, which helps us understand and use these refactoring strategies well.

The "semantics" of Things

In the previous article, I often mentioned a word "semantics", which is a more abstract word. The following citation is a semantic interpretation of the content from the Baidu Encyclopedia.

The meaning of the data is semantics (semantic). Simply put, the data is the symbol. The data itself is not 佮 meaning, only the meaning of the data can be used, when the data is converted to information, and the meaning of the data is semantics.

Semantics can simply be thought of as the concept and meaning of things in the real world that the data correspond to, as well as the direct relation of these meanings, and the interpretation and logical representation of data in a certain domain.

Semantics have domain characteristics, and semantics that do not belong to any domain do not exist.

And my understanding of it is: in the context of things, the concept of things and the meaning of the expression.
Here are 2 points to emphasize:

1. Things: Refers to the real world (real) existence of individuals, such as a person, a car. This is what we call the object.
2. Environment: Refers to the real world environment, we can also understand the environment as the context.

We need to combine these 2 points to understand semantics, things can not be separated from the environment alone, things in different circumstances show the characteristics and behavior will be different.

For example: An ordinary Volkswagen Jetta, if it is in a "taxi company" Such a context, then it is characterized by "taxi", reflects the behavior is "to provide the public with paid bus service."
If the car is in a "someone's car" such a context, then its performance is characterized by "private car", the embodiment of the behavior is "car owners can self-drive to do XXX."

When you see the next two cars on the street, you take it for granted that the "Taxi" is on the left and the "private car" on the right.

You are almost conditioned to know the semantics of these two cars! Why are you able to define them so quickly?
Because we have enough knowledge of these two cars, even if we do not touch them, but combined with our own know-how and experience, the meaning they represent has been deeply engraved in our hearts.

From this example we can easily see that when things are in different environments, they behave differently in terms of their characteristics and behavior.
This is also called "Semantic heterogeneity", it refers to the same thing in the interpretation of the differences, but also reflected in the same thing in different areas of the understanding of different.

In addition, because of children's cognitive deficiencies, their understanding of the two cars and adults will be different.

Kid: "These two cars can take me to the amusement park to play"
Adult: The car on the left can "provide the public with paid bus services", the car on the right side "owners can self-drive to do XXX"

Children's cognition of things is shallow, so their subjective judgment is more superficial.
Adults, because they have enough knowledge of things, so their subjective judgment is more profound.

Everyone is grown from a child to an adult, and people are going through the process of exploring and understanding things. At different times, different situations, people's cognition and understanding of the same thing is different.

Now that we have a general introduction to semantics, we are formally entering the Example section of this article. The following 4 sample code is very simple, so combine semantics to feel these 4 refactoring strategies.

Elevation method when a subclass's methods describe the same behavior, the method should be promoted to the base class.

Represents the refactoring strategy (blue indicates refactoring before, red indicates refactoring)

When the method is promoted to the base class, you should be aware of two points:

1. The behavior implementation details defined in the base class should be common to all subclasses.
2. Subclasses should have the ability to override the behavior of the base class, which should be appended to the details of the behavior and should not arbitrarily tamper with the behavior details of the base class (you can do it, but I don't recommend it) sample refactoring before

This code defines 3 classes: vechicle (motor vehicle), car (motor vehicle) and motorcycle (motorcycle). The turn () method is defined in car to indicate the driving behavior of the car.

namespace pullupmethod.before{public    abstract class Vehicle    {        //other methods    } public    class Car : Vehicle    {public        void Turn (Direction Direction)        {            //code here        }    } public    class Motorcycle:vehicle    {    } public    enum Direction    {left        ,        right    }}

In this scenario, motorcycle also has a driving behavior, and if a turn () method is also defined in motorcycle, it can cause semantic duplication, so we should elevate the turn () method in car to the base class vehicle.

After refactoring

namespace pullupmethod.after{public    abstract class Vehicle    {public        virtual void Turn (Direction Direction )        {            //base class behavior implementation details        }} public class    car:vehicle    {            }    public class motorcycle:vehicle< c11/>{public        override void Turn (Direction Direction)        {            //Use the base class behavior for detail            base. Turn (direction);            Append the behavior details of some subclasses themselves        }    } public    enum Direction    {left        ,        right    }}

The turn () method of the vehicle class uses the virtual keyword, which we can override in subclasses when the implementation of the base class does not meet the requirements of the subclass.

Reducing the behavior of a method in a base class is only related to individual subclasses, and should be reduced to subclasses.

Represents the refactoring strategy (blue indicates refactoring before, red indicates refactoring)

Example before refactoring

This code defines 3 classes: Animal (Animals), Dog (dogs), and Cat (cat), which define the bark () method in Animal, which represents the bark behavior of animals.

namespace pushdownmethod.before{public    abstract class Animal    {public        void Bark ()        {            //code to Bark        }    } public class Dog:animal {} public    class Cat:animal    {    }}

In this scenario, the dog can bark, the barking behavior is not part of the Cat,cat only meow, so the bark () method should be lowered to the dog class.

After refactoring

namespace pushdownmethod.after{public    abstract class Animal    {    } public    class Dog:animal    { c18/>public void Bark ()        {            //code to Bark        }    } public    class Cat:animal    {    }}

Ascending field when a field in a subclass describes the same information, the field should be promoted to the base class.

Represents the refactoring strategy (blue indicates refactoring before, red indicates refactoring)

In C #, fields are usually decorated with private. When using this refactoring strategy, the fields promoted to the base class should at least use the protected modifier in order for the subclass to be accessible.

Example before refactoring

This code defines 3 classes: Account, Checkingaccount (current account) and Savingaccount (savings account), Checkingacount and Savingaccount are inherited from accounts.

namespace pullupfield.before{public    abstract class account    {    } public    class Checkingaccount:account    {        private decimal _minimumcheckingbalance = 5m;    }    public class Savingaccount:account    {        private decimal _minimumsavingbalance = 5m;    }}

In this scenario, both Checkingaccount and Savingaccount define the minimum balance field, although the name is different, but the meaning of the representation is the same, so the minimum balance field should be defined in the account, and the field will be decorated with protected.

After refactoring

namespace pullupfield.after{public    abstract class account    {        protected decimal _minimumbalance = 5m;    } public    class Checkingaccount:account    {    } public    class Savingaccount:account    {     }}

Decrease field when the fields in the base class are used only for individual subclasses, you should reduce such fields to subclasses.

Represents the refactoring strategy (blue indicates refactoring before, red indicates refactoring)

Example before refactoring

This code defines 3 classes: task, Bugtask (defect Task), and Featuretask (functional task), and the base class task defines the _resolution field.

namespace pushdownfield.before{public    abstract class Task    {        protected string _resolution;    }    public class Bugtask:task    {    } public    class Featuretask:task    {            }}

In this scenario, the _resolution field represents the "resolution state of the Bug", which is related to the Bugtask class, which is irrelevant to the feature class, so the _resolution field should be defined in the Bugtask class and decorated with private.

After refactoring

namespace pushdownfield.after{public    abstract class Task    {     } public    class Bugtask:task    { C15/>private string _resolution;    }    public class Featuretask:task    {    }}

Summarize

These 4 methods are simple refactoring strategies and are often used refactoring strategies.
If we want to use these strategies well, we need to have a clear understanding of the semantics of classes, methods, and fields.

Even a simple refactoring strategy requires a tradeoff, which could result in "over-refactoring" or "refactoring inappropriately."
If you are just beginning to experience refactoring, do not worry too much about these two points, you can find these two problems, you have been thinking, you need to go through the process to grow.

Drink Remodeling Series [3]--Method, field promotion and reduction