У меня есть система моделей:
abstract class R00_Model_iUnique { } abstract class R00_Model_iFamilyUnique extends R00_Model_iUnique { } // for models with hierarchy abstract class R00_Model_iTaggedUnique extends R00_Model_iUnique { } // for models with tags // and, for example class R00_Model_User extends R00_Model_iUnique { } class R00_Model_Comment extends R00_Model_iFamilyUnique { } class R00_Model_Post extends R00_Model_iTaggedUnique { } Будет R00_Model_iCommentableUnique, и R00_Model_Post хочет унаследовать от него. Но это невозможно, оно уже унаследовано от R00_Model_iTaggedUnique, и я не думаю, что умно унаследовать R00_Model_iTaggedUnique от R00_Model_iCommentableUnique или наоборот. Я придумал только одну идею, как ее реализовать, но у меня есть некоторые сомнения. Может быть, вы можете рассказать мне о некоторых умных методах или критиковать этот метод?
Я придумал, чтобы сделать R00_Model_i * Уникальным не классы, а интерфейсы, и создать вспомогательные объекты, такие как R00_Model_Helper_iUnique (может быть, это обычный патерн, и есть классное имя, я не думаю, что «Помощник» будет там круто? ). Затем в R00_Model_iUnique создайте __call (), который проверяет все интерфейсы вызываемого объекта и ищет вызываемый метод в помощнике.
Или слишком много отражений и других злых медленных вещей, не так ли?
Вы находитесь в правильном направлении, используя интерфейс и помощники (состав).
Это как раз и одна из причин того, почему из принципов книги шаблонов проектирования (GoF) является «Предпочтительная композиция над наследованием» .
Композиция предоставит вам гибкость, которую вы должны использовать для разных классов. В том классе, который вам нужен.