Лекция
ооп ( объектно-ориентированное программирование ) стало неотъемлемой частью разработки многих современных проектов, но, не смотря на популярность, эта парадигма является далеко не единственной.
Объектно-Ориентированное Программирование (ООП) — это парадигма программирования, в которой основным элементом являются объекты, а не функции или процедуры, как в процедурном программировании. Объект представляет собой сущность, которая содержит данные и методы для их обработки, что помогает улучшить модульность, масштабируемость и поддерживаемость кода.
Основные понятия ООП были разработаны в 1960-х годах и легли в основу множества современных языков программирования, таких как Python, Java, C++, C#, Ruby и других. Сегодня ООП широко используется для разработки программных систем разного уровня сложности: от простых приложений до крупных программных комплексов.
ООП основывается на четырех фундаментальных принципах: инкапсуляция, наследование, полиморфизм и абстракция. Каждый из них имеет важное значение для создания гибкой и удобной архитектуры.
Инкапсуляция
Инкапсуляция — это принцип, согласно которому данные объекта скрываются от внешнего вмешательства и могут изменяться только через методы этого объекта. Таким образом, доступ к внутреннему состоянию объекта можно контролировать и защищать от прямого изменения.
Пример на Python:
class BankAccount: def __init__(self, balance): self.__balance = balance # Приватное поле def deposit(self, amount): if amount > 0: self.__balance += amount else: print("Сумма должна быть положительной") def get_balance(self): return self.__balance account = BankAccount(1000) account.deposit(500) print(account.get_balance()) # 1500
Наследование
Наследование позволяет одному классу использовать функциональность другого класса, избавляя программиста от необходимости повторного написания кода. Это также помогает структурировать иерархию классов, делая код более понятным и управляемым.
Пример на Python:
class Animal: def speak(self): pass class Dog(Animal): def speak(self): return "Гав" class Cat(Animal): def speak(self): return "Мяу" animals = [Dog(), Cat()] for animal in animals: print(animal.speak()) # Вывод: "Гав" и "Мяу"
Полиморфизм
Полиморфизм позволяет использовать один и тот же метод для объектов разных классов, и каждый класс реализует этот метод по-своему. Это значительно упрощает код, делая его более универсальным и гибким.
Пример на Python:
class Bird: def fly(self): return "Птица летит" class Airplane: def fly(self): return "Самолет летит" def make_it_fly(flying_object): print(flying_object.fly()) make_it_fly(Bird()) # Вывод: "Птица летит" make_it_fly(Airplane()) # Вывод: "Самолет летит"
Абстракция
Абстракция позволяет выделить только значимые характеристики объекта, скрывая детали реализации. Это помогает пользователю сосредоточиться на ключевых функциях объекта и не заботиться о внутренней логике его работы.
Пример на Python:
from abc import ABC, abstractmethod class Shape(ABC): @abstractmethod def area(self): pass class Rectangle(Shape): def __init__(self, width, height): self.width = width self.height = height def area(self): return self.width * self.height rect = Rectangle(4, 5) print(rect.area()) # Вывод: 20
рассмотрим более абстрактно сказанное- в качестве примеров будут выступать трансформеры.
Прежде всего стоит ответить, зачем? Объектно-ориентированная идеология разрабатывалась как попытка связать поведение сущности с ее данными и спроецировать объекты реального мира и бизнес-процессов в программный код. Задумывалось, что такой код проще читать и понимать человеком, т. к. людям свойственно воспринимать окружающий мир как множество взаимодействующих между собой объектов, поддающихся определенной классификации. Удалось ли идеологам достичь цели, однозначно ответить сложно, но де-факто мы имеем массу проектов, в которых с программиста будут требовать ООП.
Не следует думать, что ООП каким-то чудным образом ускорит написание программ, и ожидать ситуацию, когда жители Вилларибо уже выкатили ООП-проект в работу, а жители Виллабаджо все еще отмывают жирный спагетти-код. В большинстве случаев это не так, и время экономится не на стадии разработки, а на этапах поддержки (расширение, модификация, отладка и тестирование), то бишь в долгосрочной перспективе. Если вам требуется написать одноразовый скрипт, который не нуждается в последующей поддержке, то и ООП в этой задаче, вероятнее всего, не пригодится. Однако, значительную часть жизненного цикла большинства современных проектов составляют именно поддержка и расширение. Само по себе наличие ООП не делает вашу архитектуру безупречной, и может наоборот привести к излишним усложнениям.
Иногда можно столкнуться с критикой в адрес быстродействия ООП-программ. Это правда, незначительный оверхед присутствует, но настолько незначительный, что в большинстве случаев им можно пренебречь в пользу преимуществ. Тем не менее, в узких местах, где в одном потоке должны создаваться или обрабатываться миллионы объектов в секунду, стоит как минимум пересмотреть необходимость ООП, ибо даже минимальный оверхед в таких количествах может ощутимо повлиять на производительность. Профилирование поможет вам зафиксировать разницу и принять решение. В остальных же случаях, скажем, где львиная доля быстродействия упирается в IO, отказ от объектов будет преждевременной оптимизацией.
В силу своей природы, объектно-ориентированное программирование лучше всего объяснять на примерах. Как и обещал, нашими пациентами будут трансформеры. Я не трансформеролог, и комиксов не читал, посему в примерах буду руководствоваться википедией и фантазией.
Сразу лирическое отступление: объектно-ориентированный подход возможен и без классов, но мы будем рассматривать, извиняюсь за каламбур, классическую схему, где классы — наше все.
Самое простое объяснение: класс — это чертеж трансформера, а экземпляры этого класса — конкретные трансформеры, например, Оптимус Прайм или Олег. И хотя они и собраны по одному чертежу, умеют одинаково ходить, трансформироваться и стрелять, они оба обладают собственным уникальным состоянием. Состояние — это ряд меняющихся свойств. Поэтому у двух разных объектов одного класса мы можем наблюдать разное имя, возраст, местоположение, уровень заряда, количество боеприпасов и т. д. Само наличие этих свойств и их типы описываются в классе.
Таким образом, класс — это описание того, какими свойствами и поведением будет обладать объект. А объект — это экземпляр с собственным состоянием этих свойств.
Мы говорим «свойства и поведение», но звучит это как-то абстрактно и непонятно. Привычнее для программиста будет звучать так: «переменные и функции». На самом деле «свойства» — это такие же обычные переменные, просто они являются атрибутами какого-то объекта (их называют полями объекта). Аналогично «поведение» — это функции объекта (их называют методами), которые тоже являются атрибутами объекта. Разница между методом объекта и обычной функцией лишь в том, что метод имеет доступ к собственному состоянию через поля.
Итого, имеем методы и свойства, которые являются атрибутами. Как работать с атрибутами? В большинстве ЯП оператор обращения к атрибуту — это точка (кроме PHP и Perl). Выглядит это примерно вот так (псевдокод):
// объявление класса с помощью ключевого слова class
class Transformer(){
// объявление поля x
int x
// объявление метода конструктора (сюда нам чуть ниже передадут 0)
function constructor(int x){
// инициализация поля x
// (переданный конструктору 0 превращается в свойство объекта)
this.x = x
}
// объявление метода run
function run(){
// обращение к собственному атрибуту через this
this.x += 1
}
}
// а теперь клиентский код:
// создаем новый экземпляр трансформера с начальной позицией 0
optimus = new Transformer(0)
optimus.run() // приказываем Оптимусу бежать
print optimus.x // выведет 1
optimus.run() // приказывает Оптимусу еще раз бежать
print optimus.x // выведет 2
В картинках я буду использовать такие обозначения:
Я не стал использовать UML-диаграммы, посчитав их недостаточно наглядными, хоть и более гибкими.
Анимация №1
Что мы видим из кода?
1. this — это специальная локальная переменная (внутри методов), которая позволяет объекту обращаться из своих методов к собственным атрибутам. Обращаю внимание, что только к собственным, то бишь, когда трансформер вызывает свой метод, либо меняет собственное состояние. Если снаружи обращение будет выглядеть так: optimus.x, то изнутри, если Оптимус захочет сам обратиться к своему полю x, в его методе обращение будет звучать так: this.x, то есть "я (Оптимус) обращаюсь к своему атрибуту x". В большинстве языков эта переменная называется this, но встречаются и исключения (например, self)
2. constructor — это специальный метод, который автоматически вызывается при создании объекта. Конструктор может принимать любые аргументы, как и любой другой метод. В каждом языке конструктор обозначается своим именем. Где-то это специально зарезервированные имена типа __construct или __init__, а где-то имя конструктора должно совпадать с именем класса. Назначение конструкторов — произвести первоначальную инициализацию объекта, заполнить нужные поля.
3. new — это ключевое слово, которое необходимо использовать для создания нового экземпляра какого-либо класса. В этот момент создается объект и вызывается конструктор. В нашем примере, конструктору передается 0 в качестве стартовой позиции трансформера (это и есть вышеупомянутая инициализация). Ключевое слово new в некоторых языках отсутствует, и конструктор вызывается автоматически при попытке вызвать класс как функцию, например так: Transformer().
4. Методы constructor и run работают с внутренним состоянием, а во всем остальном не отличаются от обычных функций. Даже синтаксис объявления совпадает.
5. Классы могут обладать методами, которым не нужно состояние и, как следствие, создание объекта. В этом случае метод делают статическим.
(Single Responsibility Principle / Принцип единственной ответственности / Первый принцип SOLID). С ним вы, наверняка, уже знакомы из других парадигм: «одна функция должна выполнять только одно законченное действие». Этот принцип справедлив и для классов: «Один класс должен отвечать за какую-то одну задачу». К сожалению с классами сложнее определить грань, которую нужно пересечь, чтобы принцип нарушался.
Существуют попытки формализовать данный принцип с помощью описания назначения класса одним предложением без союзов, но это очень спорная методика, поэтому доверьтесь своей интуиции и не бросайтесь в крайности. Не нужно делать из класса швейцарский нож, но и плодить миллион классов с одним методом внутри — тоже глупо.
Традиционно в полях объекта могут храниться не только обычные переменные стандартных типов, но и другие объекты. А эти объекты могут в свою очередь хранить какие-то другие объекты и так далее, образуя дерево (иногда граф) объектов. Это отношение называется ассоциацией.
Предположим, что наш трансформер оборудован пушкой. Хотя нет, лучше двумя пушками. В каждой руке. Пушки одинаковые (принадлежат к одному классу, или, если будет угодно, выполненные по одному чертежу), обе одинаково умеют стрелять и перезаряжаться, но в каждой есть свое хранилище боеприпасов (собственное состояние). Как теперь это описать в ООП? С помощью ассоциации:
class Gun(){ // объявляем класс Пушка
int ammo_count // объявляем количество боеприпасов
function constructor(){ // конструктор
this.reload() // вызываем собственный метод "перезарядить"
}
function fire(){ // объявляем метод пушки "стрелять"
this.ammo_count -= 1 // расходуем боеприпас из собственного магазина
}
function reload(){ // объявляем метод "перезарядить"
this.ammo_count = 10 // забиваем собственный магазин боеприпасами
}
}
class Transformer(){ // объявляем класс Трансформер
Gun gun_left // объявляем поле "левая пушка" типа Пушка
Gun gun_right // объявляем поле "правая пушка" тоже типа Пушка
/*
теперь конструктор Трансформера принимает
в качестве аргументов две уже конкретные созданные пушки,
которые передаются извне
*/
function constructor(Gun gun_left, Gun gun_right){
this.gun_left = gun_left // устанавливаем левую пушку на борт
this.gun_right = gun_right // устанавливаем правую пушку на борт
}
// объявляем метод Трансформер "стрелять", который сначала стреляет...
function fire(){
// левой пушкой, вызывая ее метод "стрелять"
this.gun_left.fire()
// а затем правой пушкой, вызывая такой же метод "стрелять"
this.gun_right.fire()
}
}
gun1 = new Gun() // создаем первую пушку
gun2 = new Gun() // создаем вторую пушку
optimus = new Transformer(gun1, gun2) // создаем трансформера, передавая ему обе пушки
Анимация №2
this.gun_left.fire() и this.gun_right.fire() — это обращения к дочерним объектам, которые происходят так же через точки. По первой точке мы обращаемся к атрибуту себя (this.gun_right), получая объект пушки, а по второй точке обращаемся к методу объекта пушки (this.gun_right.fire()).
Итог: робота сделали, табельное оружие выдали, теперь разберемся, что тут происходит. В данном коде один объект стал составной частью другого объекта. Это и есть ассоциация. Она в свою очередь бывает двух видов:
1. Композиция — случай, когда на фабрике трансформеров, собирая Оптимуса, обе пушки ему намертво приколачивают к рукам гвоздями, и после смерти Оптимуса, пушки умирают вместе с ним. Другими словами, жизненный цикл дочернего объекта совпадает с жизненным циклом родительского.
2. Агрегация — случай, когда пушка выдается как пистолет в руку, и после смерти Оптимуса этот пистолет может подобрать его боевой товарищ Олег, а затем взять в свою руку, либо сдать в ломбард. То бишь жизненный цикл дочернего объекта не зависит от жизненного цикла родительского, и может использоваться другими объектами.
Ортодоксальная ООП-церковь проповедует нам фундаментальную троицу — инкапсуляцию, полиморфизм и наследование, на которых зиждется весь объектно-ориентированный подход. Разберем их по порядку.
Наследование — это механизм системы, который позволяет, как бы парадоксально это не звучало, наследовать одними классами свойства и поведение других классов для дальнейшего расширения или модификации.
Что если, мы не хотим штамповать одинаковых трансформеров, а хотим сделать общий каркас, но с разным обвесом? ООП позволяет нам такую шалость путем разделения логики на сходства и различия с последующим выносом сходств в родительский класс, а различий в классы-потомки. Как это выглядит?
Оптимус Прайм и Мегатрон — оба трансформеры, но один является автоботом, а второй десептиконом. Допустим, что различия между автоботами и десептиконами будут заключаться только в том, что автоботы трансформируются в автомобили, а десептиконы — в авиацию. Все остальные свойства и поведение не будут иметь никакой разницы. В таком случае можно спроектировать систему наследования так: общие черты (бег, стрельба) будут описаны в базовом классе «Трансформер», а различия (трансформация) в двух дочерних классах «Автобот» и «Десептикон».
class Transformer(){ // базовый класс
function run(){
// код, отвечающий за бег
}
function fire(){
// код, отвечающий за стрельбу
}
}
class Autobot(Transformer){ // дочерний класс, наследование от Transformer
function transform(){
// код, отвечающий за трансформацию в автомобиль
}
}
class Decepticon(Transformer){ // дочерний класс, наследование от Transformer
function transform(){
// код, отвечающий за трансформацию в самолет
}
}
optimus = new Autobot()
megatron = new Decepticon()
Анимация №3
Сей пример наглядно иллюстрирует, как наследование становится одним из способов дедуплицировать код (DRY-принцип) с помощью родительского класса, и одновременно предоставляет возможности для мутации в классах-потомках.
Если же в классе-потомке переопределить уже существующий метод в классе-родителе, то сработает перегрузка. Это позволяет не дополнять поведение родительского класса, а модифицировать. В момент вызова метода или обращения к полю объекта, поиск атрибута происходит от потомка к самому корню — родителю. То есть, если у автобота вызвать метод fire(), сначала поиск метода производится в классе-потомке — Autobot, а поскольку его там нет, поиск поднимается на ступень выше — в класс Transformer, где и будет обнаружен и вызван. Следует отметить, что модификация нарушает LSP из набора принципов SOLID, но мы рассматриваем только техническую возможность.
Любопытно, что чрезмерно глубокая иерархия наследования может привести к обратному эффекту — усложнению при попытке разобраться, кто от кого наследуется, и какой метод в каком случае вызывается. К тому же, не все архитектурные требования можно реализовать с помощью наследования. Поэтому применять наследование следует без фанатизма. Существуют рекомендации, призывающие предпочитать композицию наследованию там, где это уместно. Любая критика наследования, которую я встречал, подкрепляется неудачными примерами, когда наследование используется в качестве золотого молотка. Но это совершенно не означает, что наследование в принципе всегда вредит. Мой нарколог говорил, что первый шаг — это признать, что у тебя зависимость от наследования.
Как при описании отношений двух сущностей определить, когда уместно наследование, а когда — композиция? Можно воспользоваться популярной шпаргалкой: спросите себя, сущность А является сущностью Б? Если да, то скорее всего, тут подойдет наследование. Если же сущность А является частью сущности Б, то наш выбор — композиция.
Применительно к нашей ситуации это будет звучать так:
Для самопроверки попробуйте обратную комбинацию, получится фигня. Эта шпаргалка помогает в большинстве случаев, но бывают и другие факторы, на которые стоит опираться при выборе между композицией и наследованием. Кроме того, эти методы можно комбинировать для решения разного типа задач.
Еще одно важное отличие наследования от композиции в том, что наследование имеет статическую природу и устанавливает отношения классов только на этапе интерпретации/компиляции. Композиция же, как мы видели в примерах, позволяет менять отношение сущностей на лету прямо в рантайме — иногда это очень важно, поэтому об этом нужно помнить при выборе отношений (если конечно нет желания использовать метапрограммирование).
Мы рассмотрели ситуацию, когда два класса унаследованы от общего потомка. Но в некоторых языках можно сделать и наоборот — унаследовать один класс от двух и более родителей, объединив их свойства и поведение. Возможность наследоваться от нескольких классов вместо одного — это множественное наследование.
Вообще, в кругах иллюминатов бытует мнение, что множественное наследование — это грех, оно несет за собой ромбовидную проблему и неразбериху с конструкторами. Кроме того, задачи, которые решаются множественным наследованием, можно решать другими механизмами, например, механизмом интерфейсов (о котором мы тоже поговорим). Но справедливости ради, следует отметить, что множественное наследование удобно использовать для реализации примесей.
Кроме обычных классов в некоторых языках существуют абстрактные классы. От обычных классов они отличаются тем, что нельзя создать объект такого класса. Зачем же нужен такой класс, спросит читатель? Он нужен для того, чтобы от него могли наследоваться потомки — обычные классы, объекты которых уже можно создавать.
Абстрактный класс наряду с обычными методами содержит в себе абстрактные методы без имплементации (с сигнатурой, но без кода), которые обязан имплементировать программист, задумавший создать класс-потомок. Абстрактные классы не обязательны, но они помогают установить контракт, обязующий имплементировать определенный набор методов, дабы уберечь программиста с плохой памятью от ошибки имплементации.
Полиморфизм — свойство системы, позволяющее иметь множество реализаций одного интерфейса. Ничего непонятно. Обратимся к трансформерам.
Положим, у нас есть три трансформера: Оптимус, Мегатрон и Олег. Трансформеры боевые, стало быть обладают методом attack(). Игрок, нажимая у себя на джойстике кнопку «воевать», сообщает игре, чтобы та вызвала метод attack() у трансформера, за которого играет игрок. Но поскольку трансформеры разные, а игра интересная, каждый из них будет атаковать каким-то своим способом. Скажем, Оптимус — объект класса Автобот, а Автоботы снабжаются пушками с плутониевыми боеголовками (да не прогневаются фанаты трансформеров). Мегатрон — Десептикон, и стреляет из плазменной пушки. Олег — басист, и он обзывается. А в чем польза?
Польза полиморфизма в данном примере заключается в том, что код игры ничего не знает о реализации его просьбы, кто как должен атаковать, его задача просто вызвать метод attack(), сигнатура которого одинакова для всех классов персонажей. Это позволяет добавлять новые классы персонажей, или менять методы существующих, не меняя код игры. Это удобно.
Инкапсуляция — это контроль доступа к полям и методам объекта. Под контролем доступа подразумевается не только можно/неможно, но и различные валидации, подгрузки, вычисления и прочее динамическое поведение.
Во многих языках частью инкапсуляции является сокрытие данных. Для этого существуют модификаторы доступа (опишем те, которые есть почти во всех ООП языках):
class Transformer(){
public function constructor(){ }
protected function setup(){ }
private function dance(){ }
}
Как правильно выбрать модификатор доступа? В простейшем случае так: если метод должен быть доступен внешнему коду, выбираем public. В противном случае — private. Если есть наследование, то может потребоваться protected в случае, когда метод не должен вызываться снаружи, но должен вызываться потомками.
Геттеры и сеттеры — это методы, задача которых контролировать доступ к полям. Геттер считывает и возвращают значение поля, а сеттер — наоборот, принимает в качестве аргумента значение и записывает в поле. Это дает возможность снабдить такие методы дополнительными обработками. Например, сеттер при записи значения в поле объекта, может проверить тип, или входит ли значение в диапазон допустимых (валидация). В геттер же можно добавить, ленивую инициализацию или кэширование, если актуальное значение на самом деле лежит в базе данных. Применений можно придумать множество.
В некоторых языках есть синтаксический сахар, позволяющий такие аксессоры маскировать под свойства, что делает доступ прозрачным для внешнего кода, который и не подозревает, что работает не с полем, а с методом, у которого под капотом выполняется SQL-запрос или чтение из файла. Так достигается абстракция и прозрачность.
Задача интерфейса — снизить уровень зависимости сущностей друг от друга, добавив больше абстракции.
Не во всех языках присутствует этот механизм, но в ООП языках со статической типизацией без них было бы совсем худо. Выше мы рассматривали абстрактные классы, затрагивая тему контрактов, обязующих имплементировать какие-то абстрактные методы. Так вот интерфейс очень смахивает на абстрактный класс, но является не классом, а просто пустышкой с перечислением абстрактных методов (без имплементации). Другими словами, интерфейс имеет декларативную природу, то есть, чистый контракт без капельки кода.
Обычно в языках, в которых есть интерфейсы, нет множественного наследования классов, но есть множественное наследование интерфейсов. Это позволяет классу перечислить интерфейсы, которые он обязуется имплементировать.
Классы с интерфейсами состоят в отношении «многие ко многим»: один класс может имплементировать множество интерфейсов, и каждый интерфейс, в свою очередь, может имплементироваться многими классами.
У интерфейса двустороннее применение:
Например, если какой-то объект помимо основного поведения, может быть сериализован, то пускай он имплементирует интерфейс «Сериализуемый». А если объект можно склонировать, то пусть он имплементирует еще один интерфейс — «Клонируемый». И если у нас есть какой-то транспортный модуль, который передает объекты по сети, он будет принимать любые объекты, имплементирующие интерфейс «Сериализуемый».
Представим, что каркас трансформера оборудован тремя слотами: слот для оружия, для генератора энергии и для какого-нибудь сканера. Эти слоты обладают определенными интерфейсами: в каждый слот можно установить только подходящее оборудование. В слот для оружия можно установить ракетную установку или лазерную пушку, в слот для генератора энергии — ядерный реактор или РИТЭГ (радиоизотопный термоэлектрический генератор), а в слот для сканера — радар или лидар. Суть в том, что каждый слот имеет универсальный интерфейс подключения, а уже конкретные устройства должны соответствовать этому интерфейсу. К примеру, на материнских платах используется несколько типов слотов: слот для процессора позволяет подключать различные процессоры, подходящие под данный сокет, а слот SATA — любой SSD или HDD накопитель или даже CD/DVD.
Обращаю внимание, что получившаяся система слотов у трансформеров — это пример использования композиции. Если же оборудование в слотах будет сменным в ходе жизни трансформера, то тогда это уже агрегация. Для наглядности, мы будем называть интерфейсы, как принято в некоторых языках, добавляя заглавную «И» перед именем: IWeapon, IEnergyGenerator, IScanner.
// описания интерфейсов:
interface IWeapon{
function fire() {} // декларация метода без имплементации. Ниже аналогично
}
interface IEnergyGenerator{
// тут уже два метода, которые должны будут реализовать классы:
function generate_energy() {} // первый
function load_fuel() {} // второй
}
interface IScanner{
function scan() {}
}
// классы, реализующие интерфейсы:
class RocketLauncher() : IWeapon
{
function fire(){
// имплементация запуска ракеты
}
}
class LaserGun() : IWeapon
{
function fire(){
// имплементация выстрела лазером
}
}
class NuclearReactor() : IEnergyGenerator
{
function generate_energy(){
// имплементация генерации энергии ядерным реактором
}
function load_fuel(){
// имплементация загрузки урановых стержней
}
}
class RITEG() : IEnergyGenerator
{
function generate_energy(){
// имплементация генерации энергии РИТЭГ
}
function load_fuel(){
// имплементация загрузки РИТЭГ-пеллет
}
}
class Radar() : IScanner
{
function scan(){
// имплементация использования радиолокации
}
}
class Lidar() : IScanner
{
function scan(){
// имплементация использования оптической локации
}
}
// класс - потребитель:
class Transformer() {
// привет, композиция:
IWeapon slot_weapon // Интерфейсы указаны в качестве типов данных.
IEnergyGenerator slot_energy_generator // Они могут принимать любые объекты,
IScanner slot_scanner // которые имплементируют указанный интерфейс
/*
в параметрах методов интерфейс тоже указан как тип данных,
метод может принимать объект любого класса,
имплементирующий данный интерфейс:
*/
function install_weapon(IWeapon weapon){
this.slot_weapon = weapon
}
function install_energy_generator(IEnergyGenerator energy_generator){
this.slot_energy_generator = energy_generator
}
function install_scanner(IScanner scanner){
this.slot_scanner = scanner
}
}
// фабрика трансформеров
class TransformerFactory(){
function build_some_transformer() {
transformer = new Transformer()
laser_gun = new LaserGun()
nuclear_reactor = new NuclearReactor()
radar = new Radar()
transformer.install_weapon(laser_gun)
transformer.install_energy_generator(nuclear_reactor)
transformer.install_scanner(radar)
return transformer
}
}
// использование
transformer_factory = new TransformerFactory()
oleg = transformer_factory.build_some_transformer()
Анимация №4
К сожалению, в картинку не влезла фабрика, но она все равно необязательна, трансформера можно собрать и во дворе.
Обозначенный на картинке слой абстракции в виде интерфейсов между слоем имплементации и слоем-потребителем дает возможность абстрагировать одних от других. Вы можете это наблюдать, посмотрев на каждый слой в отдельности: в слое имплементации (слева) нет ни слова про класс Transformer, а в слое-потребителе
продолжение следует...
Часть 1 ООП (Объектно-Ориентированное Программирование) на примерах
Часть 2 Абстракция - ООП (Объектно-Ориентированное Программирование) на примерах
Комментарии
Оставить комментарий
Объектно-ориентированное программирование ООП
Термины: Объектно-ориентированное программирование ООП