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