какой принцип ооп нарушает следующий фрагмент кода

10 принципов объектно-ориентированного программирования, о которых должен знать каждый разработчик

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

Напоминаем: для всех читателей «»Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

Skillbox рекомендует: Образовательный онлайн-курс «Java-разработчик».

DRY (Don’t Repeat Yourself)

Довольно простой принцип, суть которого ясна из названия: «Не повторяйся». Для программиста это означает необходимость ухода от дублирующего кода, а также возможность использовать в работе абстракцию.

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

Это нужно для того, чтобы упростить код и сделать его поддержку проще, что является основной задачей ООП. Злоупотреблять объединением тоже не стоит, поскольку один и тот же код не пройдет проверку как с OrderId, так и с SSN.

Инкапсуляция изменений

Программные продукты большинства компаний постоянно развиваются. Значит, в код нужно вносить изменения, его нужно поддерживать. Упростить себе жизнь можно при помощи инкапсуляции. Это позволит более эффективно тестировать и поддерживать имеющуюся базу кода. Вот один из примеров.

Принцип открытости/закрытости

Этот принцип можно легко запомнить, прочитав следующее утверждение: «Программные сущности (классы, модули, функции и т.п.) должны быть открыты для расширения, но закрыты для изменения». На практике это означает, что они могут позволять менять свое поведение без изменения исходного кода.

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

Вот пример кода, который нарушает этот принцип.

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

Кстати, открытость-закрытость — один из принципов SOLID.

Принцип единственной ответственности (SRP)

Еще один принцип из набора SOLID. Он гласит, что «существует лишь одна причина, приводящая к изменению класса». Класс решает лишь одну задачу. Он может иметь несколько методов, но каждый из них используется лишь для решения общей задачи. Все методы и свойства должны служить только этому.

Ценность этого принципа в том, что он ослабляет связь между отдельным компонентом программного обеспечения и кодом. Если добавить больше одной функциональности в класс, это вводит связь между двумя функциями. Таким образом, если изменить одну из них, велик шанс испортить вторую, связанную с первой. А это означает увеличение циклов тестирования для того, чтобы выявить все проблемы заранее.

Принцип инверсии зависимостей (DIP)

Выше приведен пример кода, где AppManager зависит от EventLogWriter, который, в свою очередь, тесно связан с AppManager. Если нужен иной способ показать уведомление, будь это пуш, SMS или email, нужно изменить класс AppManager.

Проблема может быть решена при помощи DIP. Так, вместо AppManager мы запрашиваем EventLogWriter, который будет введен при помощи фреймворка.

DIP дает возможность без проблем заменять отдельные модули другими, изменяя модуль зависимости. Это дает возможность изменять один модуль, не влияя на остальные.

Композиция вместо наследования

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

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

Даже “Effective Java” Джошуа Блох (Joshua Bloch) советует отдавать предпочтение композиции, а не наследованию.

Принцип подстановки Барбары Лисков (LSP)

Еще один принцип из инструментария SOLID. Он гласит, что подтипы должны быть заменяемыми для супертипа. То есть методы и функции, которые работают с суперклассом, должны иметь возможность без проблем работать и с его подклассами.

LSP связан как с принципом единой ответственности, так и с принципом разделения ответственности. Если класс дает больше функциональности, чем подкласс, то последний не будет поддерживать некоторые функции, нарушая этот принцип.

Вот участок кода, который противоречит LSP.

Метод area(Rectangle r) просчитывает площадь Rectangle. Программа упадет после выполнения Square, поскольку Square здесь не является Rectangle. Согласно принципу LSP, функции, которые используют ссылки на базовые классы, должны иметь возможность использовать и объекты производных классов без дополнительных инструкций.

Этот принцип, который является специфичным определением подтипа, был предложен Барбарой Лисков в 1987 году на конференции в основном докладе под названием «Абстракция данных и иерархия» — отсюда и его название.

Принцип разделения интерфейса (ISP)

Очередной принцип SOLID. Согласно ему интерфейс, который не используется, не должен быть реализован. Следование этому принципу помогает системе оставаться гибкой и пригодной для рефакторинга при внесении изменений в логику работы.

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

Поскольку написание интерфейса — сложная задача, после завершения работы изменить его, ничего не нарушив, будет проблемой.

Достоинством принципа ISP в Java является то, что сначала нужно реализовать все методы, и только потом они могут быть использованы классами. Поэтому принцип дает возможность снизить количество методов.

Программирование для интерфейса, а не реализации

Здесь все понятно из названия. Применение этого принципа ведет к созданию гибкого кода, который сможет работать с любой новой реализацией интерфейса.

