использовать функцию или повторять код?

Духовность™

Продвинутый новичок
использовать функцию или повторять код?

Есть класс порядка 700 строк. Есть методы типа:

PHP:
    protected final function createSimpleRowObjectFromArray($data)
    {
        $object = new $this->model_class_name();

        if ($data)
        {
            foreach ($data as $key => $value)
            {
                $object->$key = $value;
            }
        }

        return $object;
    }
этот вспомогательный метод используется только в 2 местах, в таких же protected final методах (впрочем, видимость тут просто к слову):

PHP:
    protected final function findSimpleRowObjectByParams($params)
    {
        $res = $this->selectSimpleRowRes($params);

        $object = $this->createSimpleRowObjectFromArray($res->fetch_assoc());

        return $object;
    }
вопрос: как боле правильно в таких вот случаях - выносить код методов типа createSimpleRowObjectFromArray в отдельные методы, как сейчас сделано или повторять этот код там. где сейчас вызовы createSimpleRowObjectFromArray?

Что не нравится уже сейчас:

- цепочки методов при таком подходе получаются уже большой глубины, до вложенностью 3-4 и я начинаю беспокоиться о быстродействии - уже пахнет "жаренным"
- становится трудно ориентироваться в коде.
 

whirlwind

TDD infected, paranoid
Походу у тебя симптомы поклонения декомпозиции. Плодить код конечно смысла нет. Попробуй посмотреть со стороны теста (интерфейса) и используй правило трех ударов. А вообще, класс на 700 строк выглядит пухловатым. Скоро ты начнешь выделять интерфейсы и у тебя начнется болезнь поклонения декомпозиции :D А если серьезно, у Фаулера есть такая формулировка подходов тестирования: проверка состояния и проверка поведения. Хотя это он про TDD, но вообще это к любому коду относится. Просто делай боле содержательные состояния. По идее это должно привести к тому, что из кода исчезнут бесполезные вызовы, которые тебе не нравятся.

ЗЫ. грубо говоря, у тебя щас классы ориентированные на поведение. Это не плохо. Но главное помнить, что объект - это состояние + поведение. То есть ищем серебрянную пулю.
 

HraKK

Мудак
Команда форума
а еще меня как-то смущает связка final protected. Зачем такое чудо?
 

Духовность™

Продвинутый новичок
раньше использовались эти методы в классах-потомках.финал для того, что бы низя было изменить, ибо предполагалось, что эти финальные методы- рабочие лошадки моего мега-супер-меппера
 

HraKK

Мудак
Команда форума
хм, не понимаю полиморфизм это основа ООП и зачем ее запрещать. Ладно, наверно есть нюансы которые без контекста не понять.
 

whirlwind

TDD infected, paranoid
HraKK потомучто final private вроде как бессмысленно, а final public закрывает интерфейс для модификаций, что не есть гуд :) Хотя мне в последнее время больше нравится подход java - final class... Но это не тот случай.
 

HraKK

Мудак
Команда форума
whirlwind
Вот я понимаю и использую final class, а вот для методов - хз.
 

atv

Новичок
и я начинаю беспокоиться о быстродействии - уже пахнет "жаренным"
Пока ты не сделал замеры производительности на реальном приложении, и не обнаружил, что кол-во вызовов этих методов на время их исполнения занимает хотя бы 1% общего времени исполнения приложения, то ничем это не пахнет. Это признаки преждевременной оптимизации.

становится трудно ориентироваться в коде.
Ничего подобного, код очень нагляден. Что делается в методе findSimpleRowObjectByParams читается на ура, просто и понятно. И не бойся декомпозиции, она, во-первых, позволяет получить более наглядный профайлинг производительности, а во-вторых, сделать код более читабельным.

В трёх строчках кода разобраться куда проще, чем в 50-ти, и, соответственно, труднее наделать ошибок. А склеить код этих двух методов ты всегда успеешь, если у тебя есть юнит тесты и железные основания в виде профайлинга производительности.
 

fixxxer

К.О.
Партнер клуба
>> цепочки методов при таком подходе получаются уже большой глубины, до вложенностью 3-4 и я начинаю беспокоиться о быстродействии - уже пахнет "жаренным"

