Comments 27
Не всегда стоит всё понимать буквально.
Некоторое время назад существовали предпочтения для длины метода в строках, длины класса в строках и прочее. И это существовало для написания более чистого кода. А также существовал антипатерн "лапша код" который говорил об невероятно длинном методе в котором реализовали все, что можно.
Я думал ужас вроде оплаты по количеству символов итд страшные сказки из прошлого, а оказывается такое ещё попадается?
А я почему-то подумал про нейминг... И сразу вспомнилось вот это :)
Метрика Cognitive Complexity, пожалуй, самая человечная из всех синтетических.
С PHP не знаком, возник вопрос про этот абзац:
Возьмем в качестве примера класс Model в Laravel. Он насчитывает более 2,4 тыс. строк кода. Несмотря на то, что это может показаться огромным объемом, он намеренно спроектирован таким образом. Такой подход гарантирует, что разработчики смогут extend'нуть базовый класс Model, и вуаля, их собственная модель работает без лишних усилий.
Может кто-нибудь пояснить, что такое экстенднуть и почему это можно делать без проблем только с безумно огромными классами, а на классах небольшого размера нужны усилия?
Экстенднуть - наследовать. Если сделать много маленьких классов, то иерархия будет сложнее для понимая, к тому же не все языки программирования поддерживают множественное наследование
Обычно наследуют чтобы поменять поведение метода и если в нем 2.4к строк, то ничего и не поменяешь. Я не знаю Laravel, а там зачем наследуют?
Я вам честно скажу: за четверть века практики я видел всякие классы, и на десятки тысяч строк и маленькие. Так вот, когда классы делаются под конкретную изолированную задачу, тобишь достаточно маленькие, то такая архитектура в миллион раз легче для понимания, чем ковырять архитекруру построенную на всего нескольких, но god class с тысячами строк и сотнями методов, в попытках понять какого хрена здесь все так запутанно.
И за всю жизнь случаев, когда задумывался "ну, вот здесь-бы наверно хорошо легло-бы множественное наследование" можно было сосчитать на пальцах одной руки какого-нибудь старого слесаря. В подавляющем большинстве случаев, все наследование это интерфейс и разные его реализации. Иногда действительно базовый класс с базовым функционалом и его наследники. А вот чтоб наследник стразу двух классов (не интерфейсов, что есть, наверное, во всех языках, а именно классов), это чаще всего (хоть и не всегда) попытка слепить кучку непонятно чего, а то и god class опять-же.
В PHP наследование реализовано способом расширения класса потомка, классом родителя. Расширение (extends) обозначает включение всех методов и свойств в класс наследник. Методы можно переопределить.
Расширение создаёт сильную связь между классами. Если класс ёмкий и реализует некоторый функционал в полной мере, тогда проблем нет. Сильная связанность созданная большим количеством мелких классов создаст определённого рода архитектурные проблемы. Но это не говорит что все классы должны быть длинными или короткими по количеству строк. Классы должны соответствовать принципам solid и архитектурным паттернам .
В том же PHP есть trait-ы для эмуляции множественного наследования. Можно выносить группы функций в отдельные trait-ы которые подключать в основном классе. Для понимания общей работы никакой разницы не будет. Зато для понимания работы группы функций так, на мой взгляд, будет информативнее.
Такое себе. В java сознательно не стали делать множественного наследования. Кажется что использовать трейты именно для обхода ограничения множественного наследования такая себе идея.
Типажи (trait) - они не для эмуляции множественного наследования, а для упрощения реализаций интерфейсов: чтобы не повторять множество раз один и тот же код в разных классах.
Если я правильно помню, в "чистом коде" было что-то типа правило 5-7. То-есть максимум 5-7 методов в классе, максимум 5-7 строк в методе и т. д. А это как-раз до 100 строчек кода.
Кажется что не должно быть сокращения количества строк, ради сокращения количества строк. Это же бред какой-то.
Время от времени работаю с проектом на yii, в котором десятки модулей, сотни или даже тысячи сервисов, десятки тысяч классов. Каждый класс сам по себе не большой. Но где-то 95% из них наследуются от какой-нибудь абстракции, которая тоже может наследовать абстракцию, которая реализует какой-то интерфейс. Модели, формы, контроллеры. Какая-то бизнес-логика. Чуть ли не Дтошки и вообще всё всё всё.
Они небольшие, но в этом разобраться почти так же трудно как и с сущностями бога
Вырвать одну рекомендацию из контекста, взять тупой пример из говнокода, и делать вывод о какой-то вредности чистого кода.
Нет ни одной причины делать лапшу-код, это всегда долго, дорого.
Кажется, не совсем корректно сравнивать код фреймворка, который написан на все случаи жизни, особенно laravel eloquent, и код конкретного проекта. И уж тем более если проект на фреймворке и написан. Согласен с тем, что ограничивать размер классов, это плохая идея. Но если правильно подбирать абстракцию, то размеры классов сами по себе будут уменьшаться.
но, если я правильно помню, там принято помещать открывающую скобку в конец строки. В PHP же принято выносить эту скобку в отдельную строку.
Вообще это зависит от стандарта на стиль кодирования, принятый в конкретном месте. С точки зрения самого php-community эти стандарты менялись от версии к версии. Да и в большинстве PHP IDE можно включить автоматический reformat под разные стили.
Я сам это делаю в зависимоти от целевой версии PHP, там где поддерживается типизация возвращаемых значений и она указана - переношу скобку, там где не указана или пишется кусок кода под php5 без указания типа, то обычно не переношу, экономим строчки, хехе
2.4к строк... ну жуть же, как в этом чудовище ориентироваться? Оно ж в голове не поместится
Какой длины должны быть классы — когда «чистый» код на самом деле не так уж и хорош