же реализация в различных подклассов

Question

Скажем, у меня есть следующий сценарий:

abstract class A { 
     abstract method1(); 
     abstract method2(); 
    } 

    class B extends A { 
     method1() { 
      // implementation 1 
     } 
     method2() { 
      // implementation 3 
     } 
    } 

    class C extends A { 
     method1() { 
      // implementation 1 
     } 
     method2() { 
      // implementation 4 
     } 
    } 

    class D extends A { 
     method1() { 
      // implementation 2 
     } 
     method2() { 
      // implementation 4 
     } 
    } 

Итог: несколько подклассов одного и того же класса, с использованием различных реализаций метода для различных методов.

Проблема в том, что у меня такая же реализация в разных подклассах. Мой вопрос в том, что делать с этими общими реализациями?
Логичным способом сделать это было бы создание другого уровня абстракции, но это работает только в том случае, если у меня есть один метод с общими реализациями (поскольку Java не имеет множественного наследования). Я мог бы также применить реализацию, наиболее часто используемую в суперклассе, и реализовать ее по-другому в других классах. Тем не менее, я бы этого не сделал, потому что со временем наиболее распространенная реализация может измениться с добавлением других классов, и, кроме того, я хотел бы сохранить методы абстрактными в суперклассе.

Есть ли какой-нибудь шаблон, который бы разрешил мою проблему в «элегантной манере»?

Answer 1

Вы работаете в классический вопрос ООП с наследованием heirarchies становятся громоздким :-)

Моих предлагаемых решений:

• Предпочитает композицию наследования - вынесут реализации на отдельные объекты, которые могут быть «подключены», чтобы обеспечить требуемое поведение. Методы в вашем базовом классе просто вызывают плагин реализации через определенный интерфейс. Это в основном Strategy Pattern. Это очень надежный подход, хотя иногда он может быть подвержен большому количеству чрезмерной инженерии/шаблону, когда у вас много разных типов стратегий.
• Принять модель на основе прототипа - использовать prototype-based объекты, а не традиционные ООП. Это решает все проблемы - вы избегаете присущих ограничений иерархии наследования и можете просто скопировать реализацию, которую вы хотите, в зависимости от того, какие объекты ей нужны во время выполнения. Это самый радикальный вариант, но может принести некоторые большие выгоды.
• Фактор реализации в статических функциях - таким образом вы можете поделиться реализациями - это немного беспорядочно, поскольку вам все равно нужно выполнять все переопределения, но они просто становятся однострочными, делегируя вызов правильной реализации. Это часто наименее интрузивный вариант.

Answer 2

Я бы порекомендовал композицию. Учитывайте следующее:

interface I1 { 
    method1(); 
} 

abstract class A implements I1{ 
    abstract method1(); 
    abstract method2(); 
} 

class CommonOperations implements I1 { 
    method1() { 
     // implementation 1 
    } 
} 

class B extends A { 
    CommonOperations common; 

    method1() { 
     common.method1(); 
    } 
    method2() { 
     // implementation 3 
    } 
} 

class C extends A { 
    CommonOperations common; 

    method1() { 
     common.method1(); 
    } 
    method2() { 
     // implementation 4 
    } 
} 

class D extends A { 
    method1() { 
     // implementation 2 
    } 
    method2() { 
     // implementation 4 
    } 
}