SOLID

S.O.L.I.D

• 5 принципов проектирования
  • Single responsibility
  • Open-closed
  • Liskov substitution
  • Interface segregation
  • Dependency inversion

Нафига S.O.L.I.D?

• Приложения постоянно эволюционируют
• Добавляются безумные фичи
• Есть сложные условия активации фичей
• Без каркаса приложение развалится
• Приложения огромны с кучей связей

Single Responsibility

На каждую сущность должна быть возложена одна единственная ответственность.

• Единственная причина для изменения
  • Точечные изменения → меньше ошибок
• Одна ответственность ≠ одна функция
  • Прим. JSON.parse & JSON.stringify

Пример про Корзину

            function addToCart(e) {
                var $el = $(this);
                cart.push($el.attr('id'), $el.attr('title'));
                var newItem = $('<li></li>')
                    .html($el.attr('title'))
                    .attr('id-cart', $el.attr('id'))
                    .appendTo('#cart');
            }
        

Проблемы в примере

• Знает о структуре шаблона
• Заполняет хранилище данных
• Генерирует DOM-ноды

Исправленный пример

            function addToCart(item) {
                cart.add(_.pick(item, ['id', 'title']));
            }
        

            this.bindTo(cart, 'add', (item) => {
                render(item).appendTo(this.$el);
            });
        

Проблемы в примере

• Знает способ рендера
  • render()
• Знает как добавлять элементы
  • .appendTo()
• Знает куда добавлять
  • this.$el

Более исправленный пример

            bind('#cart', {
                cart: cart
            });
        

            <ul id="cart">
                <li data-each-item="cart" id="{item.id}">
                    {item.title}
                </li>
            </ul>
        

Пример про Mailer

            class MyMailer {
                send (options, cb) {
                    this.smtpTransport.sendMail(options, () => {
                        cb();
                        console.log('Message sent');
                    });
                }
            }
        

Проблемы в примере

• Отправляет почту
• Ведет лог
• Знает про консоль
• Сложно протестировать

Исправленный пример

            class MyMailer {
                /**
                 * @param {ILogger} logger
                 */
                constructor(logger) {
                    this.logger = logger;
                }
            }
        

Исправленный пример

            class MyMailer {
                send (options, cb) {
                    this.smtpTransport.sendMail(options, => {
                        cb();
                        this.logger.log('Message sent');
                    });
                }
            }
        

Проблемы в примере

• Отправляет почту
• Ведет лог

Более исправленный пример

            class MyMailer extends EventEmitter {
                send (options, cb) {
                    this.smtpTransport.sendMail(options, => {
                        cb();
                        this.emit('done', 'Message sent');
                    });
                }
            }
        

Стереотипы ролей объектов

• Information holder — хранит и предоставляет информацию другим
• Structurer — поддерживает связи между другими объектами
• Service provider — объект со специфичной задачей по требованию

Стереотипы ролей объектов

• Controller — решает что делать и управляет действием
• Coordinator — ничего не решает, но делегирует работу на других
• Interfacer — трансформирует информацию или запросы

Влияние Single Responsibility

• Маленькие модули
• Проще и честнее тесты
• Четкая структура приложения
• Дешевле реиспользовать модули
• Меньше негативных последствий изменений

Задачи по SRP

• Рефакторинг кода
• Написание кода

Open-Closed

Сущности (классы, модули, функции) должны быть открыты к раширению, но закрыты от модификаций.

• TL;DR Плагины — это вин!
• Расширяемость сущностей
  • Гибко меняют поведение
• Закрытость сущностей
  • Адаптация не должна влиять на код сущности

Пример с отрисовкой вопросов

            function renderQuestion (q) {
                switch (q.type) {
                    case 'yes-no':
                    case 'multi':
                        return q.title + renderAnswers(q.answers);
                }
            }
        

Проблемы в примере

• Новый тип вопроса = изменеие кода
• Несколько обязанностей

Исправленный пример

            class QuestionRenderer {
                constructor () {
                    this.methods = {};
                }
                use (methods) {
                    Object.assign(this.methods, methods);
                }
            }
        

Исправленный пример

            class QuestionRenderer {
                render (question) {
                    return this.methods[question.type](question);
                }
            }
        

Опять пример про Mailer

            class MyMailer {
                send (mail, cb) {
                    this.smtpTransport.sendMail(mail, => () {
                        cb();
                        console.log('Message sent');
                    });
                }
            }
        

Проблемы в примере

• Отправляет почту
• Ведет лог
• Нельзя определить формат лога
• Нельзя изменить логгер (консоль, БД, сервис)

Исправленный пример

            class MyMailer extends EventEmitter {
                send (mail) {
                    this.emit('before-send', mail);
                    this.smtpTransport.sendMail(mail, => (err, st) {
                        if (err) return this.emit('error', err);
                        this.emit('after-send', st);
                    });
                }
            }
        

