switch и ООП

Доброго всем времени суток.
Занимаюсь активным внедрением ООП в свой мозг и столкнулся с вот какой проблемой. Как правильно организовать вызов тех или иных методов к-либо класса?

Приведу пример. Класс User в котором есть методы регистрации, авторизации, редактирования и удаления пользователя (к примеру). Есть 4 формы соответственно для регистрации, авторизации, редактирования ну и типа удаления.
Классический вариант для процедурного программирования когда в форме стоит
action="test.php?act=register",
action="test.php?act=login" и тд. В файле test.php мы пользуем switch и запускаем ту или иную функцию. Здесь все предельно ясно. Но вот как быть с ООП? Пользоваться ли switch и если "да", то где его пользовать? После создания экземпляра класса или в теле класса, передавая туда $act? Или всеже есть другой способ? Спасибо.

Дергать статические функции классов точно так же как и в процедурном стиле.
Потому как ООП здесь и не пахнет.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

А можно про запахи поподробнее?

ну для начала стоит понять, что ООП стоит на 3 китах: наследование, инкапсуляция и полиморфизм. при отсутствии одного или более из китов это уже не ООП. в ООП все есть объект а объект это переменная определенного типа (в ООП под типом часто подразумевают класс). у объекта есть поведение (методы) и состояние (свойства)

Чем пахнет?
-----------------------------
spirit вместо switch можете посмотреть в сторону method_exists
(Добавление)
((мы мягко подойдем к осознанию того, кто такие роутер и контроллер))

-----
Шта? Репозиторий?

Неверно. Суть ООП - это инкапсуляция. Остальное -удобные фишки.


Вообще то класс - всегда есть тип.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Еще бы объяснить доходчиво, что это за "инкапсуляция" такая..
Ато вон в соседней теме уже наинкапсулировали до того,
что юзер наследует мускуля..

-----
Шта? Репозиторий?

сижу созерцаю... смысл понятен, практического применения пока не вижу(

темный лес...

в данном случае не имеет смысла -методы все известны наперед.


в половине тем где БД упоминается с ООП норовят сделать класс для Mysql и наследовать от него объекты. Этакий гибрид синглетона с active record

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Предположим у нас в урле всегда ожидаецца вот так:

/?class=xxx&method=yyy

Ну ок, типа не-до-роутер (безо всяких "меджик" __autoload):

-----
Шта? Репозиторий?

DeepVarvar, все, понял, но caballero прав -


меня просто беспокоит вот что. У меня весь код внутри классов и switch там же а в обычном файле только автолоад, создание экземпляра и вызов метода в котором лежит switch:
class.test.php

caballero, а я считаю что всегда нужно проверять есть ли метод,
даже когда они известны.
И если метода нет - бросать исключение.
Пусть для данной ситуации их четыре.
Но доступных контроллеров/методов может быть и десятка два-три..
И чтобы не лазить больше никуда и не переписывать/дописывать,
лучше сразу сделать не-свитч.

-----
Шта? Репозиторий?

в случае если нет других проверок на валидность запроса то да - проверять придется.
или прсто дергать как есть - исключение само выскочит.


лучше побеспокойся о другом. Экземпляр чего ты создаешь и на фига ты его создаешь.
После этого проблеммы решатся (ли отпадут) автоматически

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Нуу это спорно. Например, я считаю, что главный кит - инкапсуляция, потому что грамотная инкапсуляция в первую очередь позволяет снизить сложность проекта.
Чрезмерное наследование - наоборот увеличивает сложность (правда, без него никак не обойтись). Но обходиться на маленьких задачах без него вполне можно.
(Добавление)
О, я не один так считаю
(Добавление)
Попробую. Есть логика. Например, логика того, как мы идем вечером с работы домой.
1. Сохранить наделанное.
2. Надеть куртку.
3. Идти, идти, пока не придешь.
Это три функции. Разберем, например, вторую. Ее реализация будет примерно такой:
2.1. Поднять руку, снять ее с вешалки, повернуть к себе нужной стороной, сунуть в нее руки, проверить, вошли ли руки удачно (если не удачно, то бросить ексепшн и попробовать заново), застегнуть.
Вот функция НадетьКуртку инкапсулировала в себя сложный процесс. Вся эта сложная вещь скрыта в том, что описано в 2.1 (это приватные методы класса. Ими не положено пользоваться из вне и о них не нужно даже думать), а мы беззаботно пользуемся публичным методом НадетьКуркту нашего класса.
А как разработчик класса, мы можем менять, оптимизировать эти приватные методы, инкапсулированные от пользователя класса, никак не мешая ему пользоваться старыми добрыми публичными методами, которые мы ему дали.
Часто мы можем сами выступать и как разработчик класса, и как пользователь, инкапсулировав его сложность на этапе разработки и дальше беззаботно пользоваться его интерфейсом(его публичными методами).
Вот. Это конечно неполное такое описание, но какое-то накатал

А я добавлю еще так:
Инкапсуляция:
Есть объект "машина" и объект "водитель". И вот водителю (блондинке),
совершенно не нужно знать как работает двигатель внутреннего сгорания.
Она просто давит на педали (у нее АКПП) и крутит руль.
Вот раньше чтобы быть водителем нужно было знать как там все внутри работает,
сейчас уже нет.
----------
Не правильное наследование:
Никогда не было так, чтобы машина стала думать за водителя.
Ну положим в настоящее время некоторые зачатки "автопилота" уже существуют.
Но вот чтобы человек пил бензин, прогревался зимой, тарахтел под окнами (бабушки на лавочках не в счет) и "делал ноги колесом" - точно никогда не будет.

Если взялись наследовать, нужно подумать а нужно ли это.

-----
Шта? Репозиторий?