Следует использовать тип интерфейса для переменных, возвращаемых типов или же типа аргумента метода. Пример — использование SuperClass, а не SubClass.

List numbers= getNumbers();

ArrayList numbers = getNumbers();

Вот практическая реализация того, о чем говорится выше.

Принцип делегирования

Распространенный пример — методы equals() и hashCode() в Java. Когда требуется сравнить два объекта, то это действие делегируется соответствующему классу вместо клиентского.

Преимуществом принципа является отсутствие дублирования кода и относительно простое изменение поведения. Также он применим к делегированию событий.

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

Источник

ООП мертво, да здравствует ООП

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).

Я уже долгое время принимаю участие во множестве дискуссий про ECS на форуме, частично потому, что не думаю, что эта модель заслуживает существовать в качестве отдельного термина (спойлер: это просто ad-hoc-версия реляционной модели), но ещё и потому, что почти каждый пост, презентация или статья, рекламирующие паттерн ECS, повторяют следующую структуру:

Я буду называть применение этих вдохновлённых ОО языковых особенностей «ООП«, а применение вдохновлённых ОО техник создания дизайна/архитектур «OOD«. Все очень быстро подхватили ООП. В учебных заведениях есть курсы ОО, выпекающие новых ООП-программистов… однако знание OOD плетётся позади.

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

ООП-код имеет очень плохую репутацию, и в частности потому, что бОльшая часть ООП-кода не следует принципам OOD, а потому не является «истинным» ОО-кодом.

Предпосылки

Как сказано выше, 1990-е стали пиком «моды на ОО», и именно в то время «плохой ООП», вероятно, был хуже всего. Если вы изучали ООП в то время, то, скорее всего, узнали о «четырёх столпах ООП»:

Ниже я буду ссылаться на эти принципы, называя их по акронимам — SRP, OCP, LSP, ISP, DIP, CRP…

Ещё несколько замечаний:

С этой точки зрения совершенно логично следующее:

Квадрат всегда имеет одинаковые высоту и ширину, поэтому из интерфейса квадрата совершенно верно предположить, что площадь равна «ширина * ширина».

Он корректно будет работать для квадратов (вычисляя сумму их площадей), но не сработает для прямоугольников.

Концепции «сущность/компонент» (Entity / Component)

Разобравшись с предпосылками, давайте перейдём к тому, с чего начинал Арас — к так называемой начальной точке «типичного ООП».

Но для начала ещё одно дополнение — Арас называет этот код «традиционным ООП», и на это я хочу возразить. Этот код может быть типичным для ООП в реальном мире, но, как и приведённых выше примерах, он нарушает всевозможные базовые принципы ОО, поэтому его вообще не стоит рассматривать, как традиционный.

Я начну с первого коммита, прежде чем он начал переделывать структуру в сторону ECS: «Make it work on Windows again» 3529f232510c95f53112bbfff87df6bbc6aa1fae

Да, в ста строках кода сложно разобраться сразу, поэтому давайте начнём постепенно… Нам нужен ещё один аспект предпосылок — в играх 90-х популярно было использовать наследование для решения всех проблем многократного использования кода. У вас была Entity, расширяемая Character, расширяемая Player и Monster, и так далее… Это наследование реализаций, как мы описывали его ранее («код с душком»), и кажется, что правильно начинать с него, но в результате это приводит к очень негибкой кодовой базе. Потому что в OOD есть описанный выше принцип «composition over inheritance». Итак, в 2000-х стал популярным принцип «composition over inheritance», и разработчики игр начали писать подобный код.

Что делает этот код? Ну, ничего хорошего

Если говорить вкратце, то этот код заново реализует уже существующую особенность языка — композицию как библиотеку времени выполнения, а не как особенность языка. Можно представить это так, как будто код на самом деле создаёт новый метаязык поверх C++ и виртуальную машину (VM) для выполнения этого метаязыка. В демо-игре Араса этот код не требуется (скоро мы его полностью удалим!) и служит только для того, чтобы примерно в 10 раз снизить производительность игры.

Однако что же он на самом деле выполняет? Это концепция «Entity/Component» («сущность/компонент») (иногда по непонятной причине называемая «Entity/Component system» («система сущность/компонент»)), но она полностью отличается от концепции «Entity Component System» («сущность-компонент-система») (который по очевидным причинам никогда не называется «Entity Component System systems). Он формализует несколько принципов «EC»:

