~ Принципы S.O.L.I.D. ~

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

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

Эта статья включает в себя все ключевые моменты и концепции, которые вы должны знать о принципах SOLID и о том, как шаг за шагом адаптировать их к вашим собственным проектам.

Так что готовьте чашечку кофе или чая и приступим! 🤗

Обзор

Принципы SOLID — это соглашение о кодировании, которое должны понимать все разработчики, чтобы точно проектировать программное обеспечение и избегать плохого проектирования. Его представил Роберт С. Мартин, и теперь он используется во всем спектре объектно-ориентированного проектирования.

Зачем использовать принципы SOLID?

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

Итак, мы должны применять принципы SOLID.

Хотя у принципов есть много преимуществ.

✔️ Доступность

✔️ Расширяемость

✔️ Это значительно упрощает обслуживание, тестирование и расширение программы.

✔️ Код более гибкий, логичный и легко читаемый при правильном использовании.

Что такое принципы SOLID?

S.O.L.I.D — это 5 объектно-ориентированных принципов, которым следует следовать при разработке программного обеспечения.

SOLID означает,

☆ Принцип единой ответственности

☆ Принцип открытия-закрытия

☆Принцип замены Лисков

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

☆Принцип инверсии зависимостей

Давайте рассмотрим эти концепции один за другим.🧐

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

“ У класса должна быть одна и только одна причина для изменения, а это означает, что у класса должна быть только одна работа.

Преимущества принципа единой ответственности

☛ Когда программа содержит множество классов, каждый из которых придерживается этой идеи, приложение становится более удобным и понятным.

☛ Качество кода приложения выше, что приводит к меньшему количеству проблем.

☛ Новые участники легко адаптируются и могут сразу начать вносить свой вклад.

☛ Значительно проще тестировать и писать тестовые случаи.

Пример

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

Для приведенного выше примера у студенческого класса есть 4 отдельные обязанности. это getStudentName, getRegisterNo , getCourse и save в отдельных классах. Каждая отдельная функциональность передается студенческому классу.

Обзор😎

(02) Принцип открытого-закрытого (OCP)

«Объекты или сущности должны быть открыты для расширения, но закрыты для модификации»

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

· Закрыто для модификации — расширение поведения модуля не приводит к изменению исходного или двоичного кода модуля, поэтому он закрыт для модификации. Бинарная исполняемая версия модуля, будь то в подключаемой библиотеке, DLL или Java.jar, остается неизменной.

Преимущества открытого-закрытого принципа

Ниже приведены некоторые преимущества использования парадигмы открытого-закрытого кода в вашем коде:

☛ Расширяемость чрезвычайно проста

☛ Легче управлять

☛ Не нужно менять рабочий код

☛ Нет необходимости чинить сломанные блоки

☛ Создавайте код, допускающий изменения с течением времени.

☛ Гибкость

Пример

В приведенном выше примере класс Inventory использует класс Goods. Классы обуви, Шляпа и Одежда реализовали интерфейс товаров. Если мы хотим добавить больше персонажей в инвентарь, мы можем реализовать эти классы через интерфейс. Вместо использования интерфейса мы также можно использовать абстрактные классы. Мы не можем изменить детали внутреннего оборудования.

Обзор😎

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

«Каждый подкласс/производный класс должен иметь возможность заменить родительский/базовый класс»

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

Преимущества принципа замещения Лисков

☛ поощряет повторное использование кода

☛ расширять свои базовые классы без изменения их поведения

Пример

Класс Rectangle — это родительский класс, а класс square — дочерний. Класс Square наследует класс Rectangle. Класс Square также может переопределять методы класса Rectangle. Но класс Square должен выполнять базовую функциональность родительского класса, а также иметь только реализованные методы.

Давайте посмотрим на изображение ниже,

Здесь мы не можем наследовать свойства класса Autopilot через класс train. Потому что поезд не может поворачивать налево и направо, хотя машина может.

Обзор 😎

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

«Клиентов нельзя заставлять внедрять методы, которые они не используют»

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

