Как часто вам нужно создавать реальную иерархию классов в повседневном программировании?

Я создаю бизнес-приложения с интенсивным использованием базы данных. Большая часть работы по программированию заключается в подключении компонентов к базе данных и изменении компонентов для адаптации к общему поведению интерфейса. В основном я использую Delphi с его богатой библиотекой VCL и обычно покупаю необходимые компоненты. Я храню большую часть бизнес-логики в базе данных. Я редко получаю возможность построить хорошую иерархию классов снизу вверх, так как в этом действительно нет необходимости. У кого-нибудь еще есть этот опыт?

14.12.2008 16:21:30
9 ОТВЕТОВ
РЕШЕНИЕ

Ответ на этот вопрос не является полностью независимым от языка;

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

Закрытия и лямбды C # делают наследование по техническим причинам гораздо менее актуальным. Поэтому обычно наследование используется по смысловым причинам (например, кошка расширяет животное).

В последнем проекте C #, над которым я работал, мы более или менее создали все иерархии классов в течение нескольких недель. После этого все было более или менее закончено.

В моем текущем Java-проекте мы постоянно создаем новые иерархии классов.

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

3
14.12.2008 17:47:29

Я надеваю шляпу для архитекторов / дизайн класса, вероятно, один или два раза в месяц. Это, наверное, лучшая шляпа, которая у меня есть, и носить ее очень весело.

Зависит от того, на какой стадии жизненного цикла находится ваш проект.

1
14.12.2008 16:29:16

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

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

1
14.12.2008 16:34:53

Это действительно зависит от типов / фаз проектов, над которыми вы работаете. Я делаю это каждый день, потому что я работаю над внутренними компонентами базы данных для новой базы данных, создавая связанные библиотеки / структуры. Я бы сделал это гораздо реже, если бы работал в зрелой среде, используя библиотеки других людей.

0
14.12.2008 16:56:37

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

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

Если вы согласны со мной в том, что бизнес-логика должна быть не в базе данных, а в приложении, тогда я рекомендую вам обратиться к шаблону проектирования MVC, чтобы руководствоваться вашим дизайном. Вы найдете ваш дизайн, содержащий классы или объекты. Ваши VCL будут представлять ваш View, и вы можете настроить отображение классов вашей модели непосредственно в таблицу базы данных, т. Е. Каждый член в классе в модели соответствует полю в таблице базы данных (опять же, это норма, но будет исключение). где эта простота не применяется). Затем вам понадобится слой для обработки CRUD (создание, чтение, обновление, удаление) классов Model для таблиц базы данных. В итоге вы получите «многоуровневое» приложение, которое легче поддерживать и улучшать.

1
14.12.2008 17:01:33
В Delphi у нас были модули данных за последние 10 лет или около того. Они представляют контроллер в модели MVC. MVC были естественным способом ведения дел в Delphi. Существует много споров, помещающих BL в БД. Мне это нравится, и это облегчает создание как веб-версии, так и настольной версии
Tom 14.12.2008 17:36:15
Бизнес-логика должна быть в базе данных, но это означает, что база данных должна быть OODB.
Stephan Eggermont 14.12.2008 18:55:45

Для меня иногда проблема яснее или проще с подклассами, но не часто.

Это также немного меняется в данном дизайне, поскольку он подвергается рефакторингу.

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

4
14.12.2008 18:07:46
мама расширяет прародителя - там, исправил это для вас;) Да, большое замечание по поводу подклассов для собственной проблемы там.
micahwittman 18.12.2009 04:23:53

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

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

0
4.02.2011 05:34:56

Это зависит от того, что вы подразумеваете под иерархией - наследование или расслоение?

Когда впервые появились объектно-ориентированные языки, наследование было чрезмерным. Сложные иерархии были распространены. Теперь интерфейсы (как в Java и C #) предоставляют более простой способ получить преимущество полиморфизма без осложнений наследования. Я редко использую наследование больше.

Слоистость, однако, жизненно важна при создании большого приложения. Расслоение не позволяет общим низкоуровневым классам (таким как списки) напрямую ссылаться на конкретные высокоуровневые классы (например, окна веб-браузера). Насколько я знаю, формального способа описания наслоения не существует, но есть общие рекомендации (модель-представление-контроллер (MVC), отделить логику графического интерфейса от бизнес-логики, отделить данные от представления и т. Д.).

1
14.12.2008 18:43:07

Я занимаюсь инфраструктурой для продукта наших компаний, поэтому я пишу много кода, который позже будет использоваться парнями из других команд. В итоге я написал много абстрактных классов, интерфейсов, иерархий и так далее. В основном это просто шаблон «поведения по умолчанию в абстрактном / виртуальном классе, который другие программисты могут переопределить».

Должен сказать, очень сложно.

0
14.12.2008 21:24:42