Пример использования

            var mailer = new MyMailer(options);
            listenTo(mailer, 'before-send', formatAndSaveLogToDb);
            listenTo(mailer, 'after-send', formatAndPipeToStdout);
            listenTo(mailer, 'after-send', () => res.render('ok'));
            listenTo(mailer, 'error', sendAlertSmsTo(cfg.adminEmail));
            mailer.send(someMail);
        

Пример про робота

            class Robot {
                constructor (weapons) {
                    this.weapons = weapons;
                    this.weapon = weapons[0];
                }
                shoot () {}
            }
        

Пример про робота

            shoot () {
                if (this.weapon instanceof Shotgun) {
                    this.weapon.loadShell(1);
                    this.weapon.pressTrigger();
                }
                if (this.weapon instanceof Grenade) {
                    this.weapon.throw();
                }
            }
        

Проблемы в примере

• Знает про все типы оружия
• Знает как пользоватсья каждым
• Новое оружение = изменеие кода

Исправленный пример

            class Robot {
                constructor (weapons) {
                    this.weapons = weapons;
                    this.weapon = weapons[0];
                }
                shoot () {
                    this.weapon.use();
                }
            }
        

Влияние Open-Closed

• Сущности более гибкие
• Проще тестировать
• Меньше сильных связей
  • Зависимость от интерфейса
• Меньше правок в базовых сущностях
  • Особенно если они чужие

Задачи по OCP

• Рефакторинг кода
• Написание кода

Liskov Substitution

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

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

• Наследники сохраняют семантику.
• Ожидаемое поведение для использующих.

Liskov Substitution

• Сабклассы сохраняют поведение родителя
  • Предусловия не могут быть усилены.
  • Постусловия не могут быть ослаблены.
  • Не могут выбрасывать новые исключения.
  • Инварианты должны быть сохранены.
  • Соблюдены исторические ограничения.

Пример нарушения Предусловий

            var robot = new Robot();
            robot.shot();
            // class SniperRobot extends Robot
            var robot = new SniperRobot();
            robot.reload();
            robot.shot();
        

Проблемы в примере

• Производный класс вводит предусловие reload()
• Пользователю класса придется проверять на instanceof

Пример нарушения Постусловий

            class PointFromIp extends Geolocation {
                getLocation () {
                    return super().point;
                }
            }
        

Проблемы в примере

• Производный класс ослабляет интерфейс getLocation() (меняет)
• Пользователю класса придется проверять на instanceof

Пример нарушения Исключений

            function Robot(name) {
                this.name = name;
            }
            function RobotMk2 (name, weapons) {
                Robot.call(this, name);
                if (!weapons) throw new Error();
            }
        

Проблемы в примере

• Класс вводит обязательный агрумент weapons
• Пользователь класса добавит try/catch
• Пользователь класса добавит костыль для weapons

Пример нарушения Инвариантности

            class Vehicle {
                constructor () {
                    this.speed = 0;
                }
                accelerate () { this.speed++; }
                decelerate () { this.speed--; }
            }
        

Пример нарушения Инвариантности

            class FastVehicle extends Vehicle {
                accelerate () { this.speed++; this.speed++; }
            }
            var vehicle = new FastVehicle();
            vehicle.accelerate();
            vehicle.decelerate();
            expect(vehicle.speed).to.equal(0);
        

Пример нарушения Инвариантности

            class Person {
                decelerateBike () {
                    this.bike.decelerate();
                    if (this.bike instanceof FastVehicle) {
                        this.bike.decelerate();
                    }
                }
            }
        

Проблемы в примере

• Класс не соблюдает инвариантность состояния
• Пользователю нужно знать про реализации класса (FastVehicle)
• Пользователь вводит костыль

Пример нарушения Исторических ограничений

            class Point {
                center() {
                    return this._center;
                }
            }
        

Пример нарушения Исторических ограничений

            class MutablePoint extends Point {
                center(value) {
                    if (!value) return this._center;
                    this._center = value;
                }
            }
        

Проблемы в примере

• Класс не соблюдает исторические ограничения
• Point._center стал мутабильный

Пример соблюдения Исторических ограничений

            class Circle extends Point {
                radius(value) {
                    if (!value) return this._radius;
                    this._radius = value;
                }
            }
        

Пример

            class Square extends Rectangle {
                width(value) {
                    if (!value) return this._width;
                    this._width = value;
                    this._height = value;
                }
                height(value) { return this.width(value); }
            }
        

Проблемы в примере

• Не соблюдается инвариантность класса
• Лучше создать новый класс Square

            var sq = new Square();
            sq.width(1);
            sq.height(2);
            expect(sq.width() * sq.height()).to.equal(2);
        

