Как расширить возвращаемый библиотекой класс?

Question

[ninjjjja]

Добрый день.

Есть некая php-библиотека, которая реализует некие классы:

class Foo {
	public $bar;

	function __construct( ) { $this->bar = new Bar; }	
	function getBar( ) { return $this->bar; }	
}

class Bar {
	// some other code
}

Клиентский код в свою очередь хочет расширить класс Bar своим кастомным кодом:

class BarEx extends Bar {
	// some other code
}

Напрямую он этого сделать не может, поскольку библиотека все равно будет возвращать Bar, а не BarEx.

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

Вопрос: каким образом решается такая проблема? Например, DomDocument для этого имеет метод registerNodeClass - но как он работает под капотом и нормальная ли это практика?

Должен ли создатель библиотеки давать возможность перезаписывать внутренние классы, и создавать объекты не как new Bar, а, например, как new static::CustomBarClassName?

Нормальный ли это код?

class Foo {
	static protected $BarClassName = Bar::class;
	public $bar;

	static public function registerBarClass( $new_class ) {
		static::$BarClassName = $new_class;
	}

	function __construct( ) { $this->bar = new static::$BarClassName; }
	function getBar( ) { return $this->bar; }
}

class Bar {
	// some other code
}

// ...

Foo::registerBarClass( BarEx::class );
$foo = new Foo;
$bar_ex = $foo->getBar( );

Comments

[Виталий Артемьев]

Пришли ссылку на библиотеку

Answer 1

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

Я понимаю что ты рос в местах лишения интернета т.ч. для начала гугли "php factory template" и/или "php builder template".

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

это говорит о том, что ты не до конца(или вообще) понял идею шаблона facade.

Нормальный ли это код?

Нет, не надо смешивать статику и объекты + нет проверки наследственности класса. Используй классы-фабрики\строители вместо аналогичных методов или внедрение зависимостей(что-то вроде https://php-di.org)

Comments

[ninjjjja]

Хорошо, давайте поставим вопрос по-другому: какая магия происходит внутри (я не умею читать код на C) DOMDocument::registerNodeClass, чтобы заставить DOMDocument::getElementById возвращать не просто DOMElement, а любого его кастомного наследника по желанию пользователя библиотеки?

Потому что я не вижу, чем в этом случае мне поможет фабрика, билдер и/или di.

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

ninjjjja,

я не умею читать код на C

а ты хоть пробовал?

Потому что я не вижу, чем в этом случае мне поможет фабрика, билдер и/или di.

как говорил один юморист: видишь плинтус? это твой уровень :( совсем не стараешься

возвращать не просто DOMElement, а любого его кастомного наследника по желанию пользователя библиотеки?

это обычная реализация шаблона factory method/фабричный метод
мне лень смотреть код, там что-то вроде TagFactory::createTag():

class TagFactory
{
    protected $tagClasses = [];
    protected $document;

    public function __construct(Document $document)
    {
        $this->document = $document;
    }

    public function setTagClass(string $tag, string $class): self
    {
        if (!is_subclass_of($class, TagInterface::class)) {
            throw new InvalidArgumentException("Class $class not instance TagInterface");
        }
        $this->tagClasses[$tag] = $class;

        return $this;
    }

    public function createTag(string $name, iterable $attributes = [], string $content = null): TagInterface
    {
        if (isset($this->tagClasses[$name])) {
            $tag = new $this->tagClasses[$name]($this->document, $attributes);
        } else {
            $tag = new Tag($this->document, $name, $attributes);
        }

        if ($content !== null) {
            $tag->setContent($content);
        }

        return $tag;
    }
}

Answer 2

[Dr03d]

Лисков грустя слезинку утирает.
Первый код жестковат, вместо Bar подсунуть BarEx не позволит. Но если бы вместо него было что-то вроде

class Foo {
  protected $bar;

  function __construct($barInheritor ) { 
    if (is_subclass_of($barInheritor, 'Bar') {
      $this->bar = new $barInheritor; }
    }	
  function getBar( ) { return $this->bar; }	
}

уже было бы легче.
Нужно только не забывать про Пространства имён.

Comments

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

Лисков грустя слезинку утирает.

это женщина если чо

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

да, кстати раз уж помянул старушку, то при чем тут вообще она?

[Dr03d]

Антон Шаманов, естественно, женщина. А обязательное НЕИЗМЕНЕНИЕ наследниками функционала базового класса – епархия именно её Принципа Подстановки.
А ТС и планирует напропалую подтыкать вместо базового класса его наследников.

Кстати, то, что библиотека должна на входе принимать не только определённый класс, но и его наследников, хорошее напоминание всем нам.

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

А ТС и планирует напропалую подтыкать вместо базового класса его наследников.

если на кассе в магазине вместо тани стоит маня, это не ничего не меняет - она работает все тем же кассиром т.е. изменение кода не означает изменение функционала (по крайней мере в данном случае). Тут проблема скорее в том, что подобный фабричный метод нарушает принцип ответственности т.е. взятый за основу DomDocument является скорее антипаттерном "holly class" как и сама идея переноса не самого удачного(по мнению самих же авторов) js кода на php.