Я работаю над библиотекой, которая имеет довольно много классов, которые все спрятаны центральным классом. Этот центральный класс должен вызывать определенные методы для других классов для целей настройки/конфигурации. Эти методы должны быть общедоступными, чтобы центральный класс мог их вызывать, но я не хочу, чтобы пользователи вызывали эти методы (поскольку это может вызвать нежелательное поведение).PHP ограничивает вызов общедоступных методов
Одно из предложений, сделанное моим другом, состояло в том, чтобы использовать конструктор с параметрами, которые могут быть настроены во время строительства. Для целей этой библиотеки это невозможно. Рассматриваемые классы предназначены для расширения, и я не хотел навязывать какие-либо странные требования к параметрам конструктора, если пользователи хотят иметь свои собственные конструкторы. Еще сложнее то, что некоторая информация, используемая для конфигурации, недоступна для пользователя. Я должен был бы сделать его доступным для пользователя и верю, что он вернет его в соответствующие классы во время строительства.
В настоящее время мое решение состоит в том, чтобы придать этим методам что-то и отметить пользователям не вызывать методы с указанным префиксом. Это «гибкий», чтобы позволить мне добавлять более ограниченные методы, но он все же делает предположение, что пользователь будет следовать моим инструкциям. Это также не самые элегантные решения.
Мне было интересно, есть ли способ ограничить эти методы. Я подумал о добавлении в них строки, которая проверяет, был ли это центральный класс, вызывающий их, но это тоже не похоже на лучшее решение.
Редактировать: Я должен объяснить цель этой архитектуры. Каждый класс выполняет определенную задачу в стеке операций. Задача центрального класса состоит в том, чтобы командовать одним классом выполнять свою задачу, собирать результаты и распределять результаты другим классам, которые в них нуждаются. Затем класс переходит к следующему классу и делает то же самое. Как выполняются задачи, зависит от расширенного класса. Методы, которые я хочу ограничить, - это те, которые помогают в диспергировании результатов. Надеюсь, что мои намерения станут более ясными.
Запрет уродливых хаков, вы не можете ограничить, кто вызывает ваши методы. Похоже, что ваши занятия не очень хорошо разработаны. Каждый должен стоять сам по себе и не быть зависимым от того, чтобы его называли каким-либо особым образом. – deceze
Вы не можете блокировать доступ к общедоступным методам, поэтому они называются общедоступными. И если у вас есть один класс, который использует большинство других классов в системе, то вы, вероятно, строите антипаттерн Бога-объекта. http://en.wikipedia.org/wiki/God_object. Лучше, чтобы каждый класс был автономным и отвечал за собственную конфигурацию. – GordonM
Почему бы не «расширить» родителя и не использовать защищенные методы? –