У меня возник такой вопрос: почему все создают экземпляр определенного класса контроллера, а не изначально объявляют класс контроллер как статический?.. Ведь по идее, всё равно ж нам не понадобится использовать две копии контроллера в приложении с разными данными... Как вы считаете?..

Не совсем понимаю ваш вопрос. Можно увидеть пример?

Ну смотрите, допустим, фронт контроллер вызывает определенный контроллер в зависимости от запроса пользователя, например, посетитель переходит по ссылке index.php?c=catalog&act=list, сразу вызывается фронт контроллер который создает нужный экземпляр класса, в нашем случае CatalogController

$catalog = new CatalogController();
$catalog->tralivali();

зачем создавать экземпляр контроллера, почему не использовать статические контроллеры, тогда было бы:

CatalogController::tralivali();

Основная и думаю главная причина здесь в том что у нас не создается экземпляр класса, а следовательно:

1. В этом статическом методе должна быть вся реализация конкретного функционала, так как из статического метода мы не можем сделать так:



Если метод tralivali, будет статическим так сделать не получиться, если только в статическом методе не создавать экземпляр класса.

2. Также из статического метода нельзя обратиться к не статическим свойствам класса,  а соответственно мы не можем хранить состояние, точнее мы должны его тащить за собой.

3. Из 1 и 2 следует, что мы теряем такой мощный инструмент как наследование.То есть вместо того чтобы написать один раз повторяющийся код в классе родителе, мы его повторяем во множестве реализаций контроллеров в нашей системе.

думаю можно ещё перечислить несколько причин, почему так делать не стоит.

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

Вообще как я понимаю у вас возник такой вопрос потому, что ваши преподаватели (или учебник который вы прочитали) не объяснили вам зачем нужны статические методы. Вместо этого они объяснили, что они есть и все.

Это сообщение отредактировал(а) krundetz - 18.8.2011, 15:12

По 2 и 3 почитайте про основы ООП внимательнее.

В общем можно обойтись и статическими классами, но некоторый функционал все-таки теряется.
Так как статический класс не инициализируется то нет возможности использовать конструкторы и деструкторы, также нет и магических методов __set или __get.
Во многих фреймворках к обьекту динамически присваиваются обьекты других загружаемых классов чтобы можно к ним обратится через $this->user например, ну и много чего еще...

Shogun, вы видимо меня совсем не поняли. Фразой:

Я имел в виду что нельзя сделать вот так:


Ваш пример конечно обходит, это ограничение, но сразу возникает вопрос. А зачем в вашем примере класс вообще нужен? Делайте тогда так:

В посте выше я это отметил:

Заметьте я не говорю что так делать нельзя, я говорю что вы просто отказываетесь от ООП.

По 2 пункту, посмотрите вот на этот код:


По 3 пункту, я опят же не говорю что оно невозможно,  я говорю что мы его теряем.

Shogun, мне было бы интересно продолжить с вами дискусию, если вам тоже, то жду ваших комментариев к вышеописанному.

Это сообщение отредактировал(а) krundetz - 22.8.2011, 22:30

А можно и со статическими контроллерами работать...

Мне кажется главная причина именно потому что так принято...

Идет раутинг, создается instance контроллера, вызывается действие, далее вызываются модели и тп...

---

Единственное что приходит в ум:

проблем с инкапсуляцией нету


Но вот какбыть с магическими методами?

вы правы, да и Shogun уже показал способ инкапсулировать вызов статических методов. Мне интересно другое, насколько оправдано использование классов у которых есть только статические методы? Какова их область применения? Возможно проще и разумнее заменить такие классы набором обычных функций?


Я так понимаю что, никак. Такие магические методы как, __get() и __set() работают со свойствами. А соответственно нам нужно инстанцирование класса.

Добавлено через 3 минуты и 10 секунд

а если понадобиться?

а что Singleton уже не в моде?

Добавлено через 1 минуту и 42 секунды

нет

контроллер не должен хранить данные, а значит и не надо создавать 2 экземпляра   

А у Singliton только статические методы? По моему, в классическом Singleton есть один статический метод, который используется для получения экземпляра класса, либо создания экземпляра если он ещё не создан.

почему?

а где я говорил о данных? Я говорил о состояние? Или вы считаете что данные и состояние это одно и тоже?

 Начнем с того, что теоретически статические контроллеры стали доступны только в PHP 5.3, т.к. только в нем появилось позднее связывание.
Но смысл изображать объект классом когда можно воспользоваться обычным объектом?

Тема напоминает "Но ведь можно ложки держать попами и друг друга кормить". Можно, но руками то удобнее держать?

Эта проблема не семантического порядка, а проектного.
Статический метод инкапсулирует в себе знания  и алгоритм работы на уровне класса! а не экземпляра. То есть дочерние классы так же, если вызывается статический метод, работают на уровне родительского класса (не важно что он был унаследован),  в противовес своим внутренним методам - интерфейсам, которые являются частью дочернего класса и работают на уровне не класса а экземпляра. Отсюда и строятся две диаграммы в UML  диаграмма объектов и диаграмма классов. Если смотреть со стороны "клиентов", используемых эту архитектуру: это позволяет обеспечить выполнение статического интерфейса исключительно Определённого класса, что в принципе создаст большую связность, но если это укрепит архитектуру то только обеспечит уменьшение архитектурных ошибок, сори за тавтологию.  

нет

  

а что раз вы не говорили то и я не должен?

если у класса есть только методы, то почему его методы не сделать статическими или Singleton?


а что, нет?

502, 
Цитата(krundetz @  26.8.2011,  11:57 Найти цитируемый пост)
Или вы считаете что данные и состояние это одно и тоже? 
а что, нет?

Глубокое заблуждение.

>если у класса есть только методы, то почему его методы не сделать статическими или Singleton?

Странное понимание, после таких "а почему бы не сделать" архитектура трещит по швам. Выбор должен быть обоснован и аргументирован, и требуется несколько проектных решений. Кстати интересное сравнение сделать методы статическими или Singlton (два совершенно разных аспекта, один решение по конкретному методы, второе решение создание целой абстракции)

Это сообщение отредактировал(а) Sentox - 27.8.2011, 22:28