Значит объясню в чем же вопрос. Я пишу учебный проект, некую программу, которая управляет Карточками Обращения Клиента ( Далее - КОК). Клиент обращается в компанию с некой проблемой, на него открывают карточку, в ней описывается проблема, далее передают её в другой отдел где устанавливается приоритет, КОК переходит в тех. отдел там пытаются решить проблему. Вобщем с момента создания, КОК постоянно меняет статус: - новый, установлен приоритет, в процессе обработки и т.д. У каждого отдела, есть возможность менять статус КОК, например  Админ может создать КОК, Менеджер устанавливает ему приоритет, техник устанавливает его в состояние  обработки и т.д. Естественно, то что позволено одному, не позволено другому и наоборот. Первое, что приходит в голову, это объявить в объекте КОК  флаги, которые будут обозначать статус КОК. Отсюда следует, что нужно делать switch\case статусу, дабы узнать последовательность действий, в одном случае одно происходит, в другом другое. Например: если объекту КОК присвоен приоритет, то он доступен технику, а если нет, то только менеджеру, который установит приоритет, однако менеджеру доступны так же те, которые уже обработаны техником, менеджер может их удалить и т.д.  

В ВУЗе же мне сказал препод, что switch\case это не ООП. Т.е. пользоваться им можно, но в крайне редких случаях. Решение же он предложил следующие: создать объект БейсКОК, из которого наследуются объекты - НьюКОК, ПроцессКОК и т.д. При изменение статуса, удалять существующий и создавать вместо него новый объект нужного типа. Тип == Статус. 

Вот я думаю, а не дороговато ли выходит, каждый раз создавать новый объект при изменение статуса КОК?

И вообще, верно ли, что switch\case указывает на процедуральное программирование, и в ООП практически не используется?

Если, у кого есть третье решение моего примера, буду очень рад и благодарен.    
  

Это сообщение отредактировал(а) Arat - 18.7.2007, 18:00

я использую, где удобно использовать  

что то я не очень понял задачу (особо не вчитывался), но во многих случаях вместо switch/case (особенно если вариантов много) удобнее юзать std::map

дорого. но для учебной программы можно и не замечать.

нет. вооще-то swith и ООП вещи параллельные. и оно другому не мешает.

Конечный автомат.

zkv, спасибо   

Ребят, если описал задачу путанно, так скажите, просто старался из всего проекта выбрать  именно конкретный кусок, без углубления во все нюансы.

Добавлено @ 18:16

Вот это не очень понял, если можно подробнее. 

Это сообщение отредактировал(а) Arat - 18.7.2007, 18:17

Я предлогаю сначало создать единственный класс
Сard, а уже потом создать иерархию приоритетов StatusN с
базовым классом BaseKOK 



а в коде домустим



а потом все будет определятся от начинки StatusN
Например, допустимые в данном приоритете действия(права), которые я не смог 
запрограммировать без более детального условия задачи   

Я бы посоветовал сначала все спроектировать (порисовать например - мне помогает).
иначе препод...  

Добавлено через 5 минут и 14 секунд
Ошибки: нехватает ';'



Извини в блокноте печатал   

Имхо, надо делать в обратном направлении. Т.е. создается иерархия классов kok1...kokN. Причем, у kokN есть публичный конструктор, а у остальных только защищенные. Админы могут создавать эти kok'и. При создании экземпляра этого kokN у него выставлен конструктором статус new_kok. Менеджеры работают только с экземплярами класса kok(N-1), поэтому им доступны деструктор и один метод - установить приоритет и так далее. В итоге, тебе не надо каждый раз пересоздавать этот kok, ООП остается, и switch не используется.

Извини, а его потом в switch проверять

Не в обиду, но заменять switch-конструкцию должен механизм виртуальных функций.

bsa, если я чего-то не понял, тогда опиши поподробнее насчет статуса new_kok 

http://en.wikipedia.org/wiki/Finite_state_machine

Пусть препод убьётся об стену...
С сегодняшнего дня не использовать char[] потому что это не ООП!!!!

Друг мой.. ООП не спасёт мир.
Это одна из теорий программирования и не совсем однозначная.
 Разные проекты, разные задачи, разные методы...

Добавлено через 7 минут и 58 секунд
Блин я до сих пор в шоке....  

а ты не думаешь что эта задача имено на изучение ООП ?

ООП не учится путём убивания в человеке зачатков рацонализма, ты об этом не задумывался...
ООП не способ хитро*бнуться, ООП способ думать глобально,  масштабно и абстрактно... А switch это одна из основных конструкций зачастую неотъемлемая....

Вместо Switch iиспользуй If ... else ЭТО ЧИСТОЕ ООП...

Добавлено через 1 минуту и 58 секунд
switch не имеет ни какого отношения к процедурноориентируемому программированию, это БАЗОВАЯ КОСТРУКЦИЯ ЯЗЫКА

Добавлено через 2 минуты и 51 секунду
Такая же как if, while ,for

Дорогой мой, а ты в институте учился? А на кого учился? У тебя было программирование? И как тебя там этому учили помнишь?

Помню, пришла сюда девушка и попросила помочь с программой. Надо было решить какую-то задачу с помощью рекурсии. Долго народ бился, но так и не придумали такого способа - ну не решалась она таким образом и все тут.

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

bsa
ООП меня учил товарищь Шаляпин Юрий Павлович, человек зачастую неодекватный и мнимый, но...
И меня смутила не поставленная задача и предложенное решение, А заявления касающееся switch...
Меня программированю учили на алгоритмах, даже с рекурсией, но не как не на изнасиловании ума...
Практика показывает, главное в мире простота.

Господа это ИМХО, не будте так серьёзны в вопросах этики

Добавлено через 2 минуты
Daevaorn, 
человек был сбит с толку больше не тем что ООП, а тем что во второй части вопроса ИМХО

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


Это сообщение отредактировал(а) DogStyle - 19.7.2007, 21:50

Чистый ООП это миф  Надо писать так что-бы можно было разобраться. Если читабельнее написать на пару строчек switch.. case пиши switch вместо насилования архитектуры классов ради трёх вариантов