Давайте рассмотрим простой сценарий, в котором это произошло.

Пример

В чем проблема в примере?🙄

Как видите, мы не можем использовать метод fly для класса car. Но родительский класс автомобиля и класс самолета должны иметь метод «летать». Они называются толстыми интерфейсами. Группируйте методы в разные интерфейсы, каждый из которых обслуживает разные наборы клиентов.

Итак, что мы можем сделать, чтобы избавиться от этой проблемы? 🤗

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

Обзор 😎

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

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

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

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

Давайте посмотрим на пример,

Пример

Вот три класса, названные Project (высокий уровень), BackEndDeveloper (нижний уровень) и FrontEndDeveloper (нижний уровень).

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

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

Что мы можем сделать для совместимости с этим? 🤔

Решение, 😎

Чтобы избавиться от этой проблемы, мы должны создать новый интерфейс. Это может быть интерфейс или абстрактный класс.

Я создал интерфейс с именем Developer и реализовал метод develop().

Затем после этого этот метод разработчика также должен быть реализован в модулях более низкого уровня. (FrontEndDeveloper и BackEndDeveloper) Внутри метода разработчика мы можем добавить методы записи отдельно.

Вот так 👇 👇 👇

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

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

Таким образом, мы также достигаем 2-го ограничения в принципе инверсии зависимостей.

Обзор 😎

Подход к решениям . .

Как мы можем достичь этого решения наилучшим возможным способом?

🟡 Продумайте проблему

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

🟡 Разделяй и властвуй

  • Разделите проблему на более мелкие задачи и сделайте ее управляемой и понятной. Затем попытайтесь найти идеальный баланс между приоритетом и ясностью (менее сложным, легко понятным).

🟡 ПОЦЕЛУЙ (будь проще и глупее)

  • Концепция «будь проще, глупец» (KISS) — это принцип проектирования, утверждающий, что простые конструкции работают лучше, чем сложные. Аббревиатура KISS не означает невежество. Принцип KISS уменьшает или устраняет ползучий функционализм, системные сбои и другие ИТ-проблемы.

🟡 Учитесь, особенно на ошибках

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

🟡 Всегда помните, зачем существует программное обеспечение

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

🟡Помните, что вы не пользователь

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

Обзор 😎

Внедрение решений...

При внедрении разработанного решения необходимо помнить о некоторых рекомендациях.

🟣 ЯГНИ (Вам это не понадобится)

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

🟣 СУХОЙ (не повторяйтесь)

- Дублирование в логике должно быть уменьшено за счет абстракции, тогда как дублирование в процессе должно быть устранено за счет автоматизации, в соответствии с философией Don’t Repeat Yourself (DRY). Дублирование — пустая трата времени. Добавление лишнего кода в кодовую базу увеличивает объем усилий, необходимых в будущем для расширения и поддержки проекта.

🟣 Примите абстракцию

- Убедитесь, что ваша система работает правильно, не зная деталей реализации каждого компонента.

🟣 DRITW (Не изобретайте велосипед)

- Многие люди скажут: «Не изобретайте велосипед», когда приступят к задаче, имея в виду, что некоторые основополагающие аспекты задачи не нужно изменять или воспроизводить, так как это будет пустой тратой времени. Возможно, кто-то уже решал ту же проблему. Используйте это.

🟣 Пишите код, который хорошо справляется с одной задачей

- Отдельный фрагмент кода, который делает одно и то же очень хорошо. Не пытайтесь написать волшебный код, который сделает все

🟣 Отлаживать сложнее, чем писать код

  • Читаемый код лучше, чем компактный код. Сделайте его максимально читабельным.

🟣 Кайдзен (Оставьте лучше, чем когда нашли)

- Исправить не только ошибку, но и код вокруг нее. Временное исправление не поможет, если реальная проблема связана с дизайном.

Обзор 😎

Практика...

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

Это рекомендации, которым вы можете следовать,

