Специалист по базам данных спрашивает: теория объектно-ориентированного дизайна?
Я долгое время работал над проектированием баз данных, а сейчас работаю и на C#. Для меня объектно-ориентированный подход имеет смысл, но я не чувствую, что у меня есть хорошее основание в глубокой теории объектно-ориентированного проектирования.
В области баз данных существует множество теорий о том, как проектировать структуру базы данных, основным понятием является нормализация. Нормализация напрямую управляет структурой базы данных и в некоторой степени диктует, как упорядочивать сущности в базе данных.
Есть ли какие-либо похожие концепции при проектировании структуры объектно-ориентированной программы?
Я стремлюсь к одному или нескольким основополагающим теоретическим принципам, которые естественным образом направляют разработчика к «правильному» дизайну решения данной проблемы.
Где я могу узнать больше?
Есть ли работа, которую я должен прочитать?
Обновлять:
Спасибо всем за ответы. То, что я читаю, похоже, говорит о том, что не существует «Великой теории объектно-ориентированного проектирования», но есть ряд важных принципов, которые в значительной степени иллюстрируются шаблонами проектирования.
Еще раз спасибо за ответы :)
Ответы 14
Вам следует взглянуть на UML, который представляет собой весь процесс, выполняемый OOD.
Я бы порекомендовал купить книгу (или пару), потому что теория довольно обширна, и большинство людей выбирают методы, наиболее подходящие для данного проекта.
Проверьте результаты это. Учитесь на каждом вопросе.
Начните читать о шаблонах проектирования, скажем, от Мартина Фаулера. :)
Они являются наиболее практичным применением ООП.
Какая книга, шаблон проектирования предприятия?
Книга "Паттерны дизайна" - ваш следующий шаг. http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612
Но вам не обязательно использовать объектно-ориентированный подход ко всему. Не относитесь к этому религиозно. Если более процедурный подход кажется более простым, тогда сделайте это. Люди, плохо знакомые с объектно-ориентированной архитектурой, как правило, откладывают это на время.
Хорошая книга, но не для людей, которые переходят от реляционного дизайна к объектно-ориентированному дизайну - я считаю, что она слишком сосредоточена на активных классах и недостаточно сосредоточена на постоянных объектах.
Мне очень понравился Шаблоны проектирования Head First, доступный очень, и отличный Объектно-ориентированная эвристика дизайна Артура Дж. Рила.
Спасибо за эти рекомендации. У меня есть Head First, и это хорошо. Эвристика дизайна выглядит В самом деле интересно - я добавил ее в свой список желаний! :)
Если вы привыкли создавать нормализованные базы данных, объектно-ориентированный дизайн должен вам подходить. Структуры ваших классов в конечном итоге будут очень похожи на вашу структуру данных, за тем очевидным исключением, что таблицы ассоциаций превращаются в списки, а таблицы поиска превращаются в перечисления в ваших классах.
В целом, я бы сказал, что вам намного лучше прийти к объектно-ориентированному дизайну с опытом работы в реляционных базах данных, чем пойти в другом направлении.
Спасибо. Думаю, это то, о чем говорило мое чутье. :)
+1 - В этом взгляде много достоинств. Нормализованное представление данных довольно близко соответствует объектной модели.
Если вы действительно хотите разобраться с O-O, поиграйте с Болтовня. ST - это объектно-ориентированный язык чистый, и он весьма откровенен. Как только вы преодолеете парадигму, вы научитесь объектно-ориентированному программированию, поскольку без него вы не сможете работать с Smalltalk. Так я впервые изучил объектно-ориентированный подход.
Полагаю, вы имеете в виду объектно-ориентированный подход в мире баз данных.
Объектно-ориентированные базы данных, которые хранят объекты, на самом деле никогда не ловили их, поэтому в настоящее время вы ищете сопоставление объектов с реляционной базой данных. ORM или объектно-реляционное сопоставление - это термин, используемый для описания программного обеспечения, которое выполняет это сопоставление. В идеале это дает вам лучшее из обоих миров, где разработчики могут взаимодействовать с объектами, а в базе данных все хранится в реляционных таблицах, где может иметь место стандартная настройка.
Перейти к объектному мышлению Дэвида Уэста. Интересное чтение ..
Хотя вы с темной стороны ... согласно книге;) Мышление о базах данных было проклятием всех объектно-ориентированных программистов. Это противоположные концы спектра. Например
- При мышлении базы данных атрибуты данных важнее всего остального. Нормализация и создание типов на основе того, как они вписываются в схему БД ИЛИ диаграмму ER. Объектно-ориентированное мышление создает типы, основанные на поведении и сотрудничестве, и не признает атрибуты данных как все важные.
- Базы данных исходят от ученых, для которых формализация и метод важнее всего. ОО исходит от людей, которые используют эвристику и эмпирические правила и ценят индивидуальность и социальное взаимодействие как жесткий и быстрый процесс.
Дело в том, что программист на COBOL может писать программы на COBOL даже после перехода на объектно-ориентированный язык. Посмотрите любую книгу, например «Мышление на Java», в первом разделе, который неизменно детализирует принципы объектно-ориентированного программирования (подмастерье) ... Следуйте за ним с помощью объектного мышления (подмастерье), а в свое время ... мастера.
Этот сайт содержит 101 заголовок ... шаблоны проектирования, рефакторинг и прочее ... Посмотрите ... Это будет хорошей отправной точкой ...
Я считаю Гибкая разработка программного обеспечения, принципы, шаблоны и практики неплохим.
В нем подробно рассматриваются принципы объектно-ориентированного программирования, перечисленные в здесь:
- Принципы объектно-ориентированного проектирования и управления зависимостями
- SRP - принцип единой ответственности
- OCP - Принцип открытости и закрытости
- LSP - Принцип замещения Лискова
- DIP - Принцип инверсии зависимостей
- Интернет-провайдер - Принцип разделения интерфейсов
- REP - Принцип эквивалентности повторного использования релизов
- CCP - Общий принцип закрытия
- CRP - Общий принцип повторного использования
- ADP - Принцип ациклических зависимостей
- SDP - Принцип стабильных зависимостей
- SAP - Принцип стабильных абстракций
Смоделируйте свои объекты, помня об объектах реального мира.
В настоящее время мы разрабатываем программное обеспечение для автоматизации машин. Одна из этих машин имеет два загрузочных порта для подачи сырья, а все остальные - только одно. До сих пор во всех модулях у нас была информация о портах (текущие настройки, номер партии, назначенный на данный момент и т. д.) В качестве членов класса, представляющего машину.
Мы решили создать новый класс, содержащий информацию о портах, и добавить два члена LoadPort в этот класс MachineXY. Если бы мы думали об этом раньше, мы бы сделали то же самое для всех этих однопортовых машин ...
Будьте осторожны с некоторыми публикациями по шаблонам проектирования.
Есть несколько широких видов определений классов. Классы для постоянных объектов (которые похожи на строки в реляционных таблицах) и коллекций (которые похожи на сами таблицы) - это одно.
Некоторые из шаблонов проектирования «Банда четырех» более применимы к активным объектам приложения и менее применимы к постоянным объектам. Пока вы боретесь с чем-то вроде Абстрактная фабрика, вы упускаете некоторые ключевые моменты объектно-ориентированного проектирования, поскольку он применяется к постоянным объектам.
На странице Object Mentor Что такое объектно-ориентированный дизайн? есть много из того, что вам действительно нужно знать, чтобы перейти от реляционного дизайна к объектно-ориентированному дизайну.
Нормализация, кстати, не является общим принципом проектирования, который всегда применяется к реляционным базам данных. Нормализация применяется, когда у вас есть транзакции обновления, чтобы предотвратить аномалии обновления. Это хитрость, потому что реляционные базы данных - вещь пассивная; вам либо нужно добавить обработку (например, методы в классе), либо передать кучу правил (нормализация). В мире хранилищ данных, где обновления редки (или отсутствуют), стандартные правила нормализации не так актуальны.
Следовательно, для объектных моделей данных не существует «такой нормализации».
В OO Design, возможно, самое важное правило для проектирования постоянных объектов - это Принцип единой ответственности.
Если вы проектируете свои классы так, чтобы они соответствовали объектам реального мира, и вы распределяете обязанности между этими классами очень целенаправленно, вы будете довольны своей объектной моделью. Вы сможете сопоставить его с реляционной базой данных с относительно небольшими сложностями.
Оказывается, когда вы смотрите на вещи с точки зрения ответственности, вы обнаруживаете, что правила 2NF и 3NF подходят для правильного распределения ответственности. Уникальные ключи по-прежнему имеют значение. За производные данные отвечает функция метода, а не постоянный атрибут.
Спасибо. Думаю, вы действительно ответили на вопрос, который никому не удалось решить. :)
Был там - был администратором баз данных, прежде чем стать архитектором объектов - проводил время, обучая других администраторов баз данных. Я чувствую твою боль.
на сленге администраторов баз данных: объектно-ориентированный дизайн - это не что иное, как правильно нормализованные данные за безопасными рабочими интерфейсами, безопасный смысл, смотрите на операции, а не на данные напрямую
см. также programmers.stackexchange.com/questions/84598/…