Как часто вам нужно создавать реальную иерархию классов в повседневном программировании? - PullRequest
2 голосов
/ 14 декабря 2008

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

Ответы [ 9 ]

4 голосов
/ 14 декабря 2008

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

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

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

3 голосов
/ 14 декабря 2008

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

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

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

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

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

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

1 голос
/ 14 декабря 2008

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

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

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

1 голос
/ 14 декабря 2008

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

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

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

1 голос
/ 14 декабря 2008

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

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

1 голос
/ 14 декабря 2008

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

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

0 голосов
/ 15 декабря 2008

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

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

0 голосов
/ 14 декабря 2008

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

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

0 голосов
/ 14 декабря 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...