Comments 17
Я правильно понял, то что иллюстрации на бритву оккама нет - это и есть иллюстрация?
@GrigoryevArtem спасибо, иллюстрации прикольные: биатлонист в валенках сделал мой день!
Ну в общем-то по картинкам и особенно "выЙграл" уже понятно всё становится о знаниях автора. Особенно обожаю во всём этом карго-культе алфавитного супа это требование неукоснительного соблюдения взаимоисключающих параметров. Значит, плодить сущности нельзя, но классы мы будем разбивать до гранулярности песчинок, пока их количество не разрастётся до того, что разобраться в этом будет невозможно, противореча DRY. Словно никто не слышал о перенормализации в базах данных, где тоже надо знать меру.
Описание BDUF вообще само себе противоречит, надо думать сразу обо всём заранее, но нельзя погрязать в планировании, чтобы не получилось YAGNI. Лучше забейте на оптимизацию, юзер заплатит за новое железо - это объясняет, почему вокруг столько bloatware.
Хорошо придумывать принципы, которые не тебе использовать в реальном проекте.
Спасибо за замечание, но сомневаюсь, что иллюстративные примеры, которые помогут разобраться людям из других сфер IT, не связанных с разработкой, или даже орфографическая ошибка могут позволить судить о знаниях автора.
А по поводу принципов разработки: как и написано в конце статьи, все принципы необходимо использовать в меру и с умом.
«Не стоит стремиться применять все принципы сразу и везде — как и в жизни, здесь важно чувство меры. DRY не означает, что любой повтор кода — зло, а YAGNI не призывает игнорировать архитектуру. Главное — понимать, «зачем», а не просто следовать правилам по списку».
Боже, как же уже надоело читать про этот солид, просто дичайший карго-культ без какого-либо углубления в суть, запудривание мозгов себе и окружающим, просто рак мира разработки...
Эх, вам надоело. А представьте какого поддерживать такой (SOLID-based) 'Академический код' когда всё расщеплено буквально на атомы и всё дерево сущностей и их взаимодействий не помещается в ОЗУ головного мозга (ну, кроме мозга автора). Вообще, я пришёл к выводу, что человека, который пишет грязный/неудобный/неоптимальный код проще научить писать лучше, чем донести мысль о здравом! использовании SOLID его фанату.
Полагаю есть три типа:
Интуитивщики - применяющие данные принципы исходя из многолетнего опыта наломанных дров;
Академики - ну это про них: ООП-(SOLID) головного мозга;
Адекваты - воспринимающие все эти 'правила/принципы' как рекомендации.
Первым нехватает систематизации (упорядоченных знаний). Вторые, в основном, зубрилки (шаблонные програмисты) без творческой жилки, либо фанатики. Третьи рулят, ну или страдают (как я) в компании первых двух :)
Не льсти себе
Да, кстати, не упомянул, что представители вида N 2 заметно выделяются в любом коллективе и очень быстро выдают себя если правильно закинуть удочку. Нетерпимость, фамилиарность и хамство, коммуникация в форме агрессии, если задеть стопы их столпов :) Как тривиальный пример: А сам-то ты кто?! На себя посмотри! - любимые доводы.
Хотя сами по себе они могут быть вполне неплохие ребята, с довольно высоким профессиональным уровнем. Который, очень часто, к сожалению, ограничен их принципиальной "не-гибкостью", возведением в статус Кумира некоего Принципа, и с безжалостностью приснопамятного старичка Оккама, полосующих всея посягнувшееся. Ибо нех.
Мне кажется все буквы solid объясняются в совершенно очевидных фразах
S Не ешь жёлтый снег. Не смешивай несмешиваемое.
O Не ломай то, что уже протестировано.
L Частное правило не должно противоречить общему правилу.
I Не нужно зависеть от того, что не нужно.
D Ты можешь корректно использовать правило, которое работает на более широком множестве (более абстрактное правило), а не более узком.
S Не смешивай несмешиваемое.
O Не ломай то, что уже протестировано. Но добавляй новое.
L Частное правило не должно противоречить общему правилу.
I Не нужно зависеть от того, что не нужно
D Если правило А работает на множестве АА, правило Б работает на множестве ББ , то оба они могут использовать правило В на множестве ВВ, включающем АА и ББ
Вот на D я спотыкаюсь
Какое-то оно непростое
Что должно быть более независимым?
Более высокий уровень модуля (уровень? что это?)
Бо'льшая абстракция
Более широкое множество значений
Реже изменяемая предметная область
Видимо, все 4 пункта верны. Они описывают D с разных сторон:
Реже изменяемая предметная область — это цель. Бизнес-логика должна быть стабильнее, чем выбор конкретной базы данных или способа логирования.
Бо'льшая абстракция / Более широкое множество — это инструмент для достижения стабильности.
Более высокий уровень модуля — это объект, который мы защищаем от изменений.
В итоге, зависимости должны быть направлены от изменчивого к стабильному. Детали (конкретный логгер) зависят от абстракции (интерфейса ILogger), а не наоборот
Проблема в том, что все эти прекрасные принцыпы - это мысли зрелых разработчиков, адресованные зрелым разработчикам.
Вот взять, к примеру, програмку, которая делает что-нибудь полезное по HTTP (и вовсе не обязательно это веб-бровсер). Где тут проводить границы single responsibility?
Вот я бы, наверное, провёл их по линии, очерченной соответствующим набором RFC, вынеся MIME и IDA в отдельные сущности, по границам, очерченным тамошними RFC. Но можно ведь всё в одну сущность затолкать, а можно и наоборот, помельче разрезать. Какое тут правильное решение? На этот вопрос нет простого однозначного ответа.
Или, например, идея распилить класс Biathlete на три, каждый из которых имеет свою реализацию метода train(). Нередко это приводит к тому, что класс, который так бы уместился в 200 простых и понятных строк превращается в иерархию классов, общим объёмом строк на тысячу, которые рано или поздно обрастают дублирующимся кодом и которые надо все параллельно поддерживать.
А так ли уж по сути отличаются тренировки для юниоров, зрелых и престарелых? Может, они в целом примерно одинаковые, но отличаются набором параметров? А что, если "думательную" часть класса сделать общую, и кормить ее табличкой с параметрами, которые специализируют её под контретное применение?
Ну и т.д. и т.п.
И, к сожалению, все эти прекрасные принципы, примененные без соответствующего опыта, пораждают, скорее, не хороший дизайн, а некоторый карго-культ...
а где же SOSAL?
Но ведь это тоже нарушает SRP
public class Competitor {
public void compete() {
// код соревнования
}
}
public class InjuryHandler {
public void handleInjury() {
// код обработки травмы
}
}
public class Biathlete {
public void train() {
// код тренировки
}
}Судя по вашим рекомендациям, правильней так
public class Skier {
public void ski() {
// код тренировки катания на лыжах
}
}
public class Shooter {
public void shoot() {
// код тренировки стрельбы по мишеням
}
}
public class SkiingCompetitor {
public void ski() {
// код катания на лыжах
}
}
public class ShootingCompetitor {
public void shoot() {
// код стрельбы по мишеням
}
}
public class InjuryHandler {
public void handleInjury() {
// код обработки травмы
}
}
В KISS не понятно, почему вы выбросили сложный подсчёт очков. Ну, придумали такой подсчёт, программист его реализовал. Кто он такой, чтобы менять правила?
По это йлогике, в футбольном менеджере нужно было бы не учитывать усталость игроков, занимаемые ими позиции, построение на поле, а просто случайным образом начислять голы. Суть спорта сводится к тому, чтобы иметь некоторые ограничения. Этим ограничением может быть размер снаряда, границы перемещения, правила расположения тела при выполнении чего-либо. И тут может быть именно этот случай, когда выбор позиции влияет на получаемые очки, а спортсмен сам выбирает, ему важнее более высокий шанс попадания или более высокий коэффициент за успех.
SOLID, DRY, KISS, YAGNI и др. принципы разработки, пугающие новичка в IT