Как создать класс с копией статических методов другого класса?

Question

[xolnimda]

Есть класс Functions

У него статические методы

Нужно создать класс Html с копией методов класса Functions

class Html extends Functions {

}

Можно ли как то указать какие именно методы должен наследовать класс Html?

В классе Html не требуются все методы класса Functions

Answer 1

[Сергей Протько]

вот скажите, зачем вам классы? только потому что автозагрузки функций нету?

class Function {
    public static function foo() {
         return 'foo';
    }
    public static function bar() {
         return 'bar';
    }
}

class Html {
    public static function __callStatic($name, $arguments) {
         // разрешаем вызывать только foo
         if (!in_array($name, ['foo'])) {
              throw new \RuntimeException(sprintf('Unable to find method %s in class %s', $name, __CLASS__));
         }

         return call_user_func_array(['Functions', $name], $arguments);
    }
}

Html::foo() // 'foo'
Html::bar() // exception

только добавьте в phpdoc аннотации методов

либо сделайте так:

class Html {
    public static function foo() {
           return Functions::foo();
    }
}

так будет правильнее.

p.s. я не знаю зачем вы это делаете, просто знайте. Вы делаете нехорошие вещи.

Comments

[Павел Волынцев]

@Fesor, хороший-не хороший - это дело второе. А последний пример - самый правильный.

Answer 2

[Иса]

Ukazhi te metody v klasse 'Functions' kotorye ne nuzhny 'private'

Comments

[Сергей Протько]

Pisat` translitom eje davno ne modno

[Иса]

V dannyy moment ne mogu perekluchit' prosto

[xolnimda]

вариант не подходит так как класс Functions дополняется
не буду же я постоянно писать в класс Html запрещенные методы

Answer 3

[Kjuri]

что мешает, если "не требуются все методы" и не использовать их? или есть причины, чтобы их и нельзя было использовать, даже если захочется? Как вариант - создать абстрактный суперкласс. т.е. над Functions создать еще класс, и уже на основе него создавать остальное. Определить в нем некие характеристики, которые обязательно нужны везде. А вариации уже у наследников прописывать. И Html будет дочерним элементом не Functions, а этого абстрактного суперкласса.

Answer 4

[Антон Шаманов]

Использовать трейты если версия php позволяет (с 5.4)

Comments

[Сергей Протько]

и куда тут трейты то воткнуть позвольте спросить?

[Антон Шаманов]

@Fesor Все очевидно - переместить универсальные методы класса Functions в трейты и наследовать их в Html

[Сергей Протько]

@SilenceOfWinter это не правильное использование трейтов. И бессмысленное.

[Сергей Протько]

@SilenceOfWinter бессмысленное потому что автор класса Html и Functions одно лицо, да и в трейтах должен быть только код проксирующий вызовы в другое место. Там не должно быть непосредственно реализации (можно но это не хорошо).

[Антон Шаманов]

@Fesor В php на данный момент это не совсем так, сейчас скорее применимо понятие "примесей":
`Трейты (англ. traits) - это механизм обеспечения повторного использования кода в языках с поддержкой единого наследования, таких как PHP. Трейты предназначены для уменьшения некоторых ограничений единого наследования, позволяя разработчику повторно использовать наборы методов свободно, в нескольких независимых классах и реализованных с использованием разных архитектур построения классов. Семантика комбинации трейтов и классов определена таким образом, чтобы снизить уровень сложности, а также избежать типичных проблем, связанных с множественным наследованием и c т.н. mixins.` php.net/manual/ru/language.oop5.traits.php
Собственно на данный момент это единственное возможное решение описанной задачи, никто не говорит плохо это или хорошо, вопрос об этом не стоял.

[Антон Шаманов]

@Fesor спорить не особо хочу, но сейчас трейты на самом деле так и используют - можешь посмотреть популярные фреймворки (yii, fuel)

[Сергей Протько]

@SilenceOfWinter fuel такой уж прям популярный фрейморвк. Есть разница между использованием трейтов как миксинов, и "хахерачу ка я из класса в трейт что бы реюзать могли". Это бездумное использование клевой фичи, которая в таком варианте приносит больше боли чем пользы.

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

[Сергей Протько]

@SilenceOfWinter лично я пользуюсь трейтами как синтаксическим сахаром при декорировании. Идея примерно та же что и у знаменитых ларавелевских "фасадов". Причем обычно только в контроллерах что бы небыло необходимости иметь какой-то дико жирный базовый класс.

[Антон Шаманов]

@Fesor У php процедурное прошлое, отсюда и все эти выверты в ООП. Насчет тестирования зависит от конкретной реализации, если там набор конечных методов, то никаких особых проблем не вижу. Трейты использую только в маленьких проектах (на большинстве серверов до сих пор версия 5.3). "что бы небыло необходимости иметь какой-то дико жирный базовый класс." я для этих целей DI в к контроллерах использую.

[Сергей Протько]

@SilenceOfWinter DI это хорошо, но у меня довольно специфичные компоненты есть (jms serializer в частности) и что бы минимизировать количество бойлерплейт кода связанного с генерацией контекстов я вынес все что связано с десериализацией/сериализацией запросов/ответов в трейт. Там метод достает из DI нужные сервисы, предает нужные параметры и количество кода в контроллерах, где используется этот трейт необходимое для обработки запроса снижается до одной строчки. Можно конечно вынести вообще это дело еще на уровень выше, но пока не вижу в этом смысла.

Ну и да, это все же очень маленький и редкий кейс, я крайне редко использую трейты.