Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Системный анализ, проектирование и UML > ООП

Автор: Joil 24.8.2010, 14:48

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

Автор: levkunchik 24.8.2010, 15:28

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

Автор: neic 24.8.2010, 16:13

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

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

Автор: Joil 24.8.2010, 17:34

Цитата(neic @ 24.8.2010, 16:13

)

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

Автор: ValeryLaptev 25.8.2010, 10:35

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

Автор: Joil 25.8.2010, 12:35

Цитата(ValeryLaptev @ 25.8.2010, 10:35

)

Нету правил пока.

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

Цитата(ValeryLaptev @ 25.8.2010, 10:35

)

Можно почитать у Гради Буча. Но все книжки пока только рекомендуют.

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

Цитата(ValeryLaptev @ 25.8.2010, 10:35

)

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

Это когда сначала пишут тесты для программы а потом саму программу удовлетворяющую этим тестам? smile

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

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

Автор: powerOn 25.8.2010, 22:16

Joil, я думаю что тебе нужно смотреть с сторону Domain-Driven Design. http://www.evansvillednug.com/LinkClick.aspx?fileticket=4LwCx2tkyBA%3D&tabid=76&mid=399

Автор: ida 27.8.2010, 11:49

Цитата(Joil @ 24.8.2010, 15:48)

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

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

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

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

Цитата(Joil @ 25.8.2010, 13:35)

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

Слава здесь далеко не единственный отличный аналитик smile

Да и появляется редко в последнее время.

Автор: Joil 27.8.2010, 12:28

Цитата(powerOn @ 25.8.2010, 22:16

)

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

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

Цитата(ida @ 27.8.2010, 11:49

)

В ООП нет, а в ООА (анализ) есть.

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

Цитата(ida @ 27.8.2010, 11:49

)

Слава здесь далеко не единственный отличный аналитик smile

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

Автор: cat512 29.8.2010, 19:04

Цитата(ValeryLaptev @ 25.8.2010, 10:35)

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

Автор: Ake1a 22.9.2010, 01:57

Во-во.

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

Автор: YankovskyAndrey 27.8.2011, 04:10

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

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

Автор: Askofen 6.11.2011, 16:54

Цитата(Joil @ 24.8.2010, 14:48

)

Есть ли в ООП (думаю что есть, но быстрый поиск в гугле и на сайте ничего не дал) принципы (а точнее правила, инструкции или что либо еще) выделения сущностный\классов.

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

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

http://askofen.blogspot.com/2010/11/blog-post_19.html
http://askofen.blogspot.com/2011/10/1.html
http://askofen.blogspot.com/2011/10/2.html

Автор: RockClimber 8.11.2011, 18:01

Цитата(Askofen @ 6.11.2011, 16:54

)

Не уверен, что в ООП есть такие принципы/правила.

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