Из гадкого утёнка в лебедя, или как исправить криворукий код

Картинка хорошая, а статья уж очень очевидная.

Зачем писать статью которая не несет в себе никакой ценности? Подобного материала (а зачастую и более широко охватывающего тему) на в интернете (в целом) и на хабре (в частности) валом.

Зачем нужен функциональный этап?

> Переход к функциональному программированию поможет сократить код, хоть и на примере 1 вызова
Я не понимаю, при чем тут вообще ФУНКЦИОНАЛЬНОЕ программирование. Может все же процедурное?

Да и у вас в ООП я бы сказал не очень все красиво.

На мой взгляд бОльшую часть статьи можно заменить на слова:
«Если при написании программного средства вы получили (извиняюсь) говнокод, попробуйте переписать его в объектно-ориентированном стиле.»
Статья была бы нормальная(хорошая), если бы Вы предложили «метод» «перелопачивания» кода на ОО-стиль

Простите, а вы читали, собственно, Refactoring Фаулера?

Начинание похвальное, сам давно хотел что-нибудь подобное написать, но казалось, что такого примера будет мало, а приличный кусок говнокода не писался :) Но вот реализация…

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

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

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

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

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

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

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

после просмотра примеров вспомнилась заметка The Evolution of a Programmer

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

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

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

Суть ООП — инкапсуляция, наследование, полиморфизм. Для веб-разработки я особенно выделил бы инкапсуляцию. Т.е. наши программные объекты должны соответствовать объектам в бизнес-логике (данные и методы их обработки), а не служить просто разделению на модули.

habrahabr.ru/post/147438/ — другой вариант :)

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>';
}