🟠 Модульное тестирование

  • UNIT TESTING – это разновидность тестирования программного обеспечения, при котором проверяются отдельные программные модули или компоненты. Цель состоит в том, чтобы убедиться, что каждая единица программного кода работает правильно. Модульное тестирование выполняется разработчиками на протяжении всего этапа разработки (кодирования) приложения. Модульные тесты используются для изоляции части кода и проверки его правильности. Отдельный метод, процедура, операция, компонент или объект могут рассматриваться как единица.

🟠 Качество кода

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

🟠 Обзор кода

- Проверка кода — лучший способ улучшить качество кода. Это цель — улучшить код, а не критиковать разработчика.

Экспертные проверки, обзоры лидов и парное программирование — вот некоторые методы проверки кода.

🟠 Контроль версий (VCS)

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

- Git - самый популярный. Хостинг-провайдеры — Github, Bitbucket и GitLab.

🟠 Непрерывная интеграция (CI/CD)

- Непрерывная интеграция - это практика разработки. Разработчикам необходимо возвращать код в общий репозиторий несколько раз в день. Каждая проверка проверяется автоматизированной сборкой. Это позволяет разработчикам обнаруживать проблемы на ранней стадии и устранять их без задержки.

===================================

~ JavaScript ~

JavaScript – это экспрессивный, облегченный язык программирования. Он предназначен для разработки сетецентрических систем. Он работает в паре с Java и дополняет его. Поскольку JavaScript переплетается с HTML, его невероятно просто использовать. Это бесплатное и кроссплатформенное приложение.

Зачем использовать JavaScript

◽️ Единственный язык программирования, родной для веб-браузера, — это JavaScript.

◽️ Самый распространенный язык программирования — JavaScript.

◽️ Чтобы начать, вам нужна небольшая сумма денег.

◽️ Это приятный язык для изучения.

Возможности Js

🔹 Однопоточный язык.

- Программы JavaScript выполняются с использованием одного потока. Хотя есть способы создавать новые потоки, JavaScript считается однопоточным языком.

🔹 JavaScript асинхронный

- Не ожидает завершения операций ввода-вывода (неблокирующий ввод-вывод)

- JS имеет систему обработки событий, которая управляет асинхронными операциями.

- Из-за природы НИО.

🔹 Динамически типизированный

- Он определяет типы переменных, порядок и т. д. во время выполнения.

🔹 Мультипарадигма

- Js поддерживает ООП, а также функциональное программирование.

🔹 Стандарты ECMA соблюдаются JS.

Если мы рассмотрим Java и JavaScript, между этими двумя языками есть некоторая разница. Давайте посмотрим ,

Теперь мы перейдем к наиболее важным аспектам JavaScript. В этой части мы обсудим основные принципы JS. Это классы/объекты и прототипы, как действует this, строгая нотация, закрытие функций и, наконец, обратные вызовы и промисы.

Итак, давайте перейдем к ним один за другим 😉

🔴 Классы и объекты

На изображении выше вы можете ясно понять, что такое класс и объект. ,

Класс —> Шаблон для объекта . Чертеж или прототип, из которого создаются объекты.

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

✔️ Когда функция используется с ключевым словом «новое», эта функция действует как класс.

  • Когда используется ключевое слово «новое», создается новый объект, и ему присваивается значение «этот» на время вызова функции конструктора.

✔️ Функция конструктора — это просто еще одна функция.

✔️ Еще один способ создания объекта — использование литералов объектов ("{}"). Эти объекты считаются одноэлементными.

✔️JavaScript поддерживает статические методы и переменные.

Eg:-

Мы можем создать статическую переменную count и статический метод numShapes. Их можно использовать без необходимости создавать новый экземпляр класса.

И на них ссылаются, используя имя класса «Shape».

🔴 Прототипы

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

✔️ Прототип JavaScript

Мы пытаемся получить доступ к свойству прототипа функции-конструктора Person в приведенном выше примере.

Поскольку атрибут прототипа теперь пуст, он отображает пустой объект…{..}

✔️ Наследование прототипа

Прототип можно использовать для добавления свойств и методов в функцию-конструктор в JavaScript. Свойства и методы прототипа передаются объектам. В качестве примера,

