Дублирующиеся свойства - наследование, интерфейс?

Задача: создать редактор тэгов для SCADA.
Возник вопрос на этапе проработки предметной области.
Тэги (технологические переменные) можно классифицировать:
- по типу значения: дискретные, числовые, строковые;
- по типу доступа: внешние (I/O), внутренние (memory).

Оба эти "атрибута" обязательны для любого тэга.

При наследовании получается дублирование свойств в разных ветвях наследования:



Как этого избежать?

0

Сообщение от NewOrdered наследование, интерфейс?

Если использовать интерфейс, то реализовывать его Вы обязаны в каждом классе,
а если наследуете, то пишите уникальный код только у предка и наследуете поведение,
в общем и целом, если и нужно добавить функционал, то просто дописываете у потомка.
Я за наследование - меньше писать кода (и поддерживать его).

1

Сообщение от NewOrdered При наследовании получается дублирование свойств в разных ветвях наследования:

А) Это нормально и не страшно, если такого дублирования не сильно много;
Б) Может быть на самом деле у вас меньше классов в иерархии, чем вы понапроектировали?

1

Сообщение от Usaga Может быть на самом деле у вас меньше классов в иерархии, чем вы понапроектировали?

Конечных типов у меня все равно получается как минимум 6 (для упрощения понимания на диаграмме изображены только 4).

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

0

NewOrdered,
Можно сделать так.
Выделите группы свойств, которые всегда появляются вместе. Вынесите их в отдельный класс. Например:
Сами же классы тегов сделайте составными:
Это вроде будет паттерн мост.

3

Сообщение от NewOrdered никакой сложной логики в геттерах/сеттерах

А я бы не стал увлекаться написанием логики в геттерах/сеттерах. Потому что это
обычно ведёт к взаимозависимости, весьма вредной, одних свойств от других...

0

ashsvis, так я и не пишу. По задумке эти конечные классы должны быть чем-то вроде DTO.
Но похоже, что придется по совету Storm23 делать модель более сложную, но универсальную.

0

Сообщение от NewOrdered делать модель более сложную, но универсальную.

Да, развлекайтесь, если есть время для этого...

0

0

Storm23, Если CommonTag при любой классификации является вершиной иерархии, есть ли смысл конечным классам просто наследоваться от него?

0

Сообщение от NewOrdered Если CommonTag при любой классификации является вершиной иерархии, есть ли смысл конечным классам просто наследоваться от него?

Думаю, что наследоваться от него нельзя. Это противоречит логике моста.
Допустим у вас в будущем появятся две разные версии CommonTag: CommonTagA и CommonTagB - что вы будете делать с остальной иерархией?
Ваши Теги должны быть просто композицией, и не должны ни от чего наследоваться.

1

В итоге вместо стройной иерархии наследования получилась паутина композиций
Тот случай, когда код выглядит нагляднее

0

Сообщение от NewOrdered В итоге вместо стройной иерархии наследования получилась паутина композиций Тот случай, когда код выглядит нагляднее

У Вас с левой стороны дублируются во всех классах два свойства Common и Memory. Это намерено? При такой структуре, допустим, в классе CommonTag получится три пары таких свойств.

Добавлено через 5 минут
А для уменьшения визуальной путаницы в картинке - переставьте MemoryIntegerTag и AnalogTag наверх.

0

Элд Хасп, Слева - классы, описывающие сущности предметной области, справа - вспомогательные классы, содержащие общие свойства для композиции.

0

Сообщение от NewOrdered В итоге вместо стройной иерархии наследования получилась паутина композиций

Давайте разберемся.

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

Во-вторых. У вас на исходной диаграмме на самом деле столько же зависимостей, если не больше. Да, у вас только одна стрелка до MemoryDiscreteTag. Но неявно он все равно зависит и от своего дедушки Tag и от нерожденного родственника DiscreteTag. Просто на второй диаграмме мы стали честнее и выразили все связи явно.

В-третьих. Вторая диаграмма лучше первой. Каждое свойство предметной области в ней упоминается только один раз.
Поэтому если вы добавите логику, то эта логика будет сидеть только в одном свойстве, а не в нескольких. Кроме того, если вы поменяете какие-то свойства, вам придется менять их только в одном классе. Остальные классы останутся неизменным.
То есть стало меньше поводов для изменения класса. А это хорошо.

Ну и самое главное. Сейчас, что бы создать новый тег, вам просто нужно скомбинировать несколько более простых классов. А в иерархии вам бы пришлось навернуть еще один ярус дерева, с экспоненциальным ростом числа классов.

2

Всем спасибо за участие!

0