Парень из базы данных спрашивает: теория объектно-ориентированного проектирования? - PullRequest
5 голосов
/ 29 октября 2008

Я давно занимался проектированием баз данных, и сейчас я тоже работаю в C #. ОО имеет смысл для меня, но я не чувствую, что у меня есть хорошее основание в глубокой теории ОО-дизайна.

На суше баз данных существует много теорий относительно того, как проектировать структуру базы данных, основным понятием является нормализация. Нормализация напрямую управляет структурой базы данных и в некоторой степени диктует, как организовать объекты в базе данных.

Существуют ли аналогичные концепции в том, как спроектировать структуру объектно-ориентированной программы?

То, чего я достигаю, - это один или несколько основополагающих теоретических принципов, которые естественным образом ведут разработчика в «правильный» дизайн для решения данной проблемы.

Где я могу узнать больше?
Должен ли я идти на работу?

Обновление:

Спасибо всем за ответы. То, что я читаю, похоже, говорит о том, что не существует «Великой теории ОО-дизайна», но есть ряд важных принципов, которые в значительной степени иллюстрируются шаблонами проектирования.

Еще раз спасибо за ваши ответы:)

Ответы [ 14 ]

11 голосов
/ 29 октября 2008

Будьте осторожны с литературой по шаблонам проектирования.

Существует несколько широких видов определений классов. Классы для постоянных объектов (которые похожи на строки в реляционных таблицах) и коллекции (которые похожи на сами таблицы) - это одно.

Некоторые из шаблонов проектирования " Gang of Four " более применимы к активным объектам и менее применимы к постоянным объектам. В то время как вы боретесь с чем-то вроде Abstract Factory , вам не хватит некоторых ключевых моментов дизайна ОО, так как это относится к постоянным объектам.

Наставник объектов Что такое объектно-ориентированное проектирование? * На странице 1012 * многое из того, что вам действительно нужно знать для перехода от реляционного проектирования к ОО-дизайну.

Нормализация, кстати, не является общим принципом проектирования, который всегда применим к реляционным базам данных. Нормализация применяется, когда у вас есть транзакции обновления, чтобы предотвратить аномалии обновления. Это хак, потому что реляционные базы данных - это пассивные вещи; Вы должны либо добавить обработку (например, методы в классе), либо пройти ряд правил (нормализация). В мире хранилищ данных, где обновления редки (или отсутствуют), стандартные правила нормализации не так актуальны.

Следовательно, для моделей данных объекта «нормализовать это не существует».

В OO Design, пожалуй, наиболее важным правилом для разработки постоянных объектов является Принцип единой ответственности .

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

Оказывается, что когда вы смотрите на вещи с точки зрения ответственности, вы обнаруживаете, что правила 2NF и 3NF соответствуют разумному распределению ответственности. Уникальные ключи все еще имеют значение. И производные данные становятся обязанностью функции метода, а не постоянным атрибутом.

6 голосов
/ 29 октября 2008

Книга «Шаблоны проектирования» - ваш следующий шаг.
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612

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

4 голосов
/ 29 октября 2008

Я думаю Agile Software Development, принципы, шаблоны и практики довольно хорошо.

В нем подробно изложены принципы ОО, перечисленные здесь :

  • Принципы объектно-ориентированного проектирования и управления зависимостями
  • SRP - Принцип единой ответственности
  • OCP - Открытый Закрытый Принцип
  • LSP - Принцип замещения Лискова
  • DIP - принцип обращения зависимостей
  • Интернет-провайдер - принцип разделения интерфейса
  • REP - Принцип эквивалентности повторного использования
  • CCP - Общий принцип закрытия
  • CRP - принцип общего повторного использования
  • ADP - Принцип ациклических зависимостей
  • SDP - Принцип стабильных зависимостей
  • SAP - Принцип стабильных абстракций
2 голосов
/ 29 октября 2008

Если вы действительно хотите овладеть O-O, играйте с Smalltalk . ST является чистым ОО языком, и вполне в этом разбирается. Как только вы преодолеете горб парадигмы, вы выучите ОО, поскольку вы не сможете сделать Smalltalk без него. Так я впервые узнал ОО.

2 голосов
/ 29 октября 2008

Если вы привыкли строить нормализованные базы данных, тогда объектно-ориентированное проектирование должно быть вам естественным. Ваши структуры классов в конечном итоге будут очень похожи на вашу структуру данных, с очевидным исключением, что таблицы ассоциаций превращаются в списки, а таблицы поиска превращаются в перечисления внутри ваших классов.

В целом, я бы сказал, что вам гораздо лучше заняться проектированием ОО с опытом работы в реляционных базах данных, чем идти в другом направлении.

1 голос
/ 29 октября 2008

Моделируйте свои объекты, помня о реальных объектах.

В настоящее время мы разрабатываем программное обеспечение для автоматизации машин. Одна из этих машин имеет два загрузочных порта для подачи сырья, в то время как все остальные имеют только один. До сих пор во всех модулях у нас была информация о портах (текущие настройки, номер партии, назначенные на данный момент и т. Д.) В качестве членов класса, представляющего машину.

Мы решили создать новый класс, который содержит информацию о портах, и добавить два члена LoadPort к этому классу MachineXY. Если бы мы думали об этом раньше, мы бы сделали то же самое для всех этих однопортовых машин ...

1 голос
/ 29 октября 2008

На этом сайте перечислены 101 заголовок ... шаблоны проектирования, рефакторинг и другие ... Посмотрите на это .. Это будет хорошей отправной точкой ...

1 голос
/ 29 октября 2008

Давай за объектное мышление Дэвида Уэста. Интересное чтиво ..
Вы с темной стороны, хотя ... согласно книге;) Мышление базы данных было проклятием OO-программистов во всем. Они противоположные концы спектра. Например

  • Мышление в базе данных оценивает атрибуцию данных над всем остальным. Нормализация и создание типов на основе того, как они вписываются в схему БД ИЛИ диаграмму ER. Мышление ОО создает типы, основанные на поведении и сотрудничестве, и не распознает атрибуты данных как все важно.
  • Базы данных поступают от научных людей, которые ценят формализацию и метод перед всем остальным. OO происходит от людей, которые используют эвристику и эмпирические правила и ценят индивидуальность и социальное взаимодействие в сложном и быстром процессе.

Суть в том, что программист на языке COBOL может писать программы на языке COBOL даже после перехода на язык OO. Изучите любую книгу, такую ​​как «Мышление на Java», в первом разделе, в котором неизменно подробно описываются принципы ОО (ученика). В дальнейшем вы можете ознакомиться с предметным мышлением (подмастерье) и в свое время… с мастером.

1 голос
/ 29 октября 2008

Мне очень понравились Шаблоны проектирования Head First , которые очень доступны, и превосходные Объектно-ориентированные эвристики дизайна Артура Дж. Риеля

1 голос
/ 29 октября 2008

Проверьте результаты this . Учитесь на каждом вопросе.

...