Class abstraction Design Problems

{Code...} requires a new class D at this time. The lockA rules of class D are the same as those of class C. So here are the following writing methods: Write 1 {code ...} code 2 {code ...} writing Method 3 {code ...} write a statement by combining class C into Class D, and then introduce the method of Calling C lockA ()...

    public interface A{       void a();    }        public abstract class B{        protected abstract boolean lockA();                public void a(){            if(lockA()){                do();            }        }                protected abstract void do();    }        public class C extends B implements A{        public boolean lockA(){            return true;           }                public void do(){            //TODO one        }    }

In this case, a new class D is required. The lockA rules of class D are the same as those of C. Therefore, the following statements appear:

• Method 1

     public class D extends B implements A{       private C c = new C();               public boolean lockA(){             c.lockA();       }              public void do(){           //TODO two       }   }

• Statement 2

     public class D extends C implements A{        public boolean lockA(){             super.lockA();       }              public void do(){           //TODO two       }   }   

• Statement 3

     public interface Lock{       boolean lockA();   }      public interface DO{       void do();   }      public class C extends B implements A{       private Lock lock;              private DO do;          public boolean lockA(){           return lock.lockA();          }              public void do(){           do.do();       }   }   

  Write a statement by combining class C into Class D, and then introduce the method of Calling C lockA ()

Method 2: Use the inherited method to reuse lockA ()
Write 3: Use Lock and Do to make an abstraction and call it in combination. The flexibility and scalability of this method are high. It is also my favorite practice.

For example, in method 1 and method 2, it may not be necessary for me. The only difference between method 3 and method 1 and method 2 is that the design is more reasonable at the class level, because C and D are both subsets of A. If there is still dependencyFeelingUnreasonable.

Recently I got into a strange circle, and I have been thinking about what the code looks like to be a good code. Most of the time, I choose the encoding method based on my own feeling. For example, I will choose method 3 based on my feeling. There are still many situations where I will judge the quality of a piece of code based on my own feelings, but sometimes I will ask myself, or let me give a counterexample to illustrate that the current method is not good, I can think of it for a long time, or even cannot think of it, because I often find myself judging whether a piece of code is elegant according to my feelings ....

Hope you can advise me if you have any experience. Thank you.

Reply content:

    public interface A{       void a();    }        public abstract class B{        protected abstract boolean lockA();                public void a(){            if(lockA()){                do();            }        }                protected abstract void do();    }        public class C extends B implements A{        public boolean lockA(){            return true;           }                public void do(){            //TODO one        }    }

In this case, a new class D is required. The lockA rules of class D are the same as those of C. Therefore, the following statements appear:

• Method 1

     public class D extends B implements A{       private C c = new C();               public boolean lockA(){             c.lockA();       }              public void do(){           //TODO two       }   }

• Statement 2

     public class D extends C implements A{        public boolean lockA(){             super.lockA();       }              public void do(){           //TODO two       }   }   

• Statement 3

     public interface Lock{       boolean lockA();   }      public interface DO{       void do();   }      public class C extends B implements A{       private Lock lock;              private DO do;          public boolean lockA(){           return lock.lockA();          }              public void do(){           do.do();       }   }   

  Write a statement by combining class C into Class D, and then introduce the method of Calling C lockA ()

Method 2: Use the inherited method to reuse lockA ()
Write 3: Use Lock and Do to make an abstraction and call it in combination. The flexibility and scalability of this method are high. It is also my favorite practice.

For example, in method 1 and method 2, it may not be necessary for me. The only difference between method 3 and method 1 and method 2 is that the design is more reasonable at the class level, because C and D are both subsets of A. If there is still dependencyFeelingUnreasonable.

Recently I got into a strange circle, and I have been thinking about what the code looks like to be a good code. Most of the time, I choose the encoding method based on my own feeling. For example, I will choose method 3 based on my feeling. There are still many situations where I will judge the quality of a piece of code based on my own feelings, but sometimes I will ask myself, or let me give a counterexample to illustrate that the current method is not good, I can think of it for a long time, or even cannot think of it, because I often find myself judging whether a piece of code is elegant according to my feelings ....

Hope you can advise me if you have any experience. Thank you.

If you want to consider the advantages and disadvantages of the several methods you listed, I think it is best to set it to the actual situation. The so-called design pattern is just an abstraction of common programming ideas. There is no good or bad between the design patterns. Only who is better suited to the actual situation. Therefore, simply comparing several design patterns cannot be well analyzed.

In addition, I think you can try php trait to implement the above idea. I think it requires less code than the above method, and more compatible scenarios.

The reason is that it never hurts.

In this case, just pick a way to finish writing.

After a certain amount of code has been accumulated and several versions have been iterated back and forth for modification, you will feel like this next time.

"The last time I did that, the code turned into a piece of garbage that could not be maintained. This time I had to avoid it from the very beginning"