Pull to refresh

Comments 19

Картинка хорошая, а статья уж очень очевидная.
Картинка не совсем подходит к топику про PHP.
Зачем писать статью которая не несет в себе никакой ценности? Подобного материала (а зачастую и более широко охватывающего тему) на в интернете (в целом) и на хабре (в частности) валом.
Зачем нужен функциональный этап?
Иногда проще разбить на атомарное, собирать из ящиков дома проще, чем из молекул.
Можно вообще начинать писать сразу «как нужно». Если позволяют объёмы кода — можно сразу выделять всё в классы.
> Переход к функциональному программированию поможет сократить код, хоть и на примере 1 вызова
Я не понимаю, при чем тут вообще ФУНКЦИОНАЛЬНОЕ программирование. Может все же процедурное?
Да и у вас в ООП я бы сказал не очень все красиво.
Ну например можно разделить php и html, использовать вьюшки (кстати, интересней было бы про mvc написать) или шаблонизатор.
На мой взгляд бОльшую часть статьи можно заменить на слова:
«Если при написании программного средства вы получили (извиняюсь) говнокод, попробуйте переписать его в объектно-ориентированном стиле.»
Статья была бы нормальная(хорошая), если бы Вы предложили «метод» «перелопачивания» кода на ОО-стиль
Простите, а вы читали, собственно, Refactoring Фаулера?
Тут ещё бы не помешала «Эффективная работа с унаследованным кодом».
Начинание похвальное, сам давно хотел что-нибудь подобное написать, но казалось, что такого примера будет мало, а приличный кусок говнокода не писался :) Но вот реализация…

0. Перед началом рефакторинга система должна быть покрыта тестами, хотя бы те области, что рефакторинг затронет.

2.1 Делаем рефакторинг и первым же делом создаём глобальную переменную? «Я комсомолец, я не могу без трудностей»?
2.2 Делаем рефакторинг, но оставляем вывод html из php?

3.1 Создаём абстрактный класс? Зачем? Абстракция ради абстракции?
3.2 Логика приложения и представления всё равно остались перемешанными.

Это только навскидку. Может имеет смысл написать как я бы рефакторил подобный код?

Вы сделали из куска относительно терпимого процедурного скрипта кусок оверинжиниренного ооп-говнокода с «ооп ради ооп»:

1. Не разделили представление и бизнес-логику.
2. В процессе того, что на самом деле является рефакторингом «выделение метода» родили недорепозитарий с ненужным абстрактным классом.

Если уж делать, то доделывать до конца, не? И учитывать исходную задачу. С задачей «вывести список пользователей» прекрасно справляется и самый первый пример кода.
> Зачем нужно подключать все функции в системе, если достаточно работать только с необходимым набором
> функциональности? Например на странице простого списка пользователей — нет необходимости
> подключать весь список функций, таких, например как задача, или проект.

Очень странное представление об ООП.

Почему-то считается хорошим стилем использовать объекты для создания модульности и динамического подключения. Однако, само по себе это вообще никак не относится к ООП. Во многих популярных PHP-фрейморках сейчас так используются объекты, вероятно, просто по той причине, что в PHP есть удобные инструменты для этого (магические методы, автолоадеры и т.п.)

Суть ООП — инкапсуляция, наследование, полиморфизм. Для веб-разработки я особенно выделил бы инкапсуляцию. Т.е. наши программные объекты должны соответствовать объектам в бизнес-логике (данные и методы их обработки), а не служить просто разделению на модули.
function Get($limit = 10){
     $DB->query('SELECT * FROM ' . $this->moduleName.' LIMIT ' . $limit);
     $users = array();
     if($DB->get_num_rows()){
        while($user[] = $DB->fetch_row());
     } 
     return $users;
}


foreach($users as $u) {
    echo'<p>', $u, '</p>';
}
Only those users with full accounts are able to leave comments. Log in, please.

Please pay attention