ООП, проюктирование и оформление как критерий
а теперь посмотрим какие паттерны и структурные вещи чисто указывают на то, что код за-ООП-шлен наглухо. не упоминая лишний раз их функции (если кому хочется - см интернету).
к примеру, фабричный метод. ровно про то, что я говорил. создать класс по имени - типичнейшая функция, которая обязана быть простой и встроенной, а тут оно аш оборачивается классами и обертками.
а похопе, причем, обычно еще и через ж. хотя как раз в похопе - это проще пареной репы.
то же самое относится к фабрике, которая де-факто заменяет название класса на алиас. а я в прошлых постах говорил про алиасы, метки и теги к классам. дык чо бы не?
чуть более сложная фигня с абстрактной фабрикой для класса объектов. но! в жизни я такого не встречал, а вот выгрести по тегу класс из набора может быть очень и очень полезно. вспоминаем про также упомянутый уже механизм нейм серча среди классов в рантайме.
синглетоны, сплошные. про которые был по-моему отдельный пост, в котором говорилось, что механизм синглетона и удобство - это две разные хреновины. ща эти штуки идут вместе и имеют определенные сайд-эффекты от того, что их не разделить. как - также было рассказано. чем плохи синглетоны - имеет смысл спросить тестеров, обычно там возникают косяки, с ними связанные.
при этом всем вот этот рассказанный ранее механизм с поиском и регистрацией имен внутри интерпретатора (компялятора? тм) нахрен развязывает все наследования, которые можно использовать в других (к примеру) целях. или - не использовать. или - перестать просто таскать с кодом все, что случайно или не очень занаследовалось за кодом.
все вышеперечисленное как правило четко показывает, что структурщина начинает вытеснять код. и я такое видел.
поэтому как еще один показатель проблем структурности кода можно назвать массовое использование чудо-слов с ихними структурами: включая прямо вот ларавельные все эти вот [там можно уперечисляться].
при этом как еще один критерий, объем необерточного кода резко уменьшается по % объема как только начинают внедряться вот все эти паттерны и прочий хлам. помним как нарисовать hello world на жаве для веба? критерий избыточности жавы можно аш в цифрах посчитать. 10 символов на чуть ли не пару страниц вместо 10 символов на ... 20? php.
не, кому интересно, могут продолжать пользоваться языком с подобной степенью полезной нагрузки. мне - не очень. это ж прикинуть, что если я в похопе чисто трачу половину времени на, скажем так, оформление мыслей и полезностей, то в жаве для этого нужно потратить на пару порядков (!) больше времени.
вторая фигня связана с тем, что в похопе оформление линейно растет со сложностью. для примера, в каком-нить руби (который да, предлагает из коробки типа быстрые решения для начала проектов), наверно соотношение в начале проекта близко к похопе, а может и лучше, фик бы с ним. но с ростом проекта, насколько я примерно в курсе, % оформления (и в частности, допиливания до продакшна, а не как обычно тм) походу растет хуже линейного. судя по сводкам - намнооого хуже. и проблемки там врастают в интерпретатор.
а теперь смотрим: как только начинается возня с чудо-паттернами, возникает четкая проблемка, связанная с тем, что поддержание этой оформительской хрени занимает туеву хучу времени и сил. пример же wp показывает, что даже на уровне 10-лет-назад это все. уже тогда. было. до. лампочки. если грамотно просто пользоваться возможностями языка и накласть на сияние ООП, а пользоваться только тем, шо там удобно.
не очень понятно - можно ли автоматизировать поиск "оформительского кода", шоп получить четкие метрики, но как минимум уже имея вот эти вот сравнительные вещи, можно начать хотя бы оценивать а) возможности языка б) прикидывать сложность проекта как в сияющем начальном виде, так и в legacy в) (удивительно, но) начать думать не в сторону "как бы прикрутить новые паттерны", а в сторону "а какие механизмы помогут снизить % оформления, а за счет этого - уменьшить чисто физически и количество ошибок и многое чего еще за счет уменьшения писанины".
к примеру, фабричный метод. ровно про то, что я говорил. создать класс по имени - типичнейшая функция, которая обязана быть простой и встроенной, а тут оно аш оборачивается классами и обертками.
а похопе, причем, обычно еще и через ж. хотя как раз в похопе - это проще пареной репы.
то же самое относится к фабрике, которая де-факто заменяет название класса на алиас. а я в прошлых постах говорил про алиасы, метки и теги к классам. дык чо бы не?
чуть более сложная фигня с абстрактной фабрикой для класса объектов. но! в жизни я такого не встречал, а вот выгрести по тегу класс из набора может быть очень и очень полезно. вспоминаем про также упомянутый уже механизм нейм серча среди классов в рантайме.
синглетоны, сплошные. про которые был по-моему отдельный пост, в котором говорилось, что механизм синглетона и удобство - это две разные хреновины. ща эти штуки идут вместе и имеют определенные сайд-эффекты от того, что их не разделить. как - также было рассказано. чем плохи синглетоны - имеет смысл спросить тестеров, обычно там возникают косяки, с ними связанные.
при этом всем вот этот рассказанный ранее механизм с поиском и регистрацией имен внутри интерпретатора (компялятора? тм) нахрен развязывает все наследования, которые можно использовать в других (к примеру) целях. или - не использовать. или - перестать просто таскать с кодом все, что случайно или не очень занаследовалось за кодом.
все вышеперечисленное как правило четко показывает, что структурщина начинает вытеснять код. и я такое видел.
поэтому как еще один показатель проблем структурности кода можно назвать массовое использование чудо-слов с ихними структурами: включая прямо вот ларавельные все эти вот [там можно уперечисляться].
при этом как еще один критерий, объем необерточного кода резко уменьшается по % объема как только начинают внедряться вот все эти паттерны и прочий хлам. помним как нарисовать hello world на жаве для веба? критерий избыточности жавы можно аш в цифрах посчитать. 10 символов на чуть ли не пару страниц вместо 10 символов на ... 20? php.
не, кому интересно, могут продолжать пользоваться языком с подобной степенью полезной нагрузки. мне - не очень. это ж прикинуть, что если я в похопе чисто трачу половину времени на, скажем так, оформление мыслей и полезностей, то в жаве для этого нужно потратить на пару порядков (!) больше времени.
вторая фигня связана с тем, что в похопе оформление линейно растет со сложностью. для примера, в каком-нить руби (который да, предлагает из коробки типа быстрые решения для начала проектов), наверно соотношение в начале проекта близко к похопе, а может и лучше, фик бы с ним. но с ростом проекта, насколько я примерно в курсе, % оформления (и в частности, допиливания до продакшна, а не как обычно тм) походу растет хуже линейного. судя по сводкам - намнооого хуже. и проблемки там врастают в интерпретатор.
а теперь смотрим: как только начинается возня с чудо-паттернами, возникает четкая проблемка, связанная с тем, что поддержание этой оформительской хрени занимает туеву хучу времени и сил. пример же wp показывает, что даже на уровне 10-лет-назад это все. уже тогда. было. до. лампочки. если грамотно просто пользоваться возможностями языка и накласть на сияние ООП, а пользоваться только тем, шо там удобно.
не очень понятно - можно ли автоматизировать поиск "оформительского кода", шоп получить четкие метрики, но как минимум уже имея вот эти вот сравнительные вещи, можно начать хотя бы оценивать а) возможности языка б) прикидывать сложность проекта как в сияющем начальном виде, так и в legacy в) (удивительно, но) начать думать не в сторону "как бы прикрутить новые паттерны", а в сторону "а какие механизмы помогут снизить % оформления, а за счет этого - уменьшить чисто физически и количество ошибок и многое чего еще за счет уменьшения писанины".