Не беспокойся о быстродействии на этапе проектирования интерфейсов. Вообще не забивай голову.

В целом, один SQL-запрос стоит сотни вызовов методов; так что оптимизировать придется как раз реализации моделей, что несколько позже. :)

700 строк - это явно дофига. Посмотри, не знает ли твой класс слишком много и не берет ли на себя слишком много ответственности. Декомпозиция, она самая =). Но тут легко увлечься и сделать "передекомпозицию", в общем следй принципу единой ответственности <http://wiki.agiledev.ru/doku.php?id=ooad:principles:srp>.
 

whirlwind

TDD infected, paranoid
atv
В трёх строчках кода разобраться куда проще, чем в 50-ти
Ага, особенно если для этого надо развернуть стек на писят вызовов. Это и есть то, что я называю поклонением декомпозиции. Лекарство - КИСС.
 

fixxxer

К.О.
Партнер клуба
>>Ага, особенно если для этого надо развернуть стек на писят вызовов. Это и есть то, что я называю поклонением декомпозиции.

Это уже другая крайность. :)

А вот грамотный KISS приходит только с опытом, да и то постояно косячить будешь =) тут по моему фиг сформулируешь принцип, по которому какой-то баланс можно достичь. Тут скорее на уровне ощущения "что это за фигня такая!" =)
 

atv

Новичок
Ага, особенно если для этого надо развернуть стек на писят вызовов
Ага, если методы на писят строк, то как раз приходиться разворачивать стеки.

Это и есть то, что я называю поклонением декомпозиции.
И на какого бога ты променял декомпозицию? на КИСС? Так ты не правильно её понимаешь.

Как раз, если строить цепочку вызовов по методу сверху вниз, прямо по "ромбикам" алгоритма, не задумываясь в этот момент о реализации, то получишь простой и понятный набор заглушек методов, который потом наполняешь реализацией. Проще некуда.
 

fixxxer

К.О.
Партнер клуба
Давайте не будем скатываться в обсуждение идиотских крайностей "метод на каждую строчку кода" vs "все говно одной лапшой" )

А грамотная декомпозиция - это хорошо и правильно.
 

whirlwind

TDD infected, paranoid
ща нарою топ, что бы было понятно о чем я

-~{}~ 09.02.10 22:32:

Вот http://phpclub.ru/talk/showthread.php?postid=796508#post796508

Поздравте мну кстате. Я покорил 7 уровень :D

Восьмым пунктом можно записать поиски неформальных (не математически-точных) способов программирования, то есть - проектирования. Инженерные практики освоены, но есть понимание, что большой объем работы связан исключительно с переделками и недопроектированием. Что будет на 9 я пока хз ;)
 

fixxxer

К.О.
Партнер клуба
С теорией согласен =)

Но ты так и не пояснил, что имеешь в виду под избыточным декомпозированием. Если "разнесение одной ответственности по нескольким сущностям" - то согласен.
 

whirlwind

TDD infected, paranoid
Избыточная декомпозиция - это когда у класса нет четкой зоны ответственности. Просто функционал гуляет из класса в класс (из метода в метод). Я думаю, что без проектирования с этим не справиться.
 

fixxxer

К.О.
Партнер клуба
Да, еще необходимость декомпозиции диктуется, так сказать, уровнем вложенности (скажем, относительно контроллера). Если брать базовые компоненты фреймворка, то тут лучше пере-, чем недо-: лучше заранее предусмотреть варианты, чем потом лезть и править код фреймворка (а тут начинаются хаки ради совместимости); если же речь идет о релизации скаже модели, уникальной для данного проекта, то тут нефиг заморачиваться.

-~{}~ 09.02.10 22:39:

>> Избыточная декомпозиция - это когда у класса нет четкой зоны ответственности

А, понял, о чем ты. Ну это просто говенно спроектированная архитектура, там не только с декомпозицией нелады. Было у меня года три назад такое, писанное авралом за трое суток почти без сна. Потом смотрел и думал "какой идиот это писал, и что это вообще делает?" :)
 
Сверху