ФорумПрограммированиеPHP для идиотовPHP и ООП → Компромис при реализации конструкторов.

Компромис при реализации конструкторов.

  • Rotten

    Сообщения: 2243 Репутация: N Группа: Адекваты

    Spritz 29 сентября 2010 г. 20:22

    Есть пара связанных класов.

    class FileCopier
    {
    private $cf;
    private $df;

    public FileCopier($copyingFiles, $destFiles)
    {
    $this->cf = $copyingFiles;
    $this->df = $destFiles;
    }

    // тут другие методы…
    }

    class FileRemover extends FileCopier
    {
    private $delFile;

    public FileRemover($copyingFiles, $destFiles)
    {
    parent($copyingFiles, $destFiles);
    // тут реализую своё…
    }

    // тут другие методы…
    }


    Есть одна херня: в классе FileRemover мне не нужно использовать такой конструктор(с 2мя параметрами), который описан высше.
    Мне нужен конструктор

    public FileRemover($delFiles)
    {
    parent($copyingFiles, $destFiles); // не пойдет, потомучто эти параметры нужно получить извне…

    }

    И с этим затыком мне нужно обязательно реализовать конструктор предыдущего родительского класса. Но я не реализую его, потомучто планирую брать на вход лишь один параметр, которого мне только и нужно…

    Я могу тупо унаследовать конструктор родителя и н епарится: просто второму параметру присвоить null. Но мне нужно явно это все различать.
    Вроде можно также в родительском обьявить еще один конструктор на вход с 1м параметром - и его тупо заделлегировать в дочернем. Но тут портится вся логика: родителю не нужен конструктор дочернего ксласса - каждый клас должен обладать своим конструктором… ибо выйдет каша и бардак.

    Подойдет ли тут какойто паттерн типа адаптера? Интересно как его реализовать… тогда.. В голову чтото не лезит…
  • Nyaah

    Сообщения: 574 Репутация: N Группа: Джедаи

    Spritz 29 сентября 2010 г. 20:28, спустя 6 минут 53 секунды

    а) конструкторы типа ClassName deprecated
    б) накуя тут наследование вообще неясно
    в) можно передавать в конструктор массив, типа $options = array('source' => '/path/to/file', 'dest' => '/path/to/copy'); тогда можно в конструктор ремувера закидывать массив из одного значения
    г) если очень хочется фабрику, то нужно сделать интерфейс общий, а нужен он тут или нет сам решай исходя из задачи, из того какие исходные данные ты дал, тут ООП вообще нафик не всрался =)
    Work, buy, consume, die
  • LIFF

    Сообщения: 188 Репутация: N Группа: Адекваты

    Spritz 29 сентября 2010 г. 20:30, спустя 2 минуты 1 секунду

    Помоему у тебя структура классов неправильна). Да и  пых 4 уже устарел вроде.
    Спустя 51 сек.
    блин, не успел
  • Trej Gun

    Сообщения: 5305 Репутация: N Группа: в ухо

    Spritz 29 сентября 2010 г. 21:19, спустя 48 минут 32 секунды

  • Rotten

    Сообщения: 2243 Репутация: N Группа: Адекваты

    Spritz 29 сентября 2010 г. 21:25, спустя 6 минут

    Nyaah,
    а) без разницы. Это просто наглядный прием, общий по теории программирования в данном контексте. В нем - главное уловить суть.
    б) надо. На самом деле в классе-родителе есть докуя таких методов и полей, которые и понадобятся потомку(я этот код сюда просто не копировал - не имеет отношения к теме). Можно без наследования, но тогда придется дублировать докуя кода пахана.
    в) что то похоже на способ из null-значением. Но все равно спасибо… за идею…
    г) неее… фабричный паттерн тут не совсем к месту.. Нужно в конструкторе потомка реализовать уже готовый конструктор, правда на основе предка…

    Спустя 84 сек.
    CTAPbIu_MABP, спасибо, почитаю с интересом)..
  • Nyaah

    Сообщения: 574 Репутация: N Группа: Джедаи

    Spritz 29 сентября 2010 г. 22:27, спустя 1 час 2 минуты 8 секунд

    Тут проблема в том, что наследовать тебе нужно не FileRemover от FileCopier, а скорее FileRemover и FileCopier от какого-нибуть абстрактного ФайлВоркера, в паренте реализовать методы, реализующие общие задачи, а в детях уже непосредственно удаление и копирование. Просто копирование и удаление это несколько разные задачи, на мой взгляд, и наследовать одно от другого как-то глупо
    Work, buy, consume, die
  • Trej Gun

    Сообщения: 5305 Репутация: N Группа: в ухо

    Spritz 29 сентября 2010 г. 22:59, спустя 32 минуты 13 секунд

    Nyaah, вообще все можно реализовать одной операцией записи. дисскусии на эту тему были гдето на форуме.

    таки вам надо прочитать мою ссылку

    и таки copy и remove это методы утилитного класса которые принимают в себя объект файла

Пожалуйста, авторизуйтесь, чтобы написать комментарий!