Однако это не требуется. В вашем языке программирования уже есть поддержка композиции как особенность языка — для доступа к ней нет необходимости в раздутой концепции… Зачем же тогда существуют эти концепции? Ну, если быть честным, то они позволяют выполнять динамическую композицию во время выполнения. Вместо жёсткого задания типов GameObject в коде их можно загружать из файлов данных. И это очень удобно, потому что позволяет дизайнерам игр/уровней создавать свои типы объектов… Однако в большинстве игровых проектов бывает очень мало дизайнеров и в буквальном смысле целая армия программистов, поэтому я бы поспорил, что это важная возможность. Хуже того — это ведь не единственный способ, которым можно реализовать композицию во время выполнения! Например, Unity использует в качестве «языка скриптов» C#, и во многих других играх используются его альтернативы, например Lua — удобный для дизайнеров инструмент может генерировать код C#/Lua для задания новых игровых объектов без необходимости использования подобного раздутой концепции! Мы заново добавить эту «функцию» в следующем посте, и сделаем это так, чтобы он не стоил нам десятикратного снижения производительности…

Давайте оценим этот код в соответствии с OOD:

Однако он не так хорош в соблюдении DIP — многие компоненты имеют непосредственное знание друг о друге.

Итак, весь показанный выше код на самом деле можно удалить. Всю эту структуру. Удалить GameObject (в других фреймворках называемые также Entity), удалить Component, удалить FindOfType. Это часть бесполезной VM, нарушающая принципы OOD и ужасно замедляющая нашу игру.

Композиция без фреймворков (то есть использование особенностей самого языка программирования)

Если мы удалим фреймворк композиции, и у нас не будет базового класса Component, то как нашим GameObjects удастся использовать композицию и состоять из компонентов? Как сказано в заголовке, вместо написания этой раздутой VM и создания поверх неё GameObjects на странном метаязыке, давайте просто напишем их на C++, потому что мы программисты игр и это в буквальном смысле наша работа.

Вкратце об изменениях:

Объекты

Поэтому вместо этого кода «виртуальной машины»:

У нас теперь есть обычный код C++:

Алгоритмы

Ещё одно серьёзное изменение внесено в алгоритмы. Помните, в начале я сказал, что интерфейсы и алгоритмы работают в симбиозе, и должны влиять на структуру друг друга? Так вот, антипаттерн «virtual void Update» стал врагом и здесь. Первоначальный код содержит алгоритм основного цикла, состоящий всего лишь из этого:

Вы можете возразить, что это красиво и просто, но ИМХО это очень, очень плохо. Это полностью обфусцирует и поток управления, и поток данных внутри игры. Если мы хотим иметь возможность понимать своё ПО, если мы хотим поддерживать его, если мы хотим добавлять в него новые вещи, оптимизировать его, выполнять его эффективно на нескольких процессорных ядрах, то нам нужно понимать и поток управления, и поток данных. Поэтому «virtual void Update» нужно предать огню.

Вместо него мы создали более явный основной цикл, который сильно упрощает понимание потока управления (поток данных в нём по-прежнему обфусцирован, но мы исправим это в следующих коммитах).

Недостаток такого стиля в том, что для каждого нового типа объекта, добавляемого в игру, нам придётся добавлять в основной цикл несколько строк. Я вернусь к этому в последующем посте из этой серии.

Производительность

Здесь множество огромных нарушений OOD, сделано несколько плохих решений при выборе структуры и остаётся много возможностей для оптимизации, но я доберусь до них в следующем посте серии. Однако на уже на этом этапе понятно, что версия с «исправленным OOD» почти полностью соответствует или побеждает финальный «ECS»-код из конца презентации… И всё, что мы сделали — просто взяли плохой код псевдо-ООП, и заставили его соблюдать принципы ООП (а также удалил сто строк кода)!

Следующие шаги

Здесь я хочу рассмотреть гораздо больший спектр вопросов, в том числе решение оставшихся проблем OOD, неизменяемые объекты (программирование в функциональном стиле) и преимущества, которые они могут привнести в рассуждениях о потоках данных, передачу сообщений, применение логики DOD к нашему OOD-коду, применение относящейся к делу мудрости в OOD-коде, удаление этих классов «сущностей», которые в результате у нас получились, и использование только чистых компонентов, использование разных стилей соединения компонентов (сравнение указателей и обработчиков), контейнеры компонентов из реального мира, доработку ECS-версии для улучшения оптимизации, а также дальнейшую оптимизацию, не упомянутую в докладе Араса (например многопоточность/SIMD). Порядок не обязательно будет таким, и, возможно, я рассмотрю не всё перечисленное…

Источник

В какой строке будет ошибка при компиляции данного кода?

Выберите свойства конструктора.

Конструктор вызывается при создании объекта

