Java
UML Design
Comments 21
0
Отлично, спасибо. А что на счет отношения Bind (связывание шаблонного, generic в Java, класса с формальным параметром типа)? И далее комбинаций: ассоциация + связывание, зависимость + связывание и т.д.
Например вот для такого кода:
class Foo {
    public Bar<Baz> field;
}

class Bar<T> { /* ... */ }

class Baz { /* ... */ }
как должна выглядеть диаграмма?
0
Хоть какая польза от учебы в университете — по названию топика сразу все вспомнил.
Bind как и еще 4-5 разных связей можно отображать непосредственно подписью над отношением (но как правило не нужно :) ). По крайней мере VP это делает за Вас, все же зависит от конкретной нотации.
0
Сейчас изучаю паттерны проектирования. Соответственно там рассматривается ООП. Книга полна таких вот диаграмм. Так что топик прямо в тему!
Но возник такой вопрос: в ООП встречается такое понятие как «интерфейс». Википедия дала слишком абстрактный ответ на вопрос «что это». Глубоко пока не гуглил. Может кто-то тут на пальцах объяснит что подразумевается под понятием «интерфейс» в ООП. А лучше приведет пример! Буду очень признателен!
0
Но возник такой вопрос: в ООП встречается такое понятие как «интерфейс». Википедия дала слишком абстрактный ответ на вопрос «что это». Глубоко пока не гуглил. Может кто-то тут на пальцах объяснит что подразумевается под понятием «интерфейс» в ООП. А лучше приведет пример! Буду очень признателен!


Интерфейс — это абсолютно абстрактный класс, который не содержит реализаций методов, а только их объявления.
Классы могут реализовывать один или более интерфейсов.

0
Это плохое определение, показывающее технические особенности реализации, а не суть объекта.

Концептуально, интерфейс — это контракт.

А технически, да, чисто абстрактный класс. Впрочем, даже в яве это не совсем так — бывают интерфейсы вообще без объявлений методов (напр. Serializable), но контракт таки объявляющий.
0
Да, но только с оговоркой, что конкретно в java интерфейс не позволяет описать контрак. Контрак подразумевает некую семантику, что нельзя задать в чисто абстрактном классе.
0
Интерфейс Serializable как раз и подразумевает некую семантику, отличную от технически чисто абстрактного класса. А так, да, средства описания контрактов с помощью явских интефейсов весьма скудны.
0
Интерфейс — это артефакт, описывающий способ взаимодействия двух частей системы. Интерфейсы в java позволяют только описывать сигнатуры методов (то есть по сути является полностью абстрактым классом, не более того), таким образом недостающую часть конракта нужно описывать в javadoc интерфеса.
0
Получается, что вы называете имена отношений, только в одностороннем направлении.
То есть, про агригацию:
если смотреть на отношение от Департамента к Работнику, то связь — агрегация
если смотреть на отношения от Работника к Департаментуто, связь бинарная ассоциация

Верно?

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

Спасибо.
0
Думаю, что ответ слегка позноват :)
Стрелочки в диаграмме зависят от точки зрения автора в момент составления. По ним можно проследить порядок возникновения сущностей и связей.
Так же этим можно пользоваться чтобы специально расставить акценты и сконцентрировать внимание зрителей вокруг тех или иных объектов, которые с точки зрения автора являются ключевыми.
Но да, во многих ситуациях техническая реализация не будет отличаться.
0
В агрегации описано:
… отдел включает в себя одного или более сотрудников и таким образом их агрегирует. На предприятии могут быть сотрудники, которые не принадлежат ни одному отделу, например, директор предприятия.

В то время как диаграмма показывает, что отдел включает в себя 0 или более сотрудников, в то время как каждый сотрудник обязательно должен относиться к одному из отделов.
Вопрос следующий. Это ошибка в диаграмме (или описании) или я не правильно понимаю вопрос?
Спасибо.
0

Тут явная архитектурная ошибка: PastPosition — это класс, и Employee содержит список этих pastPositions и тут же рядом этот же PastPosition (правильно просто Position) раскрыт в переменные-поля: position (правильно currentPosition) и department.


На мой взгляд логично содержать единый список positions, где positions[0] — это текущая должность, а getCurrentPosition() возвращает из списка понятно что. Будет красивее и яснее, more clear.

0
Соглашусь частично. Действительно, должен быть класс Position, у которого есть свойства name и department.
А у сотрудника Employee должны быть свойства currentPosition и pastPositions[]. Сливать текущую и прошлые позиции в один массив я бы не стал, это все же разные сущности. Хранить текущую позицию в positions[0] — это совсем не clear.
0
Статья неплохая, освежила память, хоть и смахивает на реферат. Неплохой реферат )

Есть один тонкий момент, который мог бы сделать из просто неплохой статьи по-настоящему ценную. В агрегации приводится метод addEmployee класса Department. И в этом методе производятся сразу два действия: 1) добавление работника в массив работников отдела и 2) указание отдела в объекте работника.
Если следовать данной логике, то как минимум в методе removeEmployee надо не забыть почистить отдел у сотрудника, а не просто удалить сотрудника из массива.
А как максимум — нужно ли нагружать класс Department дополнительной ответственностью? Не просто добавлять сотрудника в свой массив, но и сообщать сотруднику о себе?
А может наоборот, в методе setDepartment класса Employee надо вызывать department.addEmployee(this)?
А может вообще сделать некий промежуточный класс «отдел кадров», который будет выполнять оба действия: сообщать сотруднику его отдел и сообщать отделу о новом сотруднике?

На мой взгляд, вывод в статье должен быть в том, что переход от UML к коду — это может быть и не так сложно, но вот прийти к самому UML — это дело другого уровня. Это задача проектирования предметной области. На эту тему можно начать с чтения Эрика Эванса.
Only those users with full accounts are able to leave comments., please.