⏩Принципы S.O.L.I.D
✳️Давайте быстро начнем со ссылки на ООП (принципы объектно-ориентированного программирования). Существует четыре принципа ООП: абстракция, инкапсуляция, наследование и полиморфизм. Принципы S.O.L.I.D находятся на вершине иерархии принципов ООП.
Итак, давайте взглянем на так называемые принципы S.O.L.I.D 😃
S.O.L.I.D представляет собой набор идей, которые при совместном использовании делают код более адаптируемым к изменениям. В своей книге «Принципы, паттерны и практики Agile» Боб Мартин и Мика Мартин предложили эти идеи — насколько захватывающие :*? 😕
Эти идеи также функционируют как язык, который мы также можем дополнительно использовать в обсуждениях с другими участниками группы или как часть огромной технической документации сообщества. 😀 Идеи S.O.L.I.D служат музой для создания сильных, расширяемых и удобных в сопровождении объектно-ориентированных программ.
📗Что называется S.O.L.I.D?
S: принцип единой ответственности (SRP)
O: открытый закрытый принцип
L: принцип подстановки Лискова
I: Принцип разделения интерфейсов
D: принцип инверсии зависимостей
1️⃣ S: Принцип единой ответственности (SRP)
"Каждому классу должна быть назначена одна обязанность".
Если посмотреть на это с другой стороны, класс должен создаваться, изменяться и поддерживаться только для одного внешнего вида.✅ Контейнер подобен классу. Мы можем заполнить его любым количеством наблюдений, полей и процедур. Наши классы станут плотными и востребованными, если мы будем следовать SRP, и каждый класс будет отвечать за конкретный предмет, работу или проблему.
Прежде чем мы углубимся в эту дизайнерскую идею, давайте ответим на самые важные вопросы: 😌
❌ Каковы преимущества его использования и что произойдет, если вы этого не сделаете?
Довод в пользу принципа единственной ответственности очевиден. Это делает вашу программу очень удобной для разработки и позволяет избежать непредвиденных последствий будущих улучшений. 😁
➡️Теперь давайте рассмотрим пример
Студент и учетная запись — это два существующих класса. Оба несут полную ответственность за обработку своего контента. Если мы хотим изменить статус Студента, нам не нужно обновлять класс Account и наоборот.✅ (https://howtodoinjava.com/best-practices/solid-principles/ )
2️⃣O: принцип открытого и закрытого
«Компоненты программного обеспечения всегда должны иметь возможность расширяться, но не изменяться».
Это означает, что классы приложений должны быть структурированы таким образом, чтобы, если другие программисты захотят изменить поток управления в соответствии с заданным сценарием в приложении, все, что им нужно сделать, это расширить класс и переопределить несколько функций. 😌
Если другие программисты не могут создать необходимую функциональность из-за ограничений класса ❌, нам следует рассмотреть возможность перезаписи класса. Более увлекательно ??
Общая концепция этого принципа фантастична. В нем содержится указание создать свой код таким образом, чтобы вы могли добавлять новые функции без изменения существующего кода.✅ Это исключает случаи, когда модификация одного из ваших классов требует корректировки всех связанных классы.
➡️Теперь давайте быстро перейдем к примеру
Dispatcher Servlet — это класс, предоставляемый фреймворком, который называется string. Для веб-программ, использующих Strings, этот класс отлично подходит в качестве фронт-контроллера. Мы можем развить способность желаемой функции, передав параметры инициализации. ⭕️
3️⃣L: принцип подстановки Лисков
"Определенные типы и их базовые типы должны быть взаимозаменяемыми"
Это означает, что классы, созданные коллегами-программистами путем расширения нашего класса, должны быть в состоянии вписаться в приложение без каких-либо сомнений. Это важно, когда мы возвращаемся к полиморфному поведению через наследование.✅
➡️Давайте перейдем к примеру
· Мы создадим базовый интерфейс Car с двумя методами, которые в целом должны быть доступны для всех автомобилей, и будем реализовывать методы. 😆
✅ Мы сейчас живем в поколениях, в которых есть электромобили.
Представляя автомобиль без двигателя, мы непреднамеренно меняем ход нашей программы. Это безошибочное нарушение принципа Лискова, и с ним справиться несколько сложнее, чем с двумя другими идеями.
4️⃣I: Принцип разделения интерфейсов
" Клиенты не должны быть обязаны использовать методы, которые они предпочли бы не использовать".
В результате более крупные терминалы должны быть разделены на более мелкие. Таким образом, мы можем гарантировать, что реализация классов должна быть сосредоточена только на тех методах, которые важны для них.
Давайте обсудим пример
🔴Java AWT обрабатывает события графического пользовательского интерфейса, отправляемые консолью и мышью, используя диспетчеры событий. Для каждого случая у него есть определенные классы слушателей. Все, что нам нужно сделать сейчас, это составить контроллеры для тех случаев, когда нам нужно обойтись. Ничего не должно быть закончено.
🔴 Любой может управлять любым событием в любой момент, найдя соответствующий слушатель и выполнив его.
5️⃣D: принцип инверсии зависимостей
"Используйте абстракции вместо конкретики"
Диссоциация программных модулей называется принципом инверсии зависимостей. В любом случае, вместо модулей низкого уровня, зависящих от модулей значительного уровня, и то, и другое будет зависеть от обсуждений.
Давайте перейдем к примеру
➕Правило дизайна корпуса уже давно используется в Spring Framework.
➕Все модули в Spring Framework представлены как отдельные части, которые можно использовать по отношению друг к другу, по сути добавляя условия в разные модули. Для решения этой зависимости используются внешние XML-документы.
➕Мы могли бы использовать эти безошибочно узнаваемые детали в других программных модулях, чем spring без особых усилий, потому что их линии настолько хорошо закрыты.
⏩Подход к решению
Какова наилучшая стратегия для достижения этого решения? 💯
✔️Рассмотрите проблему полностью
Запоминание проблемы снова и снова и понимание ее сути — самая важная сцена в решении проблемы. Перед проектированием неясные части следует сразу прояснить. Следует отметить, что очень важно задавать вопросы для сбора требований.
✔️Разделяй и властвуй — эффективная стратегия.
Здесь мы можем разделить массивную задачу на более мелкие задачи, что упрощает работу с каждой из частей. Приложите усилия для достижения идеального баланса между значимостью и прозрачностью.
✔️ ПОЦЕЛУЙ
Все должно быть на базовом уровне и не должно быть сложно. Решение должно быть максимально простым.
✔️Учитесь на своих ошибках, особенно.
Признание корректировок имеет решающее значение. Прогрессии должны быть продолжены, насколько это возможно, с ошибками. Сохранение договоренностей открытыми также гораздо важнее.
✔️Помните, для чего существует программное обеспечение.
Цель программного обеспечения должна быть ясной в сознании разработчика.
✔️ Всегда помните, что вы не являетесь пользователем.
Хотя разработчики являются техническими людьми, эти приложения в основном используются нетехническими людьми в реальном мире. Итак, мы должны помнить, что приложение всегда должно быть удобным для пользователя.
⏩Внедрение решения
Существуют некоторые важные и важные рекомендации по внедрению решения. Давайте обсудим дальше.
🔶ЯГНИ: «Вам это не понадобится»
Не пишите код, который в настоящее время не используется, если вы не уверены, что он будет полезен в будущем. Будущее изменится и непредсказуемо. Составьте код, который вам действительно нужен на тот момент, когда возникает проблема.
🔶СУХОЙ: Не повторяйтесь
Повторное использование реализованного кода очень важно и требует много времени.
🔶DRITW: "Не изобретайте велосипед"
Там может быть решение, которое предварительно решено кем-то другим. Извлекать из этого пользу тоже важно
🔶Поощряет абстракцию.
Убедитесь, что ваша структура работает должным образом, независимо от того, понимаете ли вы, как выполняется каждый сегмент части. Не зная, где защитить имя пользователя и секретное слово, класс User должен иметь возможность проверять клиентов.
🔶 Напишите код, который отлично справляется с конкретной задачей.
Отдельный фрагмент кода, который делает что-то определенное и хорошо работает во всех отношениях.
🔶Устранение неполадок сложнее, чем программирование.
Делаем код читабельным с помощью комментариев.
🔶Кайдзен
Исправьте проблему и код, который ее окружает.
⏩Практика написания кода
Практики — это набор рекомендаций или правил, которым мы должны следовать при написании кода.
✅Модульное тестирование
Одним из различных типов автоматизированного тестирования является модульное тестирование. Модульные тесты ограничивают и проверяют очень маленькие сегменты программы, противопоставляя их истинное поведение ожидаемому поведению. Во время модульного тестирования вы обычно не связываете свое приложение с внешними условиями, такими как информационные базы и файловая система. Модульное тестирование в конечном итоге сделает код пригодным для тестирования, создав расширяемую кодовую базу. Для инженеров существует стратегия подтверждения. Раннее обнаружение комбинированных проблем имеет основополагающее значение.
✅Качество кода
Код должен быть жизнеспособным всегда. А также он должен быть последовательным и эффективно обоснованным. Код должен придерживаться общепринятых процедур разработки, а также лучших языковых и пространственных практик. Код всегда должен распознавать вероятные неправильные ситуации. Программисты должны работать над представлением кода.
✅Проверка кода
Эта стратегия — лучший способ повысить качество кода. Цель состоит в том, чтобы обновить код, а не упрекать инженера-программиста. Это улучшает ваше исполнение, выявляя лучший ответ на вашу проблему.
✅Управление версиями
Контроль версий должен применяться ко всему коду. Это помогает разработчикам свободно обновлять и улучшать код, не опасаясь его поломки. Это позволило коду избавиться от любой единой точки отказа. Чтобы поддерживать базу кода в актуальном состоянии, мы можем использовать разные идентификаторы версий.
⏩JavaScript
JavaScript — это простой интерпретируемый язык. Планируется улучшение организационно-ориентированных приложений. Работает в паре с Java и дополняет ее. Поскольку JavaScript объединен с HTML, его чрезвычайно легко использовать. Допустимо использование и кросс-этапа. ✔️
🔎Основные возможности JavaScript
🔊 Язык сценариев легковесен. Он создан для обработки данных только в браузере.
🔊 JavaScript принимает во внимание динамическую типизацию, что означает, что тип не полностью установлен в камне ценой размещения.
- Обратимся к примеру:
номер переменной = HelloWorld;
Тип переменной будет определяться во время выполнения, а во время компиляции это не очень ясно.
🔊 Это однопоточный язык. Для решения проблем параллелизма существует пул потоков для одновременного выполнения двух операций ввода-вывода.
🔊Это асинхронный язык. Он не остается до тех пор, пока не будет выполнена одна операция ввода-вывода. Вместо этого он передает операции ввода-вывода в пул потоков при выполнении другого.
🔊 JavaScript лучше всего подходит для операций ввода-вывода, а не для операций процессора.
🔊 Это слабо типизированный язык, а также слабосвязанный.
🔊 JavaScript является независимым от платформы или универсальным, что, по сути, означает, что вы можете создать контент один раз и запускать его постоянно и когда угодно.
Давайте обсудим, как можно использовать JavaScript?
✨ Создание в Интернете и универсальных приложений
✨Создание серверных приложений и создание веб-серверов
✨ Внедрение инновационных элементов на веб-страницы
✨ За воспитание игровой разработки.
🔎Контрасты между Java и JavaScript
🔎Объявление функции в JavaScript
➰Здесь getName — это имя функции, и она не принимает никаких параметров. Функция getName() вызывается снаружи.
Переменная, называемая печатью, имеет тип данных const. Здесь переменная действует как функция. Console.log используется для печати. Функция getName() внутри Console.log ссылается на верхнюю функцию и возвращает Hello world.
🔎Классы и объекты
🔐Новое ключевое слово
Он используется для создания экземпляра объекта с помощью функции-конструктора. Когда вы используете оператор «новый» для вызова функции конструктора, происходят некоторые изменения.
🔑Будет создан пустой экземпляр
🔑Атрибут this изменен, чтобы ссылаться на только что созданный экземпляр.
🔑Когда функция-конструктор выдает не примитивный результат, возвращается вновь созданный объект.
🔐 Это ключевое слово
Независимо от того, созданы ли они с помощью конструктора или строгой документации, объекты JavaScript содержат атрибуты и методы. Термин «это» в JavaScript относится к объекту, который «владеет» кодом. Всякий раз, когда это используется в объекте, ценность экземпляра — это просто сам объект. Мы должны посмотреть, как их охарактеризовать.
🔐 Статические методы и переменные поддерживаются JavaScript.
Статические методы, которые имеют позицию с классом, а не событие этого класса, разрешены в JavaScript. В результате такие статические процедуры вряд ли будут вызываться вхождением. Доступ к классу осуществляется с помощью статических методов простым способом.
🔎Прототипы в JavaScript
· Каждой функции по умолчанию принадлежит объект-прототип
Объект-прототип — это особая форма перечисляемого элемента, к которому можно прикрепить дополнительные атрибуты и использовать их во всех экземплярах его функции-конструктора.
🔆Давайте проведем краткий обзор
Каждый объект, созданный с использованием знаков пунктуации нового улова или конструктора, имеет поле __proto__, которое ссылается на модельный объект той емкости, которая его создала. 📒
Давайте обратимся к коду диаграммы выше 📚
🔎Обратные вызовы в JavaScript
Функция обратного вызова — это функция, которая служит частью другой функции, а затем вызывается изнутри для выполнения задачи или события.
Обратные вызовы часто используются для продолжения выполнения кода после завершения асинхронного действия, они называются асинхронными обратными вызовами. ♻️ Методы обратного вызова выполняются внутри. В этом случае цикл point(), привязанный к концу гарантии после того, как гарантия удовлетворяет или отклоняет, является хорошим примером. Эта структура используется в нескольких современных веб-API. 🔖
⏩Контроль версий
Что относится к контролю версий?
Дисциплина мониторинга и поддержки модификаций кода программного обеспечения определяется как контроль версий, широко известный как контроль версий. Системы контроля версий (VCS) — это системное программное обеспечение, которое помогает командам разработчиков программного обеспечения отслеживать изменения исходного кода с течением времени. Системы контроля версий, по сути, помогают командам работать лучше и сильнее по мере роста числа платформ Интернета вещей. 👊
Теперь мы рассмотрим, зачем нам нужен контроль версий.
📙 Резервное копирование более простое, и есть встроенное хранилище исходного кода.
📙 Совместное улучшение является основным.
📙 Схема изменений, внесенных в запись.
📙 Контроль доступа.
📙 Цель вопроса
Я так увлечен JavaScript и разработкой программного обеспечения. Надеюсь больше блогов.
Удачного обучения!!
