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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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