Как правильно составить диаграмму классов?

Question

[Григорий Васильков]

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

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

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

Вот он описывает ситуацию - электрическая цепь: есть одна микросхема, есть другая микросхема, у них есть ножки значит, ножка одной соединяется с ножкой другой, образуя почему-то шину (полагаю под шиной радиотехники понимают несколько цепей, не могу точно сказать), итого он чертит модель:

Левый элемент - Ножка - Шина - Ножка - Правый элемент
Да короче вот: https://www.screencast.com/t/oLlvyP36mJ

Центральная часть ножка-шина-ножка повторяется на картинке несколько раз. После этого начинает составлять диаграмму классов:

Абстрактный класс Абстрактная Цепь содержит свойство "Правила"
Класс Цепь наследуется от АбстрактнойЦепи содержит свойство Шина
и по итогу получается вот такая схема
https://www.screencast.com/t/1iJgtfqTdv2

Как он понял, что оно должно выглядеть так. Он просто "есть дом", давайте нарисуем проект "итак, если спальня, то - проект готов, иначе - проект без спальни готов". Почему - не понятно, как получилось - не понятно, зафиг ему абстрактный класс, если сам класс и есть абстракция от объекта?

Как он понял, что метод Правило должен быть в абстрактном, а просто классе - метод шина? Почему оба не в абстрактном, или не оба в просто классе?

Правда говоря он пишет то ли на Java то ли на C, но суть понятий то?

Answer 1

[Сергей]

Вообще, это правильный подход к диаграммам. )
Вот что писал Боб Мартин:
"Возьмите за правило выбрасывать ненужные UML-диаграммы. А еще
лучше, не создавайте их на постоянном носителе. Рисуйте на доске или
на клочках бумаги. Почаще стирайте с доски и выбрасывайте эти об-
рывки. Не привыкайте к инструментарию CASE или к графическим ре-
дакторам. Для таких инструментов есть свое время и место, но жизнь
большинства UML-диаграмм недолговечна."
Хотя, далее, некоторые полезно и сохранять. Общий дизайн системы (идея) или те моменты которые из текста программы будет сложно понять.

Упрощенно можно так подходить к выделению классов и интерфейсов.
Есть два реальных объекта. Они относятся к разным классам. Со своими особенностями. Но у них есть некие одинаковые свойства. Например шаблоны функций. пример в общем случае быстрая сортировка это шаблон реализующий алгоритм, но этот шаблон не знает как реально сравнивать объекты. То есть это абстрактный класс объединяющий конкретные быстрые сортировки конкретных объектов. Можно сказать, что абстрактный класс это вынос общих методов и полей их своих потомков. При том что реально мы никогда не создадим экземпляр этого класса.
Выделение интерфейса. Обычно применяется для разделения систем на отдельные на зависимые части. Например кнопка включает лампу. В программе это реализуется так
кнопка имеет поле лампа. т.е. реализация кнопки зависит от лампы. Если тип (или код) лампы поменялся, то и часть кода ответственная за кнопку тоже меняется. По крайней мере должна протестироваться. Но можно договориться разделить все устройства которые могут что-то включать (кнопки) и могут быть включены (лампы, двигатели, телевизоры...) и указать как им взаимодействовать.
Т.е. примерно так:
Кнопка управляет устройствами.
Устройство должно иметь метод "включить".
Лампы, телевизоры, двигатели должны реализовать это метод у себя.
Итого одна и та же кнопка (без изменения кода) управляет целой группой разнородный устройств (но реализующих общие правила взаимодействия)

По картинкам:
у нас есть объекты
связь 0, связь 1, ...связь 3
так же объект шина из связей.
общее для них это они все имеют имя.
также они имеют некоторые правила передачи сигналов.
Это дает нам два класса Net и Bus. Кроме того Bus включает в себя много Net.
Далее хотелось бы , что бы эти классы были независимы от правил. т.е что бы правила мы могли назначать сами. возможно динамически. Поэтому net и bus имеют метод назначающий правила rule (с общим интерфейсом) (которые можно менять, и не менять реализацию net, bus ).
Итого Выделили общие свойства из net, bus в абстрактный класс AbstractNet. bus включает много net. Вынесли правила (которые будут часто меняться и которые мы возможно еще не знаем) за общий интерфейс.
примерно так. упрощенно.

Comments

[Григорий Васильков]

Про интерфейсы понял, еще дополнительно посмотрел в Ютубе ролик Науменко (DI/Allocator в Yii2) - он как раз приводит отличный пример интерфейсов, что это можно воспринимать как тип данных при написании "без этого программа не запустится".

Абстрактные классы я в основном путаю со статическими свойствами этих классов. В чем принципиальная разница в стиле "вот этого в статике не сделать, поэтому придумали абстрактные классы"? Правильно ли я понимаю, что это только возможность работать в методе со своим обьектом через this, а в статике - это скорее про работу с некими передаваемыми данными в отвязке от контекста?

[Григорий Васильков]

О, пример есть.
Абстрактный класс это примерно как класс Продукт, зная что у нас есть например Холодильники и Телевизоры, который имеет свойства присущие и тем и другим, но сам по себе существовать не может? Ну то есть мы же не можем продать клиенту коробку с надписью продукт, в конечном итоге это будет то что он хотел там холодильник/телевизор?

[Сергей]

Григорий Васильков:
Я бы разделил так.
моделируем потребление электричества
Счетчик суммирует мощности девайсев.
Девайс это интерфейс который понимает счетчик. Имеет метод Мощность()
Все устройства реализуют этот интерфейс.
Холодильник
имеет состояния включен/выключен
и настройку температуры
метод Мощность примерно такой
{
если выключен, то 0
иначе Мощность работы
}
метод МощностьРаботы
{
сложный расчет зависимости от температуры
}

Телевизор
состояние включен/выключен
состояние ждущий/активный режим
Мощность - такой же метод как у холодильника
МощностьРаботы
{
сложный расчет зависимости от ждущего или активного режима
}

Получается дублирование кода в части включен/выключен.
Мы его выносим в абстрактный класс
ВключаемыеУстройства{
состояния включено/выключено
метод Мощность примерно такой
{
если выключен, то 0
иначе Мощность работы
}
метод МощностьРаботы - указываем что не реализован
}
телевизор и холодилник наследники и реализуют метод Мощность работы.

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

Продукт Продаем
Абстрактное Устройство играет роль продукта
имеет абстрактный метод Проверить
и обычный Упаковать
реализует метод Продать ( Проверить + Упаковать )

Телевизор играет роль Устройства
реализует Проверить( включить и посмотреть программу)
Холодильник играет роль Устройства
реализует Проверить (включить и потрогать морозилку)

[Григорий Васильков]

Гений... так просто рассказывает, что медаль бы вам. Приезжайте в Брест, будем рады, только напишите перед этим

[Сергей]

Привет с другой окраины Беларуси ))) Могилевская обл.

[Григорий Васильков]

Страна вечнобогатых программистов, которые судя по онлайнеру получают 5 косарей, а на деле решают вопросы за 300 баксов)