Comments 21
Отлично, спасибо. А что на счет отношения Bind (связывание шаблонного, generic в Java, класса с формальным параметром типа)? И далее комбинаций: ассоциация + связывание, зависимость + связывание и т.д.
Например вот для такого кода:
Например вот для такого кода:
class Foo {
public Bar<Baz> field;
}
class Bar<T> { /* ... */ }
class Baz { /* ... */ }
как должна выглядеть диаграмма?0
Обощения и шаблоны не показывают на диаграммах. В лючшем случае так:
Взято отсюда plantuml.sourceforge.net/classes.html
Взято отсюда plantuml.sourceforge.net/classes.html
0
Хоть какая польза от учебы в университете — по названию топика сразу все вспомнил.
Bind как и еще 4-5 разных связей можно отображать непосредственно подписью над отношением (но как правило не нужно :) ). По крайней мере VP это делает за Вас, все же зависит от конкретной нотации.
Bind как и еще 4-5 разных связей можно отображать непосредственно подписью над отношением (но как правило не нужно :) ). По крайней мере VP это делает за Вас, все же зависит от конкретной нотации.
0
Гладко было на бумаге, да забыли про овраги…
+1
Сейчас изучаю паттерны проектирования. Соответственно там рассматривается ООП. Книга полна таких вот диаграмм. Так что топик прямо в тему!
Но возник такой вопрос: в ООП встречается такое понятие как «интерфейс». Википедия дала слишком абстрактный ответ на вопрос «что это». Глубоко пока не гуглил. Может кто-то тут на пальцах объяснит что подразумевается под понятием «интерфейс» в ООП. А лучше приведет пример! Буду очень признателен!
Но возник такой вопрос: в ООП встречается такое понятие как «интерфейс». Википедия дала слишком абстрактный ответ на вопрос «что это». Глубоко пока не гуглил. Может кто-то тут на пальцах объяснит что подразумевается под понятием «интерфейс» в ООП. А лучше приведет пример! Буду очень признателен!
0
Но возник такой вопрос: в ООП встречается такое понятие как «интерфейс». Википедия дала слишком абстрактный ответ на вопрос «что это». Глубоко пока не гуглил. Может кто-то тут на пальцах объяснит что подразумевается под понятием «интерфейс» в ООП. А лучше приведет пример! Буду очень признателен!
Интерфейс — это абсолютно абстрактный класс, который не содержит реализаций методов, а только их объявления.
Классы могут реализовывать один или более интерфейсов.
0
Это плохое определение, показывающее технические особенности реализации, а не суть объекта.
Концептуально, интерфейс — это контракт.
А технически, да, чисто абстрактный класс. Впрочем, даже в яве это не совсем так — бывают интерфейсы вообще без объявлений методов (напр. Serializable), но контракт таки объявляющий.
Концептуально, интерфейс — это контракт.
А технически, да, чисто абстрактный класс. Впрочем, даже в яве это не совсем так — бывают интерфейсы вообще без объявлений методов (напр. Serializable), но контракт таки объявляющий.
0
Да, но только с оговоркой, что конкретно в java интерфейс не позволяет описать контрак. Контрак подразумевает некую семантику, что нельзя задать в чисто абстрактном классе.
0
Интерфейс — это артефакт, описывающий способ взаимодействия двух частей системы. Интерфейсы в java позволяют только описывать сигнатуры методов (то есть по сути является полностью абстрактым классом, не более того), таким образом недостающую часть конракта нужно описывать в javadoc интерфеса.
0
напомнило диплом и бессонные ночи в Enterprise Architect)
0
Почему у вас классы имеют static?
0
Постер на стену www.claudiodesio.com/ooa&d/UMLPoster/UMLPoster.jpg
0
Получается, что вы называете имена отношений, только в одностороннем направлении.
То есть, про агригацию:
если смотреть на отношение от Департамента к Работнику, то связь — агрегация
если смотреть на отношения от Работника к Департаментуто, связь бинарная ассоциация
Верно?
И почему агрегация, а не ассоциация в отношениях между Департаментом и Работником?
В чем разница между:
Департамент агрегирует Работников (агрегация)
и
Каждый Департамент содержит ноль или несоклько работников (N-рная ассоциация)?
Спасибо.
То есть, про агригацию:
если смотреть на отношение от Департамента к Работнику, то связь — агрегация
если смотреть на отношения от Работника к Департаментуто, связь бинарная ассоциация
Верно?
И почему агрегация, а не ассоциация в отношениях между Департаментом и Работником?
В чем разница между:
Департамент агрегирует Работников (агрегация)
и
Каждый Департамент содержит ноль или несоклько работников (N-рная ассоциация)?
Спасибо.
0
Думаю, что ответ слегка позноват :)
Стрелочки в диаграмме зависят от точки зрения автора в момент составления. По ним можно проследить порядок возникновения сущностей и связей.
Так же этим можно пользоваться чтобы специально расставить акценты и сконцентрировать внимание зрителей вокруг тех или иных объектов, которые с точки зрения автора являются ключевыми.
Но да, во многих ситуациях техническая реализация не будет отличаться.
Стрелочки в диаграмме зависят от точки зрения автора в момент составления. По ним можно проследить порядок возникновения сущностей и связей.
Так же этим можно пользоваться чтобы специально расставить акценты и сконцентрировать внимание зрителей вокруг тех или иных объектов, которые с точки зрения автора являются ключевыми.
Но да, во многих ситуациях техническая реализация не будет отличаться.
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.
А у сотрудника Employee должны быть свойства currentPosition и pastPositions[]. Сливать текущую и прошлые позиции в один массив я бы не стал, это все же разные сущности. Хранить текущую позицию в positions[0] — это совсем не clear.
0
Статья неплохая, освежила память, хоть и смахивает на реферат. Неплохой реферат )
Есть один тонкий момент, который мог бы сделать из просто неплохой статьи по-настоящему ценную. В агрегации приводится метод addEmployee класса Department. И в этом методе производятся сразу два действия: 1) добавление работника в массив работников отдела и 2) указание отдела в объекте работника.
Если следовать данной логике, то как минимум в методе removeEmployee надо не забыть почистить отдел у сотрудника, а не просто удалить сотрудника из массива.
А как максимум — нужно ли нагружать класс Department дополнительной ответственностью? Не просто добавлять сотрудника в свой массив, но и сообщать сотруднику о себе?
А может наоборот, в методе setDepartment класса Employee надо вызывать department.addEmployee(this)?
А может вообще сделать некий промежуточный класс «отдел кадров», который будет выполнять оба действия: сообщать сотруднику его отдел и сообщать отделу о новом сотруднике?
На мой взгляд, вывод в статье должен быть в том, что переход от UML к коду — это может быть и не так сложно, но вот прийти к самому UML — это дело другого уровня. Это задача проектирования предметной области. На эту тему можно начать с чтения Эрика Эванса.
Есть один тонкий момент, который мог бы сделать из просто неплохой статьи по-настоящему ценную. В агрегации приводится метод addEmployee класса Department. И в этом методе производятся сразу два действия: 1) добавление работника в массив работников отдела и 2) указание отдела в объекте работника.
Если следовать данной логике, то как минимум в методе removeEmployee надо не забыть почистить отдел у сотрудника, а не просто удалить сотрудника из массива.
А как максимум — нужно ли нагружать класс Department дополнительной ответственностью? Не просто добавлять сотрудника в свой массив, но и сообщать сотруднику о себе?
А может наоборот, в методе setDepartment класса Employee надо вызывать department.addEmployee(this)?
А может вообще сделать некий промежуточный класс «отдел кадров», который будет выполнять оба действия: сообщать сотруднику его отдел и сообщать отделу о новом сотруднике?
На мой взгляд, вывод в статье должен быть в том, что переход от UML к коду — это может быть и не так сложно, но вот прийти к самому UML — это дело другого уровня. Это задача проектирования предметной области. На эту тему можно начать с чтения Эрика Эванса.
0
Sign up to leave a comment.
Отношения классов — от UML к коду