SOLID
👆 SOLID - одни из самых известных принципов для написания качественного ООП кода. Насколько бы простыми и интуитивно понятными они не казались - в своем конечном варианте они были сформулированы только в 2000м году Робертом Мартином.
👉 Я тоже считаю считаю их очень важными для написания качественного читаемого кода. Читаемость (или читабельность) - это вообще один из самых важных факторов вашего кода - ведь будь то большой проект или маленький пет-проект - вам приходится именно читать код в разы больше, чем его писать. Любой баг, любая фича, любой вопрос - это повод к тому, чтобы сесть и прочитать кусок кода.
👇 В первый раз когда я про это прочитал и осознал - у меня буквально перевернулся взгляд на то, как писать код, почему его надо писать по-другому. Итак:
🪑 SRP (Single Responsibility Principle) - Принцип единственной ответственности. О том, что каждый класс должен отвечать за одну и только одну функциональность.
🚪 OCP (Open-Closed Principle) - Принцип открытости закрытости. О том, что классы должны быть открыты для расширения, но закрыты для изменения.
👨👩👧 LSP (Liskov Substitution Principle) - Принцип подстановки Барбары Лисков. О правильном поведении при наследовании.
🧩 ISP (Interface-Segregation Principle) - Принцип разделения интерфейса. О том, как правильно использовать интерфейсы и абстракции.
🔃 DIP (Dependency Inversion Principle) - Принцип инверсии зависимостей. О правильной организации зависимостей на разных уровнях программы.
💬 В следующих постах периодически буду раскрывать подробнее что тут происходит.
#SOLID #Principles
👆 SOLID - одни из самых известных принципов для написания качественного ООП кода. Насколько бы простыми и интуитивно понятными они не казались - в своем конечном варианте они были сформулированы только в 2000м году Робертом Мартином.
👉 Я тоже считаю считаю их очень важными для написания качественного читаемого кода. Читаемость (или читабельность) - это вообще один из самых важных факторов вашего кода - ведь будь то большой проект или маленький пет-проект - вам приходится именно читать код в разы больше, чем его писать. Любой баг, любая фича, любой вопрос - это повод к тому, чтобы сесть и прочитать кусок кода.
👇 В первый раз когда я про это прочитал и осознал - у меня буквально перевернулся взгляд на то, как писать код, почему его надо писать по-другому. Итак:
🪑 SRP (Single Responsibility Principle) - Принцип единственной ответственности. О том, что каждый класс должен отвечать за одну и только одну функциональность.
🚪 OCP (Open-Closed Principle) - Принцип открытости закрытости. О том, что классы должны быть открыты для расширения, но закрыты для изменения.
👨👩👧 LSP (Liskov Substitution Principle) - Принцип подстановки Барбары Лисков. О правильном поведении при наследовании.
🧩 ISP (Interface-Segregation Principle) - Принцип разделения интерфейса. О том, как правильно использовать интерфейсы и абстракции.
🔃 DIP (Dependency Inversion Principle) - Принцип инверсии зависимостей. О правильной организации зависимостей на разных уровнях программы.
💬 В следующих постах периодически буду раскрывать подробнее что тут происходит.
#SOLID #Principles
sOlid
OCP или Open-Closed Principle довольно интересная штука. На моей практике этот принцип в целом довольно редко применяется. Возможно это связано с довольно быстрым современным миром и быстро меняющимися требованиями в agile-процессах. Тем не менее умственными упражнениями такое вполне достижимо и в реальной разработке можно (и нужно) к этому стремиться.
👉 OCP - это принцип при котором классы закрыты для изменений, но открыты для расширений.
💥 Итак, идея вот в чем. Представьте что архитектура и код в вашем проекте имеют такое свойство, что вы не можете никогда менять старый код ради нового функционала - только писать новое поведение, новые классы и т.д. Разумеется, ради исправления реальных багов, старый код можно править. А ради изменения поведения каких то классов вам нужно будет заново имплементировать какой-либо интерфейс и написать это поведение с нуля. К чему это приведет? Это приведет к тому что весь код работающий в вашем проекте будет без багов и проблем (разумеется - если ваши интерфейсы протестированы).
☝️ Более того, стремление к реализации такого принципа приведет к более лаконичной и аккуратной архитектуре - представьте, что перед стартом задачи вам скажут, что после релиза вы не сможете изменять существующие строки в классах проекта, а только дописывать новые методы и классы. Вы сразу более активно начнете пользоваться интерфейсами, абстракциями, сделаете ваши классы низкосвязанными - ведь вам не захочется в будущем переписывать весь проект ради реализации новой прихоти менеджера из-за очень высокой связности классов внутри проекта.
🧠 Попробуйте взглянуть на вашу последнюю задачу или реализованный модуль с точки зрения OCP - сможете ли вы изменить поведение части бизнес-логики не внося изменения в основные файлы? Сможете ли реализовать дополнительную функциональность не добавляя
#SOLID #Principles #OCP
OCP или Open-Closed Principle довольно интересная штука. На моей практике этот принцип в целом довольно редко применяется. Возможно это связано с довольно быстрым современным миром и быстро меняющимися требованиями в agile-процессах. Тем не менее умственными упражнениями такое вполне достижимо и в реальной разработке можно (и нужно) к этому стремиться.
👉 OCP - это принцип при котором классы закрыты для изменений, но открыты для расширений.
💥 Итак, идея вот в чем. Представьте что архитектура и код в вашем проекте имеют такое свойство, что вы не можете никогда менять старый код ради нового функционала - только писать новое поведение, новые классы и т.д. Разумеется, ради исправления реальных багов, старый код можно править. А ради изменения поведения каких то классов вам нужно будет заново имплементировать какой-либо интерфейс и написать это поведение с нуля. К чему это приведет? Это приведет к тому что весь код работающий в вашем проекте будет без багов и проблем (разумеется - если ваши интерфейсы протестированы).
☝️ Более того, стремление к реализации такого принципа приведет к более лаконичной и аккуратной архитектуре - представьте, что перед стартом задачи вам скажут, что после релиза вы не сможете изменять существующие строки в классах проекта, а только дописывать новые методы и классы. Вы сразу более активно начнете пользоваться интерфейсами, абстракциями, сделаете ваши классы низкосвязанными - ведь вам не захочется в будущем переписывать весь проект ради реализации новой прихоти менеджера из-за очень высокой связности классов внутри проекта.
🧠 Попробуйте взглянуть на вашу последнюю задачу или реализованный модуль с точки зрения OCP - сможете ли вы изменить поведение части бизнес-логики не внося изменения в основные файлы? Сможете ли реализовать дополнительную функциональность не добавляя
IF-ы, а лишь только добавляя новые методы и классы? В следующей задаче попробуйте найти решение такое, чтоб любое будущее изменение функциональности требовало вносить минимальные изменения в существующие классы.#SOLID #Principles #OCP
FIRST принципы
Кроме уже всем известных прицнипов #SOLID есть и очень важный набор принципов #FIRST. Это принципы про написание тестов. В основном юнит тестов, но можно сюда добавить и интеграционные.
Итак, тесты должны быть:
Fast - быстрыми
Independent - независимыми
Repeatable - повторяемыми
Self-validated - самопроверяемыми (т.е. результатом теста может быть только “пройден” или “не пройден”)
Timely - вовремя написанными, в идеале до написания продакшн кода (TDD подход)
Если написанный юнит-тест не удовлетворяет одному из первых четырех принципов - это повод присмотреться правильный ли это юнит-тест.
Кроме уже всем известных прицнипов #SOLID есть и очень важный набор принципов #FIRST. Это принципы про написание тестов. В основном юнит тестов, но можно сюда добавить и интеграционные.
Итак, тесты должны быть:
Fast - быстрыми
Independent - независимыми
Repeatable - повторяемыми
Self-validated - самопроверяемыми (т.е. результатом теста может быть только “пройден” или “не пройден”)
Timely - вовремя написанными, в идеале до написания продакшн кода (TDD подход)
Если написанный юнит-тест не удовлетворяет одному из первых четырех принципов - это повод присмотреться правильный ли это юнит-тест.