Конструктор может иметь любое имя

Конструктор имеет имя, совпадающее с именем класса

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

Конструктор не возвращает значения

При отсутствии конструктора в определении класса, компилятор создает конструктор по умолчанию

При отсутствии конструктора копирования в определении класса, компилятор создает его автоматически

Определите особенности динамического выделения памяти с помощью оператора new.

Не нужно использовать оператор sizeof для вычисления размера выделяемой памяти

Не нужно использовать операцию приведения типов

Для корректной работы необходимо выполнить операцию приведения типов

Можно перегружать оператор new

Невозможно инициализировать данные при динамическом выделении памяти с помощью оператора new

Для использования оператора new необходимо подключить соответствующую библиотеку с помощью директивы #include

Выполняется инициализация объекта, для которого динамически выделяется память с помощью оператора new

3. Какие операции нельзя перегружать в C++?

4. Правило использования перегруженных бинарных операций следующее:

Объект, стоящий с правой стороны операции, вызывает функцию оператора. Объект, стоящий слева от знака операции, передается в функцию в качестве аргумента.

Объект, стоящий с левой стороны операции, вызывает функцию оператора. Объект, стоящий справа от знака операции, передается в функцию в качестве аргумента.

5. Наследование классов на языке C++ задается следующим образом:

class имя_производного_класса (имя_базового класса) < тело_класса >;

class спецификатор_доступа имя_производного_класса, имя_базового_класса < тело_класса >;

class имя_производного_класса : спецификатор_доступа имя_базового_класса < тело_класса >;

6. Имеется ли доступ к членам класса из производного класса при использовании различных спецификаторов доступа в наследуемом классе:

Ответ:

7. Имеется ли доступ к членам класса из внешних функций при использовании различных спецификаторов доступа в классе:

Ответ:

8. Имеется ли доступ к членам класса из самого класса при использовании различных спецификаторов доступа:

Ответ:

9. Правило вызова конструкторов и деструкторов при наследовании:

деструкторы выполняются в порядке наследования, а конструкторы в обратном порядке

конструкторы выполняются в порядке наследования, а деструкторы в обратном порядке

выполняются только конструкторы и деструкторы производного класса

конструкторы и деструкторы выполняются в порядке наследования

это метод класса, объявленный с ключевым словом friend

это функция, не принадлежащая классу, но имеющая доступ к данным класса

это функция, описанная в классе с ключевым словом friend, но не имеющая доступ к данным класса

метод, который нельзя переопределить в производных классах

метод, который вызывается не для объектов класса, а для класса, и выполняет действия, относящиеся не к объекту, а к классу

Назначение инструкции throw.

Это инструкция, которая обрабатывает исключительную ситуацию, возникшую в блоке try.

Это инструкция, которая возбуждает исключительную ситуацию.

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

13. В объектно-ориентированных языках программирования полиморфизм обеспечивается с помощью:

Передачи аргументов по ссылке

Ограничения доступа к полям и методам

14. Какой принцип ООП нарушает следующий фрагмент кода:

15. Выберете наиболее точное определение наследования:

это процесс сокрытия компонентов данных и кода, реализующего функциональность, за интерфейсом, не позволяющим пользователю искажать данные

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

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

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

это механизм, который позволяет описывать новые классы на основании других классов

Как называется способность объекта скрывать свои данные и реализацию от других объектов системы?

17. Какой принцип ООП необходимо использовать, чтобы заменить конструкции if-then-else в данном фрагменте кода:

18. Выберете наиболее точное определение полиморфизма:

это принцип, согласно которому объекты, имеющие одинаковый интерфейс, могут вести себя по-разному

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

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

это процесс сокрытия компонентов данных и кода, реализующего функциональность, за интерфейсом, не позволяющим пользователю искажать данные

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

Корректен ли следующий код?

20. Что напечатает следующий код при создании экземпляра класса X:

21. Что выведет следующий код:

Произойдет ошибка компиляции

Ошибка времени выполнения

22. Что напечатает следующий код:

возникнет ошибка компиляции

возникнет ошибка выполнения

23. Какие независимые друг от друга изменения позволят коду отработать корректно:

изменить public на private в строке 1

изменить строку 2 на код: void Count()

добавить в строку 3 код: void Count()

добавить в строку 3 код: void Counter::Count()

В какой строке будет ошибка при компиляции данного кода?

1 (невозможно объявление статических членов класса)

2 (невозможно объявление статических функций класса)

3 (невозможно обращение к нестатическим членам класса из статических методов класса)

4 (невозможно обращение к статическим членам класса из методов класса)

Источник