Диаграмма классов Swing и UML при наличии нескольких экранов с одинаковыми компонентами

Я застрял на этом в течение нескольких часов. Я должен сделать диаграмму классов UML для приложения Swing в проекте колледжа. Я представил себе один главный экран, из которого я могу открыть один из нескольких экранов в зависимости от выбранного варианта. Все эти экраны имеют несколько одинаковых компонентов (например, логотип приложения, кнопку выхода и т. д.).

Теперь я прочитал, что не рекомендуется наследовать JFrame, поэтому я избегал помещать их в класс, который наследует JFrame, который снова наследуется этими другими классами, но почему-то также не кажется нормальным не иметь наследования и вместо этого перечислять эти компоненты как атрибуты в каждом классе.

Итак, как правильно это сделать?


swing uml class-diagram
person K.Z.    schedule 25.06.2017    source источник
comment
Откуда вы узнали об этом ограничении наследования?   -  person qwerty_so    schedule 25.06.2017
comment
Хм, по всему интернету, включая переполнение стека. Просто чтобы назвать несколько stackoverflow.com/questions/1143923/ thebadprogrammer.com /2012/08/   -  person K.Z.    schedule 25.06.2017
comment
А последний абзац этой самой статьи?   -  person qwerty_so    schedule 25.06.2017
comment
Так что я должен использовать наследование? Я прочитал этот абзац, и это звучит как то, что мне нужно, но затем я читал во многих других местах, что композиция всегда лучше, поэтому я сильно запутался во всем этом и решил спросить здесь.   -  person K.Z.    schedule 25.06.2017
comment
Как правило, нет черного и белого. Следуйте своим инстинктам. Иногда это вопрос стиля, но плохой стиль не означает, что он неправильный. Стиль также меняется со временем.   -  person qwerty_so    schedule 25.06.2017
comment
Нечасто мне нравятся посты Киллиана, но сейчас я полностью согласен. Моделируйте в соответствии с логикой, в соответствии с принципами SOLID, но не в соответствии с модой.   -  person Gangnus    schedule 26.06.2017
comment
Спасибо вам обоим за ваши ответы   -  person K.Z.    schedule 26.06.2017

Ответы (1)


arrow_upward
0
arrow_downward

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

Любой вид подэлемента экрана, очевидно, другого класса. Опять же, его экземпляр с датой является экземпляром.

Класс экрана имеет подэлементы разных классов. Они действительно ЯВЛЯЮТСЯ атрибутами, и изменение естественной логики было бы очень неудачной идеей.

Если экраны имеют одинаковые элементы и отличаются только своим содержанием, и этот факт является концептуальным, если они ДОЛЖНЫ быть одинаковыми, эти экраны принадлежат к одному и тому же классу. Если они так похожи лишь случайно, а дальнейшее развитие может изменить это, то они должны принадлежать к разным классам.

Наследование также может быть удобно использовано. Если у вас есть желтые кнопки и желтые кнопки с точками, последние могут быть потомками первых. Здесь принцип Лискова не будет нарушен. Не забывайте, что базовые принципы установлены в SOLID, есть НЕ такой принцип, как не использовать наследование, и вам не нужно использовать композицию из чистой моды.

person Gangnus    schedule 26.06.2017