1. Скажите пожалуйста принципы SOLID сейчас актуальны? Сейчас прям читал мнение, что это принципы из 80-х и сейчас уже не современно типа.
2. Если актуально, то можете ли вы сформулировать каждый принцип (по отношению к ООП) одним-двумя предложениями, т.е. коротко и ясно. Устал читать бесконечные размытые объяснения
Здравствуйте, Максим Рогожин, Вы писали:
МР>1. Скажите пожалуйста принципы SOLID сейчас актуальны? Сейчас прям читал мнение, что это принципы из 80-х и сейчас уже не современно типа.
Актуально, но не надо впадать в крайности и везде видеть их нарушение. Нередко, нужно просто нормально написать, чтобы работало. Не нужно видеть в каждом классе нарушение SRP. Нужно оценивать, стоит ли заморачиваться и проектировать класс так, чтобы все принципы выполнялись? Или может этот код на выброс? Или может завтра все должно быть готово и надо написать как можно быстрее? Или может этот код мы не планируем менять больше никогда (т.е. код из разряда написали — работает — забыли), а если и придется менять, то это будет легко сделать?
МР>2. Если актуально, то можете ли вы сформулировать каждый принцип (по отношению к ООП) одним-двумя предложениями, т.е. коротко и ясно. Устал читать бесконечные размытые объяснения
По-моему в книге Роберта Мартина эти принципы нормально объяснены.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Книги этой у меня нет, но я читал фрагменты — что-то мне не показалось что там коротко и ясно... но может просто с непривычки...
Посмотрите Вики, там они описаны вполне себе нормально. Или Теплякова почитайте (правда там на C#)...
Здравствуйте, Максим Рогожин, Вы писали:
МР>можете ли вы сформулировать каждый принцип (по отношению к ООП) одним-двумя предложениями, т.е. коротко и ясно. Устал читать бесконечные размытые объяснения
Можно — стараться организовывать код так чтоб не получилось что всё со всем связано. Стараться чтоб одна процедура/функция/метод/класс/модуль — одна решаемая задача. Если следовать дословно этим принципам, то можно удариться в другую степень маразма, т.е. ключевое слово — стараться следовать, но без фанатизма. Главная цель — упрощение кода, его структуры, чтоб можно быстрее было в нём разобраться и понять его проще.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Доброго времени суток!
МР>1. Скажите пожалуйста принципы SOLID сейчас актуальны? Сейчас прям читал мнение, что это принципы из 80-х и сейчас уже не современно типа.
На собеседованиях про SOLID исправно спрашивают, хотя в коде их нет. Наверное, надеются что ты их научишь.
МР>2. Если актуально, то можете ли вы сформулировать каждый принцип (по отношению к ООП) одним-двумя предложениями, т.е. коротко и ясно. Устал читать бесконечные размытые объяснения
Поздравляю, ты уже на голову выше своих коллег (я абсолютно серьёзно).
Single responsibility — тебе надо поменять что-то в этом модуле/классе, ты меняешь и всё работает как надо по-новому. Веера изменений в других модулях и классах нет.
Open/closed — надо реализовать новую фичу. Ты смотришь в код и видишь место, которое будто специально оставили для новой фичи. Ты пишешь там код и фича реализована.
Liskov substitution — ты можешь запустить программу без UI или заменить бд на оперативную память без особых усилий. Ты не дебажишь в продакшене, у тебя всё под контролем и легко воспроизводится на твоей машине.
Interface segregation — если соблюдается, то в хороший код очень сложно добавить плохой код. Нет чёрных ходов.
Dependency inversion — твой код выглядит как в учебниках по ООП — красивые объекты в вакууме. Однако этот код рабочий, в нём отражены понятия, о которых рассуждают аналитики и заказчики, когда вы обсуждаете проект. Проект не выглядит как набор скриптов, интегрирующих между собой набор фреймворков.
В реальном мире эти принципы соблюдаются очень редко. Для бизнеса они могут быть не важны, бизнес может приносить большие деньги и за счёт файла Excel с макросами. Эти принципы нужны, чтобы особо не напрягаться когда работаешь программистом за зарплату.
МР>2. Если актуально, то можете ли вы сформулировать каждый принцип (по отношению к ООП) одним-двумя предложениями, т.е. коротко и ясно.
1. Single Responsibility. Это когда в проекте сотни классов по 20 строк кода. И ты как дебил для реализации какой-нибудь фигни путешествуешь по сотням файлов, пытаясь разобраться, как это всё работает и взаимодействует.
2. Open Closed. Это когда в проекте куча наследования, притянутого за уши, а также куча костылей, помогающие этим иерархиям не развалиться. Зато разработчик расширял сущности (через наследование), но практически никогда не модифицировал их, разве что только для исправления бага.
3. Liskov Substitution. Это когда в проекте на C# есть свой собственный "фреймворк" для построения запросов к данным, практически аналогичный LINQ, построенный на LINQ, но в отличие от LINQ не нарушающий LSP. И ты как дебил вместо использования того, чем ты пользовался много лет, разбираешься со всеми костылями и особенностями внутреннего фреймворка.
4. Interface Segregation. Это когда в проекте практически каждый класс реализует 5-10 интерфейсов. При этом практически все интерфейсы реализуются только по одному разу.
5. Dependency Inversion. Это когда в проекте у каждого класса есть интерфейс, нигде в коде классы не используются напрямую, а объекты конструируются через фабрики, нет явных зависимостей, а все зависимости внедряются всякими разными способами, а на каждый простейший unit-test, который практически ничего не делает и ничего не тестирует, написано куча моков. И ты как дебил смотришь на это всё и нифига не можешь понять, как оно работает.
С моей точки зрения рациональная часть в этом такая:
1. Single Responsibility. Не пиши классы по 1000 срок кода, разбей на несколько.
2. Open Closed. Подумай, сколько мест в проекте тебе придётся изменить, если заказчик попросит ввести новый тип пользователя/счёта/платежа/продукта. Минимизируй количество этих мест, но не в ущерб ясности.
3. Liskov Substitution. Если в коде тебе приходится проверять тип переданного объекта, то, возможно, что-то ты делаешь не так.
4. Interface Segregation. Если у тебя реально есть класс, который делает "всё", то можно попытаться немного исправить это безобразие введением дополнительного слоя интерфейсов в зависимости от предполагаемых групп пользователей этого класса.
5. Dependency Inversion. По хорошему, пользователь объекта класса не должен знать, что для того, чтобы вызвать метод А, ему надо установить свойство Б в определённое магическое число, иначе вызов метода А сломается. Т.е. пользователю не следует знать, как именно метод А реализован, чтобы правильно воспользоваться им. «Зависимость на Абстракциях. Нет зависимости на что-то конкретное.» не следует читать, как "скорее вводи интерфейс". Сам по себе класс уже в 90% достаточная абстракция.
Здравствуйте, Vladek, Вы писали:
V>Single responsibility — тебе надо поменять что-то в этом модуле/классе, ты меняешь и всё работает как надо по-новому. Веера изменений в других модулях и классах нет.
Э... Нет.
V>Open/closed — надо реализовать новую фичу. Ты смотришь в код и видишь место, которое будто специально оставили для новой фичи. Ты пишешь там код и фича реализована.
Э... Нет...
V>Liskov substitution — ты можешь запустить программу без UI или заменить бд на оперативную память без особых усилий. Ты не дебажишь в продакшене, у тебя всё под контролем и легко воспроизводится на твоей машин
е.
Э... Нет...
V>Interface segregation — если соблюдается, то в хороший код очень сложно добавить плохой код. Нет чёрных ходов.
Э... Нет...
V>Dependency inversion — твой код выглядит как в учебниках по ООП — красивые объекты в вакууме. Однако этот код рабочий, в нём отражены понятия, о которых рассуждают аналитики и заказчики, когда вы обсуждаете проект. Проект не выглядит как набор скриптов, интегрирующих между собой набор фреймворков.
Ну, может быть, но эти слова могут быть отнесены ко всем принципам, а также и к DRY, KISS и YAGNI...
V>В реальном мире эти принципы соблюдаются очень редко. Для бизнеса они могут быть не важны, бизнес может приносить большие деньги и за счёт файла Excel с макросами. Эти принципы нужны, чтобы особо не напрягаться когда работаешь программистом за зарплату.
У кого — как... Все зависит от архитектора или от опыта разработчиков.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Доброго времени суток!
МР>1. Скажите пожалуйста принципы SOLID сейчас актуальны? Сейчас прям читал мнение, что это принципы из 80-х и сейчас уже не современно типа. МР>2. Если актуально, то можете ли вы сформулировать каждый принцип (по отношению к ООП) одним-двумя предложениями, т.е. коротко и ясно. Устал читать бесконечные размытые объяснения
Давно забыл, как расшифровывается SOLID, пришлось гуглить . Но общий здравый смысл присутствует.
1.Single responsibility
Как надо: поведение любого изолированного блока кода (функции, метода, класса) должно хорошо описываться его названием. По имени метода должно быть понятно, что он делает. По имени класса — зачем он нужен.
Как не надо: создавать классы с именами, содержащими слова Factory, Processor, Engine, Manager. Писать методы длиннее 100 строк и классы больше 300.
Излишний фанатизм: много методов и классов, которые не делают ничего, кроме вызова чего-то еще
2. Open Closed
Как надо: проектировать код так, чтобы будущие изменения требовали минимальных изменений в уже существующий код. Причем эти изменения должны заключаться в добавлении кода, а не в его модификации. Причем изменения должны сохранять обратную совместимость с существующим кодом.
Как не надо: при добавлении функционала код меняется "пятнами", приходится переписывать существующий код.
Излишний фанатизм: глубокое (больше 3 уровней) наследование, использование аспектов, вынос в отдельные методы/классы кода, который не несет смысловой нагрузки. Отсутствие понимания, что пишется не очень конфигурируемый спринг, а собственное приложение, в котором исходники всегда можно подправить.
3. Liskov Substitution
Как надо: все реализации интерфейса должны придерживаться его контракта (явадок на интерфейсе, общие соглашения в проекте)
Как не надо: одна из реализаций делает не то, что написано в контракте интерфейса
Излишний фанатизм: Считать контрактом поведение одной из реализаций интерфейса, применять этот принцип к тестовым мокам и стабам.
4. Interface Segregation
Как надо: Помнить о том, что для большого интерфейса требуется большая реализация, а слишком маленький реализовывать бессмысленно
Как не надо: иметь реализацию интерфейса больше 500 строк или реализацию, которая часть или весь функционал делегирует в другие классы
Излишний фанатизм: Иметь интерфейсы, которые никогда не реализуются и не используются без других интерфейсов. Marker interface, естественно, не в счет.
5. Dependency Inversion
Как надо: Класс должен получать свои зависимости извне (через конструктор), а не конструировать их самостоятельно
Как не надо: передавать в класс вместо зависимостей параметры для их конструирования, использовать фабрики, статические синглтоны
Излишний фанатизм: использовать интерфейсы для всех зависимостей (это же не библиотечный код, всегда можно преобразовать класс в интерфейс), передавать все зависимости извне вместо использования агрегации для зависимостей, которые являются деталью реализации.
