Но вот если использовать не MVC, а немного более прогрессивный MVVM, то вся логика представления (кроме разве что итераторных циклов) внезапно оказывается там где ей и положено быть — в контроллере.
Сложилось впечатление, что автор никогда не работал на больших проектах, в команде и в энтерпрайзе, со всеми его проблемами и бардаком.
1.1. ООП неэффективно только в совсем уж коротких скриптиках. По поводу производительности и серверных приложений вообще чушь какая-то. Время разработчиков стоит СИЛЬНО больше железа, соответственно, тратить его на разгребании вермишели…
1.2. Чушь. Вы не понимаете для чего нужно наследование.
1.3. У вас странные представления о «крутом» коде и о паттернах. Крутой код — тот который легко читать, в котором легко разобраться и, который ЛЕГКО расширять.
1.4. А как же принцип разделения логики и представления? Не являюсь пхп-программистом, но логика внутри шаблона — это же ужасно с точки зрения читабельности.
1.5. Если библиотека спроектирована правильно и выполняет задачи с заданными требованиями и ограничениями нет никакого смысла лезть внутрь, кроме случаев когда ее нужно расширять. Достаточно интерфейса. Если это фреймворк (а фреймворк — это НЕ библиотека) — то разработка под ним как раз и осуществляется за счет его расширения, соответственно, и знать его изнутри НАДО.
2-3. Да, согласен.
4. Выделять можно и НУЖНО. Опять же в целях читабельности, расширяемости и так далее.
5. Почти согласен. Но нужно учитывать что большинство систем все-таки живет постоянно развиваясь. Решая задачи нужно стараться оставлять возможность для расширения.
6. К сожалению, этот пункт слабо относится к содержанию статьи и выглядит как попытка оправдать свое мнение.
7. Чушь, кроме случая плохо спроектированной системы, развитие которой приводит к вермишелеобразности. Лечится живительным рефакторингом.
Как ни странно очень удобно — Ctrl, Shift + стрелки, end, home и так далее для выделения текста и тут же с использованием тех же Ctrl, Shift копируем и вставляем. Одна рука все время над левой частью клавиатуры, вторая все время над правой.
Оттуда же, 3-й факультет.
Впечатления — шикарная база, матподготовка и теория по специальности; с практикой и прикладными предметами все плохо, часть прочли «для галочки», часть честно признали, что учить некому да и смысла нет, так как к диплому все поменяется и все равно придется учиться самому, и прочли теоретические основы.
Но вот если использовать не MVC, а немного более прогрессивный MVVM, то вся логика представления (кроме разве что итераторных циклов) внезапно оказывается там где ей и положено быть — в контроллере.
1.1. ООП неэффективно только в совсем уж коротких скриптиках. По поводу производительности и серверных приложений вообще чушь какая-то. Время разработчиков стоит СИЛЬНО больше железа, соответственно, тратить его на разгребании вермишели…
1.2. Чушь. Вы не понимаете для чего нужно наследование.
1.3. У вас странные представления о «крутом» коде и о паттернах. Крутой код — тот который легко читать, в котором легко разобраться и, который ЛЕГКО расширять.
1.4. А как же принцип разделения логики и представления? Не являюсь пхп-программистом, но логика внутри шаблона — это же ужасно с точки зрения читабельности.
1.5. Если библиотека спроектирована правильно и выполняет задачи с заданными требованиями и ограничениями нет никакого смысла лезть внутрь, кроме случаев когда ее нужно расширять. Достаточно интерфейса. Если это фреймворк (а фреймворк — это НЕ библиотека) — то разработка под ним как раз и осуществляется за счет его расширения, соответственно, и знать его изнутри НАДО.
2-3. Да, согласен.
4. Выделять можно и НУЖНО. Опять же в целях читабельности, расширяемости и так далее.
5. Почти согласен. Но нужно учитывать что большинство систем все-таки живет постоянно развиваясь. Решая задачи нужно стараться оставлять возможность для расширения.
6. К сожалению, этот пункт слабо относится к содержанию статьи и выглядит как попытка оправдать свое мнение.
7. Чушь, кроме случая плохо спроектированной системы, развитие которой приводит к вермишелеобразности. Лечится живительным рефакторингом.
XaocCPS, спасибо за статьи и ссылку.
Удивлен, что никто больше не предложил ;)
> Фитнесс-функция реализована как среднеквадратическое отклонение между выходным сигналом тестового фильтра и сгенерированного по генам особи
Вот уж не сказал бы, что банальный метод наименьших квадратов сложнее в реализации генетического алгоритма.
Как еще одно применение генетического алгоритма — не оправдано и не интересно.
Статью — в сборник антипаттернов.
Впечатления — шикарная база, матподготовка и теория по специальности; с практикой и прикладными предметами все плохо, часть прочли «для галочки», часть честно признали, что учить некому да и смысла нет, так как к диплому все поменяется и все равно придется учиться самому, и прочли теоретические основы.
Там очень неплохо объяснено зачем когда-то выпускали такие сборники.