The origin of the Java decorative design pattern

Decorative design pattern: Provides enhanced functionality based on existing features

The origin of the decorative design pattern:

Reader

----TextReader

----Mediareader

To provide buffered read functionality for subclasses

Reader

----TextReader

----Bufferedtextreader

----Mediareader

-----Bufferedmediareader

Reader

----TextReader

----Bufferedtextreader

----Mediareader

-----Bufferedmediareader

----Otherreader

-----Bufferedotherreader

Since it is all a function of buffering read, it is possible to extract this function and define it individually as a class.

Who needs to be more efficient, pass on who as a parameter to the constructor of this class

Class BufferedReader

{

Privatereader R;

Publicbufferedreader (Reader R)

{

THIS.R = R;

}

}

The system will look like this:

Reader

----TextReader

----Mediareader

----Otherreader

----BufferedReader

Features of the decorative design pattern:

1: Because it is based on existing features to provide enhanced functionality, it is also part of the original system

2: It's a system that simplifies

Example Description:

Import java.io.*;//implement Linenumberreaderclass Mybufferedreader//extends reader{private reader r;//The private char that is really used to read the file [] arr = new char[1024];//equivalent to the buffer private int index;//array uses the subscript private int count;//The variable that stores the number of characters public Mybufferedreader (Reader R ) {THIS.R = R;} Implements the ability to read one character at a time public int myread () throws ioexception{//If there is no data in the buffer, the data is read from the file to the buffer if (count==0) {count = R.read (arr  );//Read the data from the file to the buffer, return the number of characters read index = 0;//subscript reset to 0, read a batch of data from the file, starting from subscript 0 to take}if (count<0) return-1;//from the buffer to take a character int num = arr[index];//subscript plus 1index++;//quantity minus 1count--;return num;}  Implement the ability to read one line at a time//repeatedly call Myread (), not enough time to store, enough time to return to public String Myreadline () throws ioexception{//use StringBuilder to implement storage          StringBuilder sb = new StringBuilder ();  int ch;  while ((Ch=myread ())!=-1) {if (ch== ' \ R ') continue;  else if (ch== ' \ n ') return sb.tostring ();  Else Sb.append ((char) ch); } return null; public void Myclose () throws Ioexception{r.close ();}} Class Mylinenumberreader extends Mybufferedreader{private int Linenumber;publIC Mylinenumberreader (Reader R) {super (R);} public void Setlinenumber (int linenumber) {this.linenumber = linenumber;} public int Getlinenumber () {return this.linenumber;} Public String Myreadline () throws IOException {++linenumber;return super.myreadline ();}} Class Demo7{public static void Main (string[] args) throws IOException {FileReader fr = new FileReader ("Demo5.java");//is a loaded Adorn Mylinenumberreader LNR = new Mylinenumberreader (FR); String line = Null;lnr.setlinenumber, while (line = Lnr.myreadline ())!=null) {System.out.println ( Lnr.getlinenumber () + ":" +line);} Lnr.myclose ();}}

1) Inheritance is one of the extension forms, but not necessarily the best way to achieve elastic design.

2) in the design, the behavior should be allowed to be extended without having to modify the existing code.

3) Combinations and delegates can be used to dynamically add new behavior at run time.

4) In addition to inheritance, decorator mode also allows us to expand behavior.

5) Decorator mode means a group of decorator classes, which are used to package specific components.

6) The Decorator class reflects the type of component being decorated (in fact, they have the same type, all through interfaces or inheritance implementations).

7) The decorator may add his or her own behavior in front of and/or behind the act of the decorator, or even replace it with the entire act of the decorator and achieve a specific purpose.

8) A component can be packaged with countless decorators.

9) The decorator is generally transparent to the customer of the component, unless the client program relies on the specific type of the component.

10) Decorators can cause many small objects to appear in the design, which can complicate the program if overused.

The origin of the Java decorative design pattern