Влияние Liskov substitution

• Проектирование по контракту
• Поведение объекта + интерфейс
• Предсказуемое поведение потомков
• Поощряется написание тестов поведения
• Композиция классов важнее наследования

Задачи по LSP

• Рефакторинг кода
• Написание кода

Interface Segregation

Наследники не должны имплементировать методы, которыми они не пользуются.

• Похож на SRP, но применим для интерейса.
• Интерфейсы должны описывать одну сущность.

Интерфейсы и JavaScript

• Сигнатура метода/операции
  • Имя метода
  • Предусловия и аргументы
  • Постусловия и результат
• Интерфейс — совокупность сигнатур

Интерфейсы и JavaScript

            // EventEmitter
            {
                on: function(event, cb) {}
                off: function(event, cb) {}
                emit: function(event, data) {}
            }
        

Интерфейсы и JavaScript

            // Promise aka thenable
            {
                // @param {Function} [onFulfilled]
                // @param {Function} [onRejected]
                // @returns {Promise}
                then: function(onFulfilled, onRejected) {}
            }
        

Пример

            class IWeapon {
                reload() {
                    throw new AbstractMethodError();
                }
                fire() {
                    throw new AbstractMethodError();
                }
            }
        

Пример

            class Rifle extends IWeapon {
                reload() {
                    this._pullHammer();
                }
                fire() {
                    this._pullTrigger();
                }
            }
        

Пример

            class Grenade extends IWeapon {
                reload() {}
                fire() {
                    this._pullCheck();
                    this._throw();
                }
            }
        

Проблемы в примере

• Grenade имплементирует заглушку reload
• Заглушки могут вызвать проблемы в будущем
• Интерфейс слишком общий для всех орудий

Пример

            class IProduct {
                log(value) {throw new AbstractMethodError();}
                addTo(cart) {throw new AbstractMethodError();}
                destroy() {throw new AbstractMethodError();}
                getLink() {throw new AbstractMethodError();}
                updateImage(img) {throw new AbstractMethodError();}
                loadImage(img, cb) {throw new AbstractMethodError();}
            }
        

Пример

            class IButton {
                getIcon() {throw new AbstractMethodError();}
                getLabel(cart) {throw new AbstractMethodError();}
                getUrl() {throw new AbstractMethodError();}
                onClick(cb) {throw new AbstractMethodError();}
                onLongPress(cb) {throw new AbstractMethodError();}
            }
        

Проблемы в примере

• Интерфейс "толстый"
• Содержит множество обязанностей

Role Interface

• Объект может иметь несколько ролей
• См. Стереотипы ролей объектов

Влияние Interface Segregation

• Один интерфейс = одна роль
• Маленькие интерфейсы

Задачи по ISP

• Рефакторинг кода
• Написание кода

Dependency Inversion

Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракции.

Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

• Прим: YBlock использует jQuery, YButton наследуется от YBlock.

Пример

            class TrackMap {
                renderMap() {
                    return new google.maps.Map(this.el, this.options);
                }
                addMarker(options) {
                    new google.maps.Marker(options).setMap(this.map);
                }
            }
        

Проблемы в примере

• Имеет сильную связанность с google.maps
• Знает интерфейс google.maps.Map
• Знает интерфейс google.maps.Marker
• Знает как добавлять маркер на карту

Решение проблем в примере

            var MapProvider = {
                // @param {Object}   options
                // @param {Number[]} options.ll
                // @param {String}   options.title
                // @returns {IMarker}
                Marker(options) {}
                Map(options) {}
            }
        

Решение проблем в примере

            class TrackMap {
                constructor(mapProvider) {
                    this.api = mapProvider;
                }
                addMarker(options) {
                    var marker = new this.api.Marker(options);
                    marker.addTo(this.map);
                }
            }
        

Решение проблем в примере

• Было: TrackMap → g.maps
• Стало: TrackMap ← MapProvider ← *.maps
• Теперь MapProvider имеет единый интерфейс
• MapProvider использует *.maps

Влияние Dependency Inversion

• Мягкость — изменения затрагивают одну часть
• Гибкость — изменения не ломают систему
• Мобильность — модули не имеют жестких связей

Попытка реиспользовать модуль в новом проекте не должна привести к копипасту половины модулей из старого проекта.

Задачи по DIP

• Рефакторинг кода
• Написание кода

Заключение

• Приложения постоянно эволюционируют
• Добавляются безумные фичи
• Есть сложные условия активации фичей
• Без каркаса приложение развалится
• Приложения огромны с кучей связей

Заключение

• Single responsibility
• Open-closed
• Liskov substitution
• Interface segregation
• Dependency inversion