Комментарии 11
Ну, solid обыкновенный, каков посыл?
На js можно писать используя solid!
люди все равно сидят на хабре в рабочий день
пусть у них будет повод лишний раз вспомнить о принципах
все равно лучше, чем читать отчет очередной корпорации к примеру
пусть у них будет повод лишний раз вспомнить о принципах
все равно лучше, чем читать отчет очередной корпорации к примеру
и точно полезнее статей на тему «зачем нужны заголовки»
Принцип единственной ответственности imho не очень хорошо описан. Если понимать дословно — то любая сколько-нибудь сложная функция не впишется в рамки, ведь она вызывает несколько простых.
В вашей метафоре со стеной и шурупами — невозможно, не нарушая принципа, "написать функцию", которая, скажем, поставит на стену заплатку (взять лист гипрока, привинтить, закрасить шурупы).
Мне нравится формулировка "действие функции должно описываться одной простой фразой". "Поставить на стену заплатку" — вполне понятно, одно действие.
С одной стороны, может казаться, — банальные вещи. С другой — многие, если и осознают, то не всегда пользуются, пока шишек не набьют. Фундаментальная вещь по теме, на мой взгляд, это "Совершенный код" Стива МакКоннелла. Книга, которая должна быть прочитана, разобрана и принята к использованию, особенно в начале пути разработчика.
Дрель была бы гораздо более полезным и надёжным инструментом, если бы она выполняла лишь одну функцию.Полностью «за», т.е. она должна «сверлить».
А вот закручивать шурупы нужно хотя бы шуруповертом… Думаю, что автор просто запутался в словах. Исправьте, пожалуйста.
функциональщина давно уже проиграла битву ООП
Спасибо за перевод.
Идея статьи правильная, но, как обычно, винтернете кто-то не прав есть замечания.
В основном претензии к примерам. Так автор в статье говорит о SRP и Coupling, а потом в примере к SRP приводит код, который имеет не хилый такой Coupling, причем разных типов.
Возможно идея была в том, чтобы от раздела к разделу применять к коду описанные принципы. Но тогда стоило бы использовать один и тот же код и пошагово применять к нему их, а не приводить разные примеры.
Про сам каплинг, начал автор за здравие, закончил за упокой.
Только заголовок про каплинг, остальное все нужно удалить, дабы не создавать неправильное понимание у начинающих. Вот более правильный пример (первое что показал гугл) одного вида каплинга. Но есть и другие.
Интерфейсы методов — это не каплинг. Это документация для пользователя класса. Оно там для того чтобы можно было быстро понять как класс использовать. Когда автор заменил конструктор с явным обьявлением параметров на объект — он ухудшил «девелопер экспириенс». Теперь IDE не подскажет какие параметры ждет класс. А каплинг остался на месте. Если вдруг этому классу потребуется новый обязательный параметр в конструкторе — разработчику, все так же, придется лезть во все места где этот класс используется и добавлять его. Если вдруг какой-то параметр заменится, или поменяется его смысл — разработчику придется лезть и менять код во всех местах. Если параметр уберется — то код конечно будет работать, но разработчик открывший этот код, будет в замешательстве — «Что этот параметр значит? А не баг ли это?». Еще больше он обрадуется, когда в коде будет 2-3 разных вызова этого конструктора с разным набором параметров.
Чтобы решить эту проблему умные люди давным давно придумали паттерн Фабрика. Но просто заменить new Class на new ClassFactory — не достаточно. Надо таки разобраться что такое каплинг и принцип инверсии зависимостей. И передавать фабрику туда, где требуется создавать объекты.
Хотя есть правильный случай, когда объединение параметров в объект имеет смысл — это когда параметров больше 5 (зависит от соглашений в команде, основано на особенностях человеческого мозга держать в фокусе 5 +- 2 параметра). И то, тогда они объединяются не просто в объект, а в специальный класс, который проверит, что все параметры переданы и корректны.
Про связанность начиналось хорошо, но под конец просто бессмыслица. Хотелось бы обратить внимание на то, что повторяющийся код — это не всегда плохо. Есть разница между DRY и SRP.
В общем Cohesion и Coupling это очень важные метрики кода. И отличный показатель качества кода. Но материал в этой статье не дает хорошего понимания что это и как этим пользоваться. SOLID наше все.
Идея статьи правильная, но, как обычно, в
В основном претензии к примерам. Так автор в статье говорит о SRP и Coupling, а потом в примере к SRP приводит код, который имеет не хилый такой Coupling, причем разных типов.
Возможно идея была в том, чтобы от раздела к разделу применять к коду описанные принципы. Но тогда стоило бы использовать один и тот же код и пошагово применять к нему их, а не приводить разные примеры.
Про сам каплинг, начал автор за здравие, закончил за упокой.
Только заголовок про каплинг, остальное все нужно удалить, дабы не создавать неправильное понимание у начинающих. Вот более правильный пример (первое что показал гугл) одного вида каплинга. Но есть и другие.
Интерфейсы методов — это не каплинг. Это документация для пользователя класса. Оно там для того чтобы можно было быстро понять как класс использовать. Когда автор заменил конструктор с явным обьявлением параметров на объект — он ухудшил «девелопер экспириенс». Теперь IDE не подскажет какие параметры ждет класс. А каплинг остался на месте. Если вдруг этому классу потребуется новый обязательный параметр в конструкторе — разработчику, все так же, придется лезть во все места где этот класс используется и добавлять его. Если вдруг какой-то параметр заменится, или поменяется его смысл — разработчику придется лезть и менять код во всех местах. Если параметр уберется — то код конечно будет работать, но разработчик открывший этот код, будет в замешательстве — «Что этот параметр значит? А не баг ли это?». Еще больше он обрадуется, когда в коде будет 2-3 разных вызова этого конструктора с разным набором параметров.
Чтобы решить эту проблему умные люди давным давно придумали паттерн Фабрика. Но просто заменить new Class на new ClassFactory — не достаточно. Надо таки разобраться что такое каплинг и принцип инверсии зависимостей. И передавать фабрику туда, где требуется создавать объекты.
Хотя есть правильный случай, когда объединение параметров в объект имеет смысл — это когда параметров больше 5 (зависит от соглашений в команде, основано на особенностях человеческого мозга держать в фокусе 5 +- 2 параметра). И то, тогда они объединяются не просто в объект, а в специальный класс, который проверит, что все параметры переданы и корректны.
Про связанность начиналось хорошо, но под конец просто бессмыслица. Хотелось бы обратить внимание на то, что повторяющийся код — это не всегда плохо. Есть разница между DRY и SRP.
В общем Cohesion и Coupling это очень важные метрики кода. И отличный показатель качества кода. Но материал в этой статье не дает хорошего понимания что это и как этим пользоваться. SOLID наше все.
Опять же, всё это уже описано в книге «Программист-Прагматик».
Причём, описано короче и понятнее.
Не наезд, а просто вопрос: зачем плодить дубли? Таких статей куча, во всех книгах уже про это написано, и всё равно, по несколько таких статей в месяц публикуется…
Причём, описано короче и понятнее.
Не наезд, а просто вопрос: зачем плодить дубли? Таких статей куча, во всех книгах уже про это написано, и всё равно, по несколько таких статей в месяц публикуется…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JavaScript: путь к ясности кода