Мероси сершумор дар Java. Муқоисаи таркиб ва мерос

"Мушкилоти алмос"

package com.journaldev.inheritance;
public abstract class SuperClass {
   	public abstract void doSomething();
}

package com.journaldev.inheritance;
public class ClassA extends SuperClass{
    @Override
 public void doSomething(){
        System.out.println("Какая-то реализация класса A");
    }
  //собственный метод класса  ClassA
    public void methodA(){
    }
}

package com.journaldev.inheritance;
public class ClassC extends ClassA, ClassB{
    public void test(){
        //вызов метода родительского класса
        doSomething();
    }
}

Мерос ва интерфейсҳои сершумор

package com.journaldev.inheritance;
public interface InterfaceA {

    public void doSomething();
}

package com.journaldev.inheritance;

public interface InterfaceB {

    public void doSomething();
}

package com.journaldev.inheritance;

public interface InterfaceC extends InterfaceA, InterfaceB {

    //метод, с тем же названием описан в  InterfaceA и InterfaceB
    public void doSomething();

package com.journaldev.inheritance;

public class InterfacesImpl implements InterfaceA, InterfaceB, InterfaceC {

    @Override
    public void doSomething() {
        System.out.println("doSomething реализация реального класса ");
    }

    public static void main(String[] args) {
        InterfaceA objA = new InterfacesImpl();
        InterfaceB objB = new InterfacesImpl();
        InterfaceC objC = new InterfacesImpl();

        //все вызываемые ниже методы получат одинаковую реализацию конкретного класса

        objA.doSomething();
        objB.doSomething();
        objC.doSomething();
    }
}

Композиция How спасение

package com.journaldev.inheritance;

public class ClassC{

    ClassA objA = new ClassA();
    ClassB objB = new ClassB();

    public void test(){
        objA.doSomething();
    }

    public void methodA(){
        objA.methodA();
    }

    public void methodB(){
        objB.methodB();
    }
}

Композиция or наследование?

1. Предположим, мы имеем следующую связку классов родитель-наследник:

   ClassC.java

   package com.journaldev.inheritance;
   
   public class ClassC{
   
   public void methodC(){
     	}
   
   }

   ClassD.java

   package com.journaldev.inheritance;
   
   public class ClassD extends ClassC{
   
       public int test(){
           return 0;
       }
   }

   Код выше прекрасно компorруется и работает, но что, если ClassC будет реализован иначе:

   package com.journaldev.inheritance;
   
   public class ClassC{
   
       public void methodC(){
       }
   
       public void test(){
       }
   }

   Отметьте, что метод test() уже существует в классе наследнике, но возвращает результат другого типа. Теперь ClassD, в случае если вы используете IDE, не будет скомпorрован. Вам будет рекомендовано изменить тип возвращаемого результата в классе наследнике or в суперклассе.

   Теперь представим себе такую ситуацию, где имеется многоуровневое наследование классов и суперкласс не доступен для наших изменений. Теперь, чтобы избавиться от ошибки компиляции, у нас нет других вариантов, кроме How изменить сигнатуру or Name метода подкласса. Также нам придется внести изменения во все места, где этот метод вызывался. Таким образом, наследование делает наш code хрупким.

   Проблема, описанная выше, никогда не встречается в случае композиции, и поэтому делает последнюю более предпочтительной перед наследованием.

2. Следующая проблема с наследованием заключается в том, что мы демонстрируем все методы родителя клиенту. И если суперкласс разработан не очень корректно и содержит дыры в «безопасности». Тогда, несмотря на то, что мы fully позаботимся о безопасности при реализации нашего подкласса, мы все равно будем зависеть от ущербной реализации класса-родителя.

   Композиция помогает нам в обеспечении контролируемого доступа к методам суперкласса, тогда How наследование не поддерживает ниHowого контроля над его методами. Это - также одно из главных преимуществ композиции над наследованием.

3. Бартарии дигари таркиб дар он аст, ки он ҳангоми даъват кардани усулҳо чандирӣ медиҳад. Татбиқи синфи ClassCдар боло тавсифшуда оптималӣ нест ва ҳатмии барвақтро ба усули даъватшуда истифода мебарад. Тағироти ҳадди ақал ба мо имкон медиҳад, ки усули зангро чандир созем ва ба дер ҳатмӣ (ҳатмӣ дар вақти корӣ) иҷозат диҳем.

   ClassC.java

   package com.journaldev.inheritance;
   public class ClassC{
       SuperClass obj = null;
       public ClassC(SuperClass o){
           this.obj = o;
       }
       public void test(){
           obj.doSomething();
       }
   
       public static void main(String args[]){
           ClassC obj1 = new ClassC(new ClassA());
           ClassC obj2 = new ClassC(new ClassB());
   
           obj1.test();
           obj2.test();
       }
   }

   Барномаи боло нишон медиҳад:

   doSomething implementation of A
   doSomething implementation of B

   Ин чандирии даъвати методӣ бо мерос дида намешавад, ки таркибро беҳтарин равиш месозад.

4. Санҷиши воҳидҳо дар мавриди таркиб осонтар аст, зеро мо медонем, ки барои ҳама усулҳои дар суперкласс истифодашуда мо метавонем санҷишҳоро нопадид кунем, дар ҳоле ки дар мерос мо аз суперкласс вобастаем ва намедонем, ки усулҳои синфи волидайн чӣ гунаанд истифода мешавад. Ҳамин тавр, аз сабаби мерос мо бояд тамоми усулҳои суперклассро санҷем, ки ин кори нодаркор аст.

   Идеалӣ, мерос бояд танҳо вақте истифода шавад, ки муносибати " аст-a " барои синфҳои волидайн ва кӯдакон дуруст бошад, вагарна таркиб бояд бартарӣ дода шавад.