Extended functions = inherit?

We all know that we have learned object-oriented, through inheritance: We can reuse and expand the code that has been thoroughly tested without modifying it. But as mentioned in the Policy mode, inheritance will ban class methods. So if we want to extend the function, do we still have to use inheritance?

The answer is no, of course, because the Design Pattern provides us with a good pattern-the decoration pattern: dynamically attaching responsibility to objects. The so-called dynamics can be simply understood as flexible. So how can we achieve our goal without using inheritance? Let's take a look.

Let's take a look at an example. When we buy coffee in a coffee shop, there are different types of coffee: comprehensive, deep baking, low caffeine, and concentrated. However, drinking coffee is not that simple. It also needs to add ingredients to satisfy customers' taste needs: milk, soy milk, Moka, and milk bubbles. Now there are some new tastes and types to be added to the coffee shop, so the original inheritance system will no longer apply. Once the types and types are increased, the figure below will become a glimpse:

So what kind of decoration mode should be used?

As shown in the figure above, we use the specific coffee type and ingredients as sub-classes of A Class. Through the free combination of types and ingredients, we can achieve code reusability at the same time, improve maintainability in the future. The Code is as follows:

1. abstract class

<Span style = "font-size: 18px;"> package Baz coffee; // This is an abstract class. Public abstract class beverage {string description = "unknown beverage"; Public String getdescription () {// gets the return description;} public abstract double cost ();} </span>

2. Specific components

public abstract class CondimentDecorator extends Beverage {public abstract String getDescription();}public class DarkRoast extends Beverage {public DarkRoast() {description ="DarkRoast Coffee";   }public double cost(){return .99;}}</span>

public class Espresso extends Beverage {public Espresso (){description ="Espresso";}public double cost(){return 1.99;}}

public class HouseBlend extends Beverage {public HouseBlend(){description ="House Blend Coffee";}public double cost(){return .89;}}</span>

Several other classes are similar to the ones listed above. You can implement them manually. The following results will be achieved:

If you need to pay for the capacity of the cup in the store, you can add three classes in condimentdecorator: Medium cup, small cup, and large cup. Add the method to the abstract class: getsize () obtain the cup type, and then use different combinations of cup type, coffee type and ingredients to Achieve flexible charges. In this way, dynamic addition and decoupling are achieved. Isn't it just a matter of two?

Summary:

1. In decoration mode, the combination and delegation are used to dynamically add functions to the system during system operation. In this mode, we need to create a bunch of decorators, which are used to decorate components, for example: mocha, whip, and other four ingredients are used to decorate houseblend and darkroast coffee types.

2. We can use one or more decorators to package one component: Prepare a medium cup of Low-caffeine coffee that includes milk, Moka, and so on.

3. the decorator will lead to many small objects in the design. If it is used excessively, the program will still become complicated. That is to say, we cannot infinitely expand the types and ingredients of coffee, otherwise the system will be slow or even paralyzed because of too many coffee types and ingredients. Everything follows the same level of problem, the food is delicious, the model is easy to use, and the system cannot be dragged to death.

So, to a certain extent, the modifier mode is still great.

Finally, let's go !!

Extended functions = inherit?