Мы добавили новое свойство gender в метод конструктора Person в приведенном выше приложении, используя:

Гендерное свойство объектов person1 и person2 наследуется от свойства прототипа функции-конструктора Person.

Примечание 🤞

  • В JavaScript объект-прототип используется при создании объектов, для наследования и добавления методов в класс JavaScript.
  • Из-за гибкости JavaScript существует несколько способов создания классов, а также их расширения.
  • - Рекомендуется использовать прототипы.

✔️ Добавить методы в функцию-конструктор с помощью прототипа

Функция, которая используется для создания объектов, называется функцией-конструктором. Прототип функций используется для наследования свойств экземплярам объекта.

Давайте посмотрим на пример ниже, 👇

новый метод greet добавлен в функцию-конструктор Person с использованием прототипа.

✔️ Изменение прототипа

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

В качестве примера,

✔️ Связывание прототипов JS

Когда объект пытается получить доступ к свойству, которое находится как в функции-конструкторе, так и в объекте-прототипе, объект использует свойство функции-конструктора.

В качестве примера,

Имя свойства указывается в функции-конструкторе, а также в свойстве прототипа функции-конструктора в приведенной выше программе.

Когда программное обеспечение запускается, person1.name проверяет, есть ли свойство с именем name в функции-конструкторе. Объект получает значение из свойства name функции-конструктора, которое имеет значение «Raveena».

Когда программное обеспечение запускается, person1.age проверяет, есть ли свойство с именем age в функции-конструкторе. Поскольку в функции-конструкторе отсутствует свойство age, программа проверяет объект-прототип функции-конструктора, который наследует свойства объекта-прототипа (если они доступны).

● Экземпляр объекта также имеет прототип. По сути, это экземпляр объекта, из которого создается объект. Объект «__proto__» — это место, где объект получает свои свойства, унаследованные от него.

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

🔴 "это" ключевое слово в JavaScript

› Маловероятно, что в других языках JavaScript ключевое слово this действует иначе.

› Внутри объекта «это» относится к самому объекту.

› В глобальном контексте «это» относится к глобальному объекту (в браузере это объект окна). Это поведение будет изменено в строгом режиме.

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

› Такое поведение очень заметно при обратном вызове и закрытии.

Eg :-

🔴 Строгая запись

  • Ограниченный режим JavaScript.
  • Цель: упростить написание безопасного JavaScript.
  • Строгий режим превращает плохие практики в JavaScript в ошибки.
  • Не позволяйте разработчику использовать синтаксис, который станет недействительным в будущих разработках JavaScript.
  • Например, он не позволяет создавать переменные без ключевого слова var (переменная должна быть объявлена).
  • Другим примером может быть то, что он перестанет ссылаться на объект окна как «это» из внешних экземпляров объекта.

Преимущества использования строгого режима

  • Помогает в создании более чистого кода
  • Неявные ошибки теперь рассматриваются как настоящие ошибки, и выдается сообщение об ошибке.
  • Упрощает создание «безопасного» JavaScript

Eg :-

Код внутри функции будет в строгом режиме, если вы используете «use strict»; внутри него.

использовать строгие правила; используется внутри метода hello() в приведенной выше программе. В результате строгий режим применим только внутри функции.

Как видите, myVariable используется без объявления в начале программы.

Вы не можете использовать переменную, не объявив ее внутри функции, если вы объявили «use strict» в начале программы.

В качестве примера,

Блочные операторы с фигурными скобками не зависят от строгого режима.

🔴 Закрытие

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

Давайте посмотрим на пример: -

name — это локальная переменная, созданная с помощью init(), а displayName — это функция, созданная с помощью init() (). Функция displayName() — это внутренняя функция, определенная внутри init(), которую можно использовать только в теле метода init(). Функция displayName() не имеет собственных локальных переменных. Однако, поскольку внутренние функции имеют доступ к переменным внешних функций, displayName() может получить доступ к имени переменной, определенной в родительской функции, init().

