Comments 32
Все хорошо. Но. Господи, это же книга 2013 года. С некрофилией типа того же Unity. Неужели нельзя что-нибудь посвежее сюда притянуть? Хотя бы вот это - если уж говорить про .NET и DI то это считается классикой..
То есть вы считаете что читать можно только что-то свеженькое? Начиная с какого года материал стоит переводить, вы считаете? - ну так на всякий случай, чтобы авторы (не только я) на Хабре больше не ошибались?
Почему то свеженькое все сложнее понимать, по крайней мере мне.
Про DI уже столько всего написано - хоть на русском, хоть на чукотском, что про него переводить что-то и смысла нет. Переведите, например, вот это - респект, я думаю, тут будет вам огромный, тем более там статьи на три, а то и больше. Там у чувака, причем, язык какой-то дико тяжелый - я на английском читаю практически свободно, но прочитать осилил, наверное, только половину :(
Переведите, например, вот это - респект, я думаю, тут будет вам огромный
Я как раз думал написать на эту тему - как оно работает даже от себя, но можно и перевести. За такое побуждение, спасибо.
Про DI уже столько всего написано
Но я же не про DI перевел, я перевел "Пример для иллюстрации принципов SOLID" самый простой пример из возможных, как мне кажется.
Что там понимать-то... Нужно просто с тестов начинать, и все само собой встанет на свои места.
Нужно просто с тестов начинать
Это тоже может быть опасный путь, ведь тесты тоже надо как-то проверить, то есть для тестов нужен другой уровень тестов. Есть риск нарваться на не хорошую рекурсию.
Я к тому что там со всех сторон засада :), с этими СОЛИДАМи, хоть ТДД-шными, хоть какими.
Я бы оставил вот так:
Нужно просто - - - начинать, и все само собой встанет на свои места.
Потому что, если не начать, то точно ничего не получится.
Приветствую, новый адепт SOLID и KISS ;)
да я не столько про SOLID и KISS и иже с ними хотел высказаться, а на предмет:
где СЛожно, а где НЕ-сложно,
в ответ на статью: SOLID — это несложно. С примерами на Python.
обожаю принципы SOLID, у них столько разных толкований. ведь это то что нужно от паттернов и принципов разработки, чтобы можно было поспорить над куском кода насколько он солид и в какой трактовке.
Кто-то пошутил что SOLID DRY code is a WET dream EVAPORATED.
Плюсую. Считаю, что принцип должен прост, понятен и легкозапоминаем, как DRY и KISS. 95% разработчиков через полгода после последнего собеседования не вспомнят, что это вообще за буквы: OCP, SSP, SDP и прочие. Которые, и расшифровав, не поймёшь, что значат. Аббревиатуры ради литературы и диссертаций.
Считаю, что принцип должен прост, понятен и легкозапоминаем, как DRY и KISS.
Ну SOLID прост, понятен и легко запоминаем, как DRY и KISS.
95% разработчиков через полгода после последнего собеседования не вспомнят, что это вообще за буквы: OCP, SSP, SDP и прочие.
Если в команде есть ревью ему напомнят. К тому же разработчика могут попросить провести собеседование для кандидата.
Ну SOLID прост, понятен и легко запоминаем
Так же прост как отделить от монолитного EXE-шника некоторую функциональность в виде библиотеки (DLL-ки, - когда-то их называли компонентами, теперь можно назвать микросервисом, или нельзя? к микросервисам надо по сети обращаться??? Но к ДЛЛ-кам тоже по сети можно обращаться вроде), а потом написать другую ДЛЛ-ку с другой реализацией и сделать чтобы из EXE-шника можно было выбрать через какую реализацию этой функциональности мы будем работать. Это если совсем приземленно описать практический смысл.
Тут и запоминать то нечего. Или есть другие варианты?
я добавлю что ко всему вышеперечисленному принцип должен быть в достаточной мере однозначен. если его трактуют по разному пользы от него мало. solid не принцип а набор принципов. что уже перебор, фраза "код не соответствует solid" не даёт информации без разъяснений. но дело еще в том что многие из этого набора принципов можно толковать по разному, даже в одном стэке технологий. и толкуют. думаю вы сталкивались, не раз. а в разных стэках вообще беда. и получается что это просто принципы для собесов, как точка начала общения по архитектуре, и принципы для очень общего понимания хороших практик где то на уровне начинающего мидла, после длинных статей разъяснений о чем же на самом деле solid.
Ну честно говоря я бы не сказал что solid так же прост как kiss или dry. Особенно если почитать Мартина. Особенно первый принцип, который кажется часто вызывает разночтения.
В этом изложении которое я перевел все в общем то сводится к тому что член класса ЖЕЛАТЕЛЬНО иметь в виде интерфейса:
private readonly ITenantStore tenantStore;а не в виде некоторой законченной реализации класса:
private readonly TenantStore tenantStore;То есть разница только в добавленной буковке "I" перед "TenantStore".
Далее расписано что это дает:
Это изменение напрямую влияет на то, насколько легко вы сможете выполнить список требований
И даже написано что эта замена класса на интерфейс не эффективна для маленьких проектов:
Небольшие примеры слабосвязанного дизайна (читай дизайна по правилам СОЛИД), программирования на интерфейсах и внедрения зависимостей часто усложняют решение
потому что эта добавленная буква "И" тащит за собой много дополнительного кода для ее обслуживания.
Интересно о чем тут можно спорить?
Хотя одна версия ответа у меня есть: можно спорить о том достаточнно ли проект большой (или сможет ли он дорасти до нужной величины), чтобы применять к нему незабвенные принципы.
Вот спорить о том является ли код СОЛИД или не-СОЛИД, мне кажется не очень конструктивно.
Вроде как из описания очевидно:
есть буковка "И" = СОЛИД:
нет буковки "И" = не-СОЛИД
если это шутка то я не уловил её соль. объясните где лопата, пожалуйста.
если это серьёзно то я офигел, сказал что хабр уже не торт и тихо слился. объяснений в этом случае не надо.
Шутка в том что все зависит от одной буковки разве это не очевидно? И разве это не весело? Может соль вы не в состоянии уловить, потому что маленько (совсем чуть-чуть) забронзовели?
В каком то старом кино было, примерно так:
Не делайте умное лицо, господа!
Помните все глупости в этом мире делаются именно с этим выражением лица.
Привет.
Для получения дополнительной информации смотрите the article Principles of Object Oriented Design by Robert C. Martin статью Роберта К. Мартина <ред: ссылка для меня не работает к сожалению>.
Попробуй эту ссылку http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
SRP описан неверно и приведен неверный пример, собственно, как и почти везде в интернете. В последних изданиях «Чистой архитектуры» Боб Мартин извиняется за слово «причина» в определении, потому что подавляющим большинством оно было понято неправильно. А затем дает новое определение «перед каждым классом должен быть ответственен только один актор» - что делает пример из статьи (и из большинства других статей) бесполезным. Тем не менее, даже с таким определением этот принцип почти никогда нельзя соблюсти из-за наличия функциональных и не функциональных требований, т.е. актора всегда два: заказчик, который просит перекрасить кнопку, и какая-нибудь кор-команда, которая просит тебя переписать код под новую мажорную версию языка
SRP описан неверно и приведен неверный пример
если бы вы прокоментировали, что конкретно вам не нравится в утверждении:
класс ManagementController выполнял две функции: выступать в качестве контроллера в пользовательском интерфейсе и создавать экземпляры объектов TenantStore и управлять временем жизни объектов TenantStore. Во втором примере ответственность за создание экземпляров объектов хранилища клиента и управление ими лежит на другом классе или компоненте системы.
, а не рассуждали абстрактно про "перекрасить кнопку", было бы очень интересно.
Потому что он про совершенно другую вещь. Принцип про то, что только один человек или одна группа людей может задать такие требования, что придется вносить изменения в этот класс. Не про то, что класс не может выполнять более одной функции
Система, вступление к описанию которой я перевел, вполне успешно используется-работает, насколько я знаю. И насколько я понимаю она построена вполне в соответствии с теми принципами, описание которых я перевел.
Поэтому можно много и нудно рассуждать о том кто как и что понимает и за что извиняется, а можно просто посмотреть как люди делают и сделать для себя выводы, что является пустыми рассуждениями, а что имеет практическое значение.
SRP описан неверно и приведен неверный пример, собственно, как и почти везде в интернете.
Все нормально. Это перевод. Переведено правельно.
Потому что он про совершенно другую вещь. Принцип про то, что только один человек или одна группа людей может задать такие требования
Вот ссылка на статью 2014 где Роберт Мартин дает пояснения.
https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Это скорее разяснения причем сделанное с точки здения DDD. В книге Martin, Robert C. (2018). Clean architecture : a craftsman's guide to software structure and design дана формулеровка уже не много другая "A module should be responsible to one, and only one, actor." Именно actor, а не people.
Термин actor это больше по Event storming и архитектуру, а не про код.
Статья в вики по Event storming (https://en.wikipedia.org/wiki/Event_storming) предлагает три типа actor это Guest, Registered user, Administrator. Для того чтоб знать что у нас за actor нужно прогнать его через аутентификацию и авторизацию. Только после этого мы сможем понять кто это и какой ему отведен класс. А как применять SRP к аутентификации и авторизации, когда мы еще не знаем что это за пользователь. Или к классам где нет пользователя. Как применить к классу для нотификации. Мы же не будем email и sms пихать в один класс. Для таких случаев подойдет старый, добрый принцип описанный в этой статье и заботливо переведенный автором. Который почемуто многое считают не правельным или устаревшим.
Про перевод согласен.
Где Боб Мартин ссылался на Event storming? В Clean architecture словом actor Боб пользуется для краткости, заменяя им слова user, stakeholder и их группы. А стейкхолдеры это и people тоже.
"Мы же не будем email и sms пихать в один класс. Для таких случаев подойдет старый, добрый принцип описанный в этой статье" - вам Мартин буквально сказал, что этот старый добрый принцип понят неправильно и SRP про другое. SRP != неправильно трактованный SRP. Я не против существования старой трактовки, хоть и она вызывает определенные вопросы, но она НИКАК больше не принадлежит SOLID.
Перевод не правильный. У терминов "единый" и "единственный" разное значение в словаре.
Любители похоливарить обожают понадругаться над SRP, даже не понимая, о чём писал Мартин. В CC и CA смысл SRP различен, потому как книги написаны про разные концептуальные уровни. CA - про построение архитектуры, а не про код. А CC - про код, а не про архитектуру.
У терминов "единый" и "единственный"
Я, извините, глубоко сомневаюсь что варианты перевода какого-то одного слова, в каком-то контексте надо воспринимать как термины, но там действительно затесалась ошибка, вместо "единый" действительно правильно перевести single как "единственный" или одиночный. Благодарю за замечание!
Любители похоливарить обожают понадругаться над SRP, даже не понимая, о чём писал Мартин.
Интересно, кто же понадругался над SRP в данном конкретном случае, и в чем состояло надругательство. Неужели вы подозреваете в этом авторов исходного текста?
За то что вы нашли ошибку в моем переводе (которую я теперь исправил), я раскажу вам по секрету :) в чем главная проблема с принципом SRP. Как мне это кажется.
Так вот проблема с этим принципом в том, что сам то принцип очень прост, но он никак не помогает в идентификации этой самой "ответственности" как единственной или одиночной. Другими словами вы всегда можете определить некую совокупность отвественностей как одну ответственность (здесь кстати подойдет слово единую ответственность, возможно поэтому я пропустил это слово в исходной версии перевода - в качестве оправдания мне). Как видите проблема не с принципом, проблема в том, что считать одиночной ответственностью, это всегда субъективное решение, пока вы не определили четких критериев разделения ответственностей, которые принцип не определяет.
Но вот пример, который есть в тексте, который я перевел, вполне наглядно демонстрируе некий способ идентификации ответственностей в этом смысле, по крайней мере для меня он вполне наглядный.
Тут вся соль в том, что единственность определяется контекстом применения.
При проектировании апи метода мы, например, хотим, чтобы он возвращал список мух и не стремимся в этот же набор напихать ещё и котлет. Однако, при получении мух производится множество операций разными акторами со своей ответственностью. Но при этом мы не выделяем эти операции в разные апи методы.
При создании класса получения записей мы не замешиваем в него работу с базой и сериализацию на фронт. Мы создаём два класса для этих двух задач. Однако же, мы не разделяем ответственность по записи и чтению на разные классы.
При написании функции сохранения поста на форуме мы не пишем там же обновление профиля. Однако, в ту же функцию мы можем запихнуть обработку низкоуровневых исключений.
Всё это проявления SRP, но в зависимости от контекста, они проявляются несколько по-разному. Но многие холиварщики продолжают топить за лишь одно из проявлений - у каждого разное.
Кстати, у Эванса в DDD есть прекрасный термин - ограниченный контекст. Рекурсивно применяя его на кодовую и архитектурную базу и соответствующим образом масштабируя, можно без труда увидеть применимость SRP в конкретном контексте.
Кажется, миллиард определений одного и того же принципа это не проблема любителей холиварить, а проблема автора этого принципа
Пример для иллюстрации принципов SOLID который я (кажется) понял