Все доброго утра\дня\вечера\ночи!
Не уверен что пишу в правильной ветке....
Появился такой вопрос. Есть ли в ООП (думаю что есть, но быстрый поиск в гугле и на сайте ничего не дал) принципы (а точнее правила, инструкции или что либо еще) выделения сущностный\классов. Т. е. нужно нам допустим написать программу, анализируем, выделяем сущности (как в БД), создаем классы (пишем внутренности) и все...
Как то все это пока делается интуитивно. Может кто подскажет как это делать более менее по правилам?

ничего не понял :(

Почитайте про диаграммы классов в нотации UML.

Т.е. делаете диаграмму классов, из нее генерируете код в ЯП, там разрабатываете внутренности.

Не, UML я знаю... я говорю не о способе представления классов и их методов в виде прямоугольничков связанных. А о логике выделения этих прямоугольничков (читай классов)...
Т. е. как мы делаем в БД. Допустим нам нужно БД для вокзала(продажа билетов), мы сидим и как то интуитивно или по правилам выделяем сущности. Например (пассажир, билет, место, номер поезда и т. д.). Этим сущностям потом в соответствие создадим таблицы, связанные между собой... И у нас будет БД.
Так вот, эти самые сущности, мы выделяем по какой то логике, по каким то принципам, может быть правилам. В ООП классы мы тоже как то выделяем. Ну и собственно вопрос: есть ли какие нибудь правила которые позволят выделять классы наиболее правильно? Ведь можно в большом проекте вместо 30 нужных классов (для более гибкой и удобной разработки и поддержки) выделить 5 и написать ###код, где одно с другим вяжется через ж...

Нету правил пока. Можно почитать у Гради Буча. Но все книжки пока только рекомендуют. Никаких правил не выработали - это чисто творческая часть проекта. И только от опыта зависит, удачно получится или нет. 
Есть книжка Кента Бека "Разработка через тестирование" - там ход мыслей Бека расписан. Тоже на эту же тему - очень интересно почитать.  

Да, это плохо, так как по правилам опыт набирается куда быстрее чем интуитивно. ИМХО. А что значит "пока", просто к слову или Вы уверены в том, что когда то это направление перейдет из области творчества в область следования правилам?


Нужно на днях поискать и гляну! Я так понимаю У Гради Буча какие то общие рекомендации по проектированию(наверное вот в этой книге: Объектно-ориентированный анализ и проектирование)?


Это когда сначала пишут тесты для программы а потом саму программу удовлетворяющую этим тестам?   На самом деле довольно интересно, давно хотел ознакомиться с этой концепцией.
Спасибо за рекомендации.
Но вопрос не закрывается. Предлагаю людям делиться кое-какими мыслями на этот счет, в этой теме. Понимаю конечно что процесс выделения сущностей сформулировать трудно, но все таки, может у кого то есть какие нибудь профессиональные взгляды\методы\мысли\уловки\фичи на этот счет.   

Хотел бы еще услышать мнение, очень уважаемого мной, отличного аналитика и здешнего модератора Се ля ви!   

Это сообщение отредактировал(а) Joil - 25.8.2010, 12:41

Joil, я думаю что тебе нужно смотреть с сторону Domain-Driven Design. pdf

В ООП нет, а в ООА (анализ) есть.
Т.к. анализ проводится перед проектированием, то вы пользуетесь его результатами в дальнейшем.

В основном эти правила формулируются настолько абстрактным языком, что проще объяснить на примере.
Одна и та же сущность может быть как классом, так и атрибутом или состоянием - в зависимости от решаемой задачи. А от этого зависит, как проектировать модель, и БД в том числе.

Если вы автоматизируете пассажирские перевозки для вашего вокзала, это будет одна схема, если управление подвижным составом - другая, если контроль персонала - третья.


Слава здесь далеко не единственный отличный аналитик   
Да и появляется редко в последнее время.

Это сообщение отредактировал(а) ida - 27.8.2010, 11:53

powerOn, спасибо, взгляну! Даже не слышал об этом, хотя может и слышал но не знал что это оно   


За это спасибо, тоже буду изучать...
Ох... жалко что времени в сутках так мало... да и вообще его мало...


Хех... я такого и не говорил   

Как это нет??? По крайней мере 3 метода есть.(читайте Буча, Рамбо внимательнее).
1. Метод "Существительное - глагол"
2. Метод "Карт обязанностей"
3. Метод "OOA RUP". Собственно в этом методе, акцентируется внимание на три класса объектов;
Boundary classes, Control classes, entity classes  

Во-во.

1. Лексический анализ. Подлежащее- сущность/аттрибут и сказуемое - связь/метод
2. Исследование рабочих моделей того-же business domain
3. Ещё чего-то, чего на вскидку не помню, но технология вполне топтаная 

Гради Буч не очень(в плане книги). Он такой философ от программирования, постоянно цитирует Страуструпа и прочих. Много воды. Океан.
В его книжке интересна вторая часть(примерно четверть от целого), где он разбирает примеры. Тут тебе и анализ требований и создание дизайна(с диаграммами и блекджеком) и что-то от реализации. Это нужно. Смело можно читать только вторую часть. И лучше на английском, помнится разница была между изданиями.

Смотрю в сторону Кента Бека.
//Оффтоп
Никто не подскажет, где лучше покупать книжки на английском? Или может тему на форуме, не могу конкретных советов найти.

Не уверен, что в ООП есть такие принципы/правила. Но мой опыт проектирования показывает, что в основу класса всегда нужно класть какие-то обязанности (функции). Не должно быть бесполезных классов, классов, которые ничего не делают и ни за что не отвечают.

Если Вам интересен какой-либо практический пример, то можете посмотреть статьи на эту тему у меня в блоге:

Проектирование классов для графического редактора
Задача про датчики: Проектирование классов. Часть 1.
Задача про датчики: проектирование классов. Часть 2.

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