То что обьект может принадлежать к нескольким классам сразу - это могучая дурь, поскольку точный, актуальный тип обьекта задается его конструктором.
на данном этапе возможностей ООЯ, наверное, это действительно так, но почему же "могучая дурь"? Множественная классификация и множественное наследование в реальном мире встречается довольно часто, другое дело, что современный ООЯ просто не позволяет просто воспользоваться этим. Возможно пока в этом и нет потребности и есть гораздо более простые средства выразить это в программе.
Никто не мешает насиловать ооп концепцию и изменять ее до неузнаваемости. Ну например создать такую систему в которой тип обьекта может меняться. Вопрос только - какую концептуальную задачу мы этим решим и к чему такие фичи в вашем подходе.
а параметризированные классы не укладываются в то, что Вы описали?
Из своего опыта могу сказать, что мне приходилось использовать розу для реализации сложных систем из сотен классов на С++, но разумеется безо всяких там отношений ассоциации, и проч. аналитической муры,
Т.е. Вы считаете ассоциации - простой аналитической дурью?
А что вы понимаете здесь под "розой"
роза при генерации кода помогала с помошью параметров генерации создавать автоматически некий код(что было лень писать ручками), автоматически делать нужные инклуды, оформлять заголовки файлов и так далее.
Т.е. единственная причина использовать автогенерацию - это лень?
Очень сомнительно, что применяя ассоциации, агрегирования и проч, можно проделать такую же работу за приемлемое время. диаграммы точно станут нечитаемыми в силу могучего изобилия стрелок, линий и проч.
Трудно не согласиться, но не стоит ли все-таки различать аналитическую работу и собственно реализацию. Или Вы полагаете, что аналитика - суть пиар и ничего более?
Фактически использовались мной лишь отношения наследования и зависимости. А также средства разбрасывания класов по пакетам - файлам .сpp и .h в терминах с++.
Но Вы использовали это не потому ли, что это было полезно и сокращало время и позволяла не потеряться в массе информации?
Но! Всерьез ассоциациями и проч. архианалитикой ничего не опишешь. Если у вас классов 500, в каждом технически методов по 10, и собственных полей в среднем штуки 4 - вы в стрелочках просто запутаетесь.
Может быть все дело в точке зрения? Что такое эти 500 классов - откуда они появились? Это классы предметной области? Или уже объекты программной реализации? Все ли 500 классов вам нужны для анализа одновременно? Не разбиваются ли эти 500 классов на смысловые группы, которые и следует рассматривать отдельно? Разве проектировщики баз данных отказываются от представления связей только из-за того, что их слишком много? Повторяюсь не следует ли всегда при решени задачи держать в голове: (1) точку зрения, (2) контекст использования, (3) уровень использования ?
обычно при сопровождении большой программной системы или ее разработке, необходимо иметь перед глазами структуру классов, особенно если новый человек вводится в проект. наглядность диаграмм в данном случае много выше чем наглядность исходников программ.
однако в данном случае стоит акцентровать. имелось ввиду, что диаграмма не перенасыщена отношениями аггрегирования и проч. ассоциациями, а атрибуты классов(например) вписаны явным образом(не через отношения, а прямо в тело класса).
опять же вопрос об уровне где и как использовать ассоциации и тем более агрегации.
Понимаете явное указание атрибута типа объект среди атрибутов другого класса по сути есть уже указание на решение, но задача аналитика не указать конкретное решение по реализации, а сказать что нужно реализовать. Ведь Вы не будете спорить, что ассоциацию можно реализовать по-разному? В то время как явное указание атрибута жестко будет определять и способ реализации связи между двумя объектами - через ссылку, массив, коллекцию или создание отдельного класса. Т.е. если на модели Вы укажите просто ссылку на объект, как это принято в C++, а в реальности вам потребуется сделать нечто иное - не приведет ли это к логическому разрыву между реализацией и моделью - как впрочем часто и бывает?