🔴 Обратный звонок и обещания

  • JavaScript является асинхронным. Все операции ввода-вывода в JavaScript реализованы как асинхронные по своей природе.
  • Причина этого в том, что JavaScript является однопоточным языком, если операции ввода-вывода удерживают поток до тех пор, пока он не завершится. JavaScript не будет хорошо работать как язык программирования.
  • Но асинхронная операция создает трудности, когда нам нужно выполнять синхронную обработку с использованием данных.
  • Это решается с помощью обратных вызовов и промисов.
  • Обратный вызов — это функция, которая передается асинхронной задаче, и по завершении функция будет выполнена.
  • Обещание — это объект, возвращаемый асинхронными задачами. У Promise есть свойства для синхронной работы с асинхронными операциями.
  • Вложенные обратные вызовы, переданные в последовательность асинхронных задач, называются «адом обратных вызовов».
  • Объект Promise был введен для решения этой проблемы.
  • Объект Promise имеет набор свойств, методов и механизм цепочек для удобной обработки сложных асинхронных задач.

Обратный звонок -›

Функции — это объекты в JavaScript. В результате мы можем отправлять объекты в качестве параметров функциям.

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

Рассмотрим следующую функцию обратного вызова:

Мы бы получили следующий вывод, если бы это был код синхронизации.

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

Обещания -›

Давайте создадим обещание:

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

Мы используем then() для разрешения и catch() для отклонения приведенной выше конструкции Promise.

~ Контроль версий ~

Что такое контроль версий?

«Управление несколькими версиями одной и той же единицы информации»

● Управление изменениями в источнике.

● Изменения идентифицируются с помощью номера версии.

● Каждая редакция имеет свою временную метку, а также имя человека, внесшего изменение.

● Версии можно восстанавливать, сравнивать и объединять.

Почему контроль версий так важен?

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

Преимущества использования контроля версий.

  • Будьте в курсе событий и следите за тем, чтобы все в вашей команде работали над одной и той же версией.
  • Улучшается видимость.
  • Помогает командам со всего мира в сотрудничестве.
  • Повышает скорость доставки продуктов.
  • Упрощенное резервное копирование и централизованное хранилище исходного кода.
  • Легкая совместная разработка.
  • Обзор изменений, внесенных в файл.
  • Контроль доступа.
  • Разрешающий конфликт.
  • Он сообщает нам, кто, что, когда и почему были сделаны модификации.

Типы контроля версий?

⚇ Системы контроля версий на локальном уровне

⚇ Централизованные системы контроля версий

⚇ Системы контроля версий в распределенной среде

Примеры

Терминология

● Репозиторий

- Центральное место, где хранятся все файлы. Обычно каталог с набором файлов.

● Багажник

- Также называется основной ветвью. Именно здесь размещается наиболее стабильный код, который называется производственным кодом.

● Этап

- Пометить файлы для отслеживания изменений.

● Подтвердить

– Создайте моментальный снимок изменений, вносимых в файлы.

● Филиал

- Копия основной ветки, взятой в данный момент. Все разработки функций и исправления ошибок будут выполняться в ветке. Обычно допускается иметь несколько ветвей одновременно.

● Оформить заказ

- Отметить/разблокировать файл для изменения.

● Объединить

- Объединение веток вместе для обновления главной ветки.

● Конфликт слияния

  • Конфликты слияния возникают при слиянии файла, который был изменен в двух разных ветвях или местах. Изменения, препятствующие другим изменениям.

- Git-

  • Самая популярная система контроля версий.
  • Распределенная система контроля версий.

Клиенты получают полный клон исходного кода. В аварийной ситуации полный исходный код вместе со всей историей может быть восстановлен с клиента.

  • Бесплатный и с открытым исходным кодом.
  • Несколько веток и тегов.

Ветки функций, ветки ролей (производство).

  • Быстрее по сравнению с другими системами (работает на ядре Linux и написан на C).
  • Поддержка нескольких протоколов ( HTTP, SSH )
  • Промежуточная область, локальные коммиты и тайники.

- Промежуточная область — пометить файлы для фиксации.

