ER к ОО стратегии дизайна?

Question

Я все еще изучаю все возможности дизайна ОО и имею гораздо больше опыта в проектировании баз данных (в частности, E-R). Каждый раз, когда я подхожу к проблеме и пытаюсь придумать дизайн, следуя ОО-стратегиям, мои диаграммы (например, классы UML) выглядят как ERD. Я читал / слышал, что тогда умно сопоставлять класс с каждой таблицей и работать оттуда ... Но, кажется, это никуда не приведет, и мои проекты имеют очень высокую (плохую) связь, которая, как я понимаю, большое "нет-нет" в ОО.

Несколько поисков в Google вернули несколько попаданий при переходе от E-R к OO, но ничего такого, что могло бы помочь мне вернуться домой. У кого-нибудь есть материалы на эту тему, или, возможно, боролись с подобной проблемой?

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

Спасибо за любые советы!

Answer 1

Системы баз данных: практический подход к ... - учебник (главы 3 ~ 4), который я бы порекомендовал.

Я думаю, что фундаментальные различия в данных (реляционной модели данных) и программе являются основным разрывом между дизайном E-R и OO. Вы можете нарисовать схему базы данных в UML, но это не так означают, что модель реальных данных стала бы осмысленным понятием ОО-парадигмы.

Программы, с другой стороны, фокусируются на правильной обработке с дисциплиной повторного использования. Данные, однако, сосредоточены на сохранении правильно с дисциплиной производительности.

Хотя существуют некоторые методы для уменьшения разрыва (например, O-R Mapping), но основные цели для данных / программ не совсем одинаковы.

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

Answer 2

На самом деле есть только один способ изучения объектно-ориентированного проектирования программного обеспечения: изучить его с нуля.Вы не найдете ярлыков для преобразования ваших знаний о другом методе разработки программного обеспечения в понимание объектно-ориентированного проектирования.Вы должны начать с основ, как и все остальные: инкапсуляция, абстракция, отношения is-a и has-a и т. Д.

Answer 3

Концептуальная модель E / R может помочь вам всякий раз, когда вам нужно спроектировать отношения между сущностями. Вам не важно, как они будут реализованы во время разработки: их можно преобразовать в Class, DataTable, XML, ....

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

http://martinfowler.com/eaaCatalog/tableModule.html

Использование Nhibernate или EF или любого другого ORM в системе, подобной той, о которой упоминалось ранее, это пустая трата ресурсов и времени, потому что вы добавляете слой, который вам на самом деле не нужен

Answer 4

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

Учитывая ваши комментарии о ваших проектах ОО, движущихся к подразумеваемому постоянному элементу хранения данных, вы также можете рассмотреть такие концепции, как Аспектно-ориентированное программирование (Spring - отличный инструмент для этого). Кроме того, посмотрите, что может сделать ORM, такой как Hibernate, и как он это делает (хотя это может быть немного сложнее).