Решение задачи без множественного наследования?

Question

[Damaskus]

В системе присутствует 2 основных класса объектов: документы и справочники,

те в свою очередь наследуются от некоего общего базового класса.




Проблема появилась в тот момент, когда некоторым из потомков DICTIONARY и DOCUMENT

понадобилось привить некий дополнительный функционал по работе с флагами (чек боксы, по сути не важно, имеются ввиду любые дополнительные свойства и методы)

Причем этому функционалу было достаточно набора данных имеющемся в BASE


Тут можно сказать, что функционал для работы с флагами можно внести в BASE и забыть.

С этим есть проблема:

В иерархии между базовым классом и объектами использующие флаги есть много документов, которым этот функционал не нужен.

И менять базовый класс ради отдельных документов/справочников (добавлю что их немного) никто не будет и не даст, еще по башке надают.


В С++ можно было бы на нужном нам уровне иерархии привить нужные методы.

В Java же приходится изгаляться.


Предлагаемые решения:

I

Копируем методы для работы с классами в каждую ветку иерархии — копипаст. Некрасиво, источник потенциальных ошибок.

II

Создаем методы в каждом классе и делегируем их в статический метод третьего класса со ссылкой на объект.

Тут могут быть неудобства. Метод не будет иметь доступа к private и, возможно, protected свойствам.

(frend class вроде как в Java нет, поправьте меня, если неправ)

Это значит что придется в справочники и документы добавлять геттеры и сеттеры для недоступных полей.


Есть идеи, как в Java более элегантно решить этот вопрос?

Answer 1

[Shedal]

Ваш второй вариант уже ближе к правильному. Не совсем понятно, почему вы хотите сделать методы статическими, я бы создавал объект класса внутри. Но возможно, вам действительно больше подходит статика.

По поводу доступа к приватным полям — эту проблему можно решить, например, создав event'ы во вспомогательном классе, и затем подписать на них методы основого класса.

Comments

[Damaskus]

Можете поподробней рассказать про идею с event'ами?
Не совсем понял о чем речь.

[Shedal]

Damaskus, оказывается, в Java нет специального механизма событий (который есть, например, в C# — ключевое слово event). Но их можно реаилзовать вручную при помощи интерфейсов. Например: stackoverflow.com/a/1530497/236660
Суть в том, что в основном классе (документ, справочник) есть методы, которые предназначены для реагирования на события, которые возникают во вспомогательном объекте (FlagFunctioner по терминологии phil_tsarik). Когда объект FlagFunctioner создаётся внутри объекта Document, то Document подписывает свои методы на события FlagFunctioner (addSomeEventHandler(this.mySomeEventHandler)).

Answer 2

[asm0dey]

Есть вариант написать класс на скале, например. В ней, если мне память не изменяет, есть множественное наследование.

Answer 3

[Arktos]

Можно не добавлять геттеры и сеттеры, а использовать Reflection (методы getClass, class.getField, field.setAccessible, field.get, field.set)

Answer 4

[Ivan Komarov]

Java практически не знаю, но всегда думал, что в Jave принято решать такие вещи через интерфейсы.
public class MixedDict extends Dictionary implements Flagable


Comments

[Damaskus]

Проблема не в интерфейсе, а в реализации.

[Анатолий]

дублируйте реализацию, однозначно нужны интерфейсы, либо все в родителя выносите.

[Анатолий]

Не хочется копипастить, делегированием проблему решить вообще не составит труда.

[Damaskus]

> Не хочется копипастить
А вам бывает хочется? :-)

[Анатолий]

Тогда остается делегирование. Хотя если нужно пару строк кода, то я бы лучше скопипастил.

[Damaskus]

Проблема в том, что функционал не тривиальный, и багофиксить нужно будет тоже в 2-х местах, если что. Это не есть хорошо, особенно в больших проектах, где разработчик может не иметь информации о системе в целом.

[Анатолий]

Нет, багофиксить придется в одном месте

function A(q,w,e)
{
    return this.delegatedObj.A(q,w,e);
}

Внутри делегата уже делайте что хотите.

[Damaskus]

Я имел ввиду вариант I

[Анатолий]

Вы сами уже убедили всех вокруг да и похоже самого себя что копипаст не катит, остается делегирование =)

Answer 5

[phil_tsarik]

Возможно, такое подойдет:
в каждом классе Some_WithFlags держать объект FlagFunctioner. Класс FlagFunctioner должен иметь все необходимые public методы, чтобы работать с ним. плюс будут видны protected, если находятся в одном пакете.
В Some_WithFlags создать getter для FlagFunctioner, если надо его доступность извне.

Может быть вы и имели это ввиду под пунктом II, только я не понял о чем у вас там речь.
> Создаем методы в каждом классе и делегируем их в статический метод третьего класса со ссылкой на объект.

Comments

[Damaskus]

Да, я именно это и имел ввиду.

Answer 6

[leventov]

Можно подождать (1 год) Java 8 c дефолтными реализациями в интерфейсах :)

Comments

[Damaskus]

Все равно делегировать придется.

[leventov]

Damaskus, имеете ввиду все равно не получается доступа к внутреннему состоянию? Во-первых, можно будет сделать интерфейс вложенным в BASE, ведь интерфейсы с extension methods очень похожи на абстрактные классы, а их делать вложенными можно. Во-вторых, чем тогда поможет миксин в Си++ (или что вы имеете ввиду под «прививанием» нужных методов)?

Answer 7

[serso]

Во-первых, делегирование — правильное решение в данном случае (вы, по сути, скроете(инкапсулируете) дополнительный функционал)
Во-вторых, вы можете не создавать getter'ы для приватных полей, а явно передавать их делегату. Либо вы можете объявить getter'ы package protected и не бояться что-то кто может воспользоваться ими извне

Comments

[Damaskus]

Да, про private я напутал.

Answer 8

[relgames]

Путей несколько.

Можно добавить интерфейс Flaggable и реализовать его в каждом классе через общий делегат (ваш метод 2)

Можно сделать класс FlagWrapper, который будет принимать на вход объект типа Base — тогда вообще не надо менять существующие классы, а сделать завязку на FlagWrapper