Да, это не очень объектно-ориентированный. Было бы лучше реализовать метод на классах. Может быть, что-то вроде
-(BOOL)shouldPopTwo;
, а затем
if ([previousView shouldPopTwo]) { ... }
И тогда каждый подкласс может быть реализован так, как ему нужно.
НО
В большинстве случаев я думаю, что вам следует избегать соблазна строить иерархии классов с помощью UIViewControllers. Контроллеры, как правило, являются наименее многократно используемыми объектами в настройке MVC, поскольку они предназначены для очень конкретного определения поведения и сопоставления его с конкретными объектами модели. Конечно, иерархии могут быть построены (как они были в SDK), но структура, функция и абстракция должны быть очень тщательно спланированы и построены.
Вместо этого вам, вероятно, следует создать повторно используемые UIViews, а затем реализовать различные UIViewController, чтобы определить, как приложение должно использовать эти ответы и реагировать на них.
В ответ на комментарии ниже:
Звучит так, как будто вы пытаетесь использовать навигационный контроллер способом, для которого он не предназначен, и фактически ваши последние два контроллера представления должны быть единым контроллером представления. Контроллер представления в первую очередь предназначен для управления полноэкранным контентом. Если я правильно понимаю, в вашем случае у вас есть сегментированный элемент управления, который должен оставаться на экране и нести ответственность за переключение содержимого в остальной части доступного пространства. Я хотел бы предложить, чтобы у вас был один контроллер представления, и это представление будет содержать сегментированный элемент управления и «холст», который будет использоваться для отображения альтернативных представлений. Контроллер представления будет содержать ссылки на представления, которыми он управляет, чтобы он мог включать и выключать их (если вам нужны анимации в стиле UINavigationController, вам придется реализовать это самостоятельно).
Наконец, вам нужно решить: может ли этот контроллер одного представления действовать как контроллер для двух подпредставлений? Или у каждого представления должен быть свой контроллер? Если этот подкласс UIViewController является одноразовым и предназначен только для этих двух видов (скажем, PhotoMapViewController), вы можете выбрать первый, более простой вариант. Если вы хотите, чтобы это работало с любым UIView (скажем, SegmentedControlViewController), то каждое представление должно иметь свой собственный контроллер NSObject (не UIViewController). Из яблочных документов:
Примечание: если вы хотите разделить представление
иерархия на несколько подрайонов и
управлять каждым по отдельности, использовать
универсальные объекты контроллера (пользовательские
объекты, сходящие с NSObject)
вместо просмотра объектов контроллера
управлять каждым подрайоном. Тогда используйте один
просмотр объекта контроллера для управления
универсальные объекты контроллера.
http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/AboutViewControllers/AboutViewControllers.html
Но для этого потребуется значительно больше абстракции и настройки.
Если общая цель состоит в том, чтобы (я предполагаю) отобразить коллекцию фотографий, в первом случае в вызывающем контроллере представления у вас может быть такой код:
NSArray *photoCollection = model.myPhotos;
PhotoMapViewController *pmViewController = [[[PhotoMapViewController alloc] initWithPhotoCollection:photoCollection] autorelease];
[self.navigationController pushViewController:pmViewController];
и PhotoMapViewController: UIViewController будет отвечать за создание и инициализацию двух представлений, которыми управляет его сегментированный элемент управления.
Я не буду вдаваться в код второго случая, потому что он намного сложнее.
Наконец, обратите внимание на ООП принцип предпочтения композиции перед наследованием, чтобы увидеть более широкую перспективу того, почему вы могли бы действовать таким образом вместо вашей первой реализации.
Каждый раз, когда вы начинаете устанавливать иерархию классов, вы должны спросить себя - действительно ли это подкласс? а затем остановиться и спросить себя - нет, подождите, это действительно подкласс ?? :) Удачи!