Рубрики
Паттерн

Введение

Паттерн
шаблон проектирования

Часто встречающиеся решение определённой проблемы при проектировании архитектуры
(веб-приложения или любой другой программы)

Способ решения периодически возникающих проблем некоторых типовых задач

Паттерн — это не

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

Отличие SDK от API

SDK
software development kit
набор инструментов для работы с чем-то
рецепт, нарезные продукты, четко отмеренные специи, набор всех кастрюль-сковородок, которые понадобится вам в готовке

комплект, для разработки программного обеспечения
В sdk входят

  • библиотеки
  • примеры
  • коды
  • некий инструментарий для отладки
  • реализующая бизнес-логика

API
application programming interface
описание интерфейса чего-либо
рецепт блюда

Набор правил, по которым что-то должно работать

Рубрики
ООП

ООП построено на трёх основных концепциях

  • инкапсуляция
  • наследование
  • полиморфизм
Рубрики
ООП

ООП имеет два основных понятия

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

Объект
конкретный представитель класса или экземпляр класса
каждая характеристика имеет значение
Объект с Имя=Вася

Рубрики
5. Dependency inversion principle SOLID

ПРИМЕР Музыкальное приложение

5. Dependency inversion principle
Принцип инверсии зависимости

создаем объект — экземпляр класса яндекс музыка API работаем с этим экземплярам в разных местах приложения — вызываем метод

создаем Yandex класс
музыку мы будем получать из яндекс музыки
class YandexMusicApi {
 get(){}
}
const MusicApp = () ={
  const API = new YandexMusicApi()
  API.get()
}
Рубрики
5. Dependency inversion principle SOLID

Введение

5. Dependency inversion principle
Принцип инверсии зависимости

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

Рубрики
4. Interface segregation principle SOLID

ПРИМЕР класс клиент-сервер

4. Interface segregation principle
Принцип разделения интерфейса

СервисСайт рендериг приложение с клиентом и сервером

const client = () => { }
const server = () => { }
Рубрики
4. Interface segregation principle SOLID

Введение

4. Interface segregation principle
Принцип разделения интерфейса

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

  • тесно связан с первым принципом (ответственность)
  • тесно связан с третьим принципом (подстановка)

разбивать толстые интерфейсы (программные сущности)

  • интерфейсы маленькие (узко-специализированные)
  • интерфейсы решают одну задачу

Положительность в принципе

  • избавляем программные сущности от методов, которые они не используют
  • получаем более предсказуемую работу
  • код становится менее связанным в модулях и легче поддерживается
Рубрики
3. Liskov Substitution Principle SOLID

ПРИМЕР класс база данных

класс база данных и есть классические операции
class Database {
 connect(){} подключение
 read(){} чтение каких-то данных
 write(){} запись каких-то данных
 joinTables(){} добавляем метод по объединению таблиц
}
класс реляционная база данных MySQLDataBase в которой все данные хранятся в форме связанных таблиц (уместен joinTables)
расширяет поведение базового класса Database

class MySQLDataBase extends Database{
 connect(){}
 read(){}
 write(){}
 joinTables(){}
}

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

класс не реляционная база данных MongoDB и там данных хранятся в форме коллекции и документов
там таблиц нет и объединять таблицы мы не можем
class MongoDatabase extends Database {
 connect(){}
 read(){}
 write(){}
 переопределяем метод и выбрасываем ошибку
 joinTables(){error}
}

при правильном проектировании было уместнее сделать сделать следующие.
Мы создаём ещё один класс, который наследует от базового. Из него мы удаляем метод joinTables

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

class Database {
 connect(){} подключение
 read(){} чтение каких-то данных
 write(){} запись каких-то данных
 joinTables(){}
}

специфичные методы для конкретного типа базы данных мы вынесли в отдельные классы

class SQLDataBase extends Database{
 connect(){}
 read(){}
 write(){}
 joinTables(){}
}
class NOSQLDatabase extends Database {
 connect(){}
 read(){}
 write(){}
 createIndex(){}
}

class MySQLDataBase extends SQLDatabase{
 connect(){}
 read(){}
 write(){}
 joinTables(){}
}
class MongoDatabase extends NOSQLDatabase {
 connect(){}
 read(){}
 write(){}
 createIndex(){}
 mergerDocuments(){}
}

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

function startApp(database: Database){
 database.connect();
}
startApp(new MongoDatabase);
startApp(new MySQLDatabase);
Рубрики
3. Liskov Substitution Principle SOLID

Введение

3. Liskov Substitution Principle
Принцип подстановки Барбары Лисков

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