- Локальная фиксация — локальная фиксация кода без отправки в удаленную ветку.

  • Stashing — Храните изменения файлов в Stash и применяйте их позже.

Команды Git

🔸 Git инициировать

- Новый репозиторий Git создается с помощью команды git init. Его можно использовать для преобразования неверсионного проекта в репозиторий Git или для создания нового репозитория с нуля.

🔸 Гит-клон

- Создайте новый каталог из клонированного источника.

🔸 Git добавить

- Добавить содержимое файла в индекс.

🔸 Git-стадия

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

🔸 Git коммит

- Изменения в репозитории должны быть записаны.

🔸 Гит пуш

- Удаленные ссылки, а также связанные с ними объекты должны быть обновлены.

🔸 Git Pull

- Используется для обновления локальной версии репозитория с удаленного

🔸 Git ветка

- Создает новую ветку для существующего репозитория

🔸 Git-касса

- Навигация между ветвями, созданными веткой git.

🔸 Git слияние

- Взять независимую линию разработки, созданную веткой git, и интегрировать их в одну ветку.

~ NoSQL ~

База данных NoSQL — это нереляционная система управления данными, не требующая схемы. Он не требует каких-либо объединений и прост в масштабировании. База данных NoSQL в основном используется для распределенных хранилищ данных с большими требованиями к хранению данных. И большие данные, и веб-приложения реального времени используют NoSQL. Каждый день такие фирмы, как Twitter, Facebook и Google, например, накапливают гигабайты пользовательских данных.

Функции NoSql

· Реляционная модель никогда не используется в базах данных NoSQL.

· Никогда не следует использовать таблицы с плоскими записями с фиксированными столбцами.

· Работа с большими двоичными объектами или автономными агрегатами.

· Нормализация данных и объектно-реляционное отображение не требуются.

· Отсутствуют расширенные функции, такие как языки запросов, планировщики запросов, соединения ссылочной целостности или совместимость с ACID.

Типы баз данных NoSql

● На основе пары "ключ-значение"

● График, ориентированный на столбцы

● На основе графиков

● Ориентированность на документы

Разница между SQL и NoSql

Преимущества NoSQL

✯ Можно использовать как первичный или аналитический источник данных.

✯ Емкость для больших данных

✯ Нет единых точек отказа.

✯ Репликация проста.

✯ Нет необходимости в отдельном слое кэширования.

✯ Он предлагает высокую производительность, а также горизонтальную масштабируемость.

✯ Способен одинаково хорошо обрабатывать организованные, полуструктурированные и неструктурированные данные.

✯ Объектно-ориентированное программирование — это тип программирования, который прост в использовании и адаптируется.

✯ Для баз данных NoSQL не требуется выделенный высокопроизводительный сервер.

✯ Поддерживаются основные языки и платформы разработчиков

✯ РСУБД сложнее внедрить.

Недостатки NoSQL

✯ Нет стандартных правил

✯ По мере роста объема данных становится все труднее сохранять уникальные значения, поскольку становится все труднее найти ключи.

✯ Не работает с реляционными данными

✯ Новые разработчики имеют крутую кривую обучения

✯ Варианты с открытым исходным кодом не так популярны, как раньше

Примеры

– Mongo DB –

MongoDB — это документно-ориентированная база данных NoSQL для хранения больших объемов данных. MongoDB использует коллекции и документы вместо таблиц и строк, как в традиционных реляционных базах данных. Документы состоят из пар ключ-значение, которые являются основной единицей данных MongoDB. Коллекции эквивалентны таблицам реляционных баз данных, поскольку они включают в себя наборы документов и функций. MongoDB — это база данных, впервые появившаяся в середине 2000-х годов.

В mongo DB также можно выполнять операции CRUD с нашим кодом,

Заключение 👋

Итак, пришло время прощаться. Сегодня мы изучили принципы SOLID в ООП и способы их применения, контроль версий, основы JavaScript, NoSQL и многое другое.

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

Спасибо, что нашли время, чтобы прочитать это!!! 🖐