2014-01-31 2 views
0

다양한 UI 기능을 구현하는 UIViewController을 만들었습니다. 사용자가 하위 클래스를 사용하여 setContents:getContents과 같은 몇 가지 메서드로 업데이트 할 수 있도록하기위한 것입니다.UIViewController 하위 클래스 호출 메서드

UIViewController 내에서 사용자가 자신의 하위 클래스 인 showPicker에 구현하려는 버튼을 누르면 메소드가 호출됩니다. ,

- (void)showPicker { 
    // Do what you want 
} 

이를 위해 :

나는 사용자들이이 방법으로 일을 통제 할 수있을 수 있도록하고 싶습니다, 그래서 그들은 단지 자신의 서브 클래스 내에서 구현해야한다고 생각 원래의 UIViewController에 같은 이름의 빈 메서드를 추가하고 헤더 파일에도 추가해야했습니다.

정확하게 원하는 것은 서브 클래스 UIViewController과 정확히 같고 viewWillAppear:을 구현하고 해당 메소드에서 원하는 것을 수행하는 것과 같습니다.

내 클래스의 버튼을 두 드릴 때 사용자가 제어 할 수 있도록하려는 경우 올바른 패턴입니까? 이 모든 일을 잘못하고 있니? 대의원을 사용해야합니까? 당신이 UIViewControllerviewWillAppear:으로 무엇을 모방하려는 경우

답변

1

, 당신은 기본 클래스에 showPicker의 아무것도 실시하지 않는 구현을 추가해야합니다. UIViewController.hviewWillAppear:에 아무것도 수행하지 않는 기본 구현이 있음을 나타냅니다.

대리인은 실제로 많은 부분을 단순화하지 않고 기본 클래스와 하위 클래스를 복잡하게 만듭니다. 그들은 추상적 인 방법보다 통지에 더 가깝습니다.

if ([self canPerformSelector:@selector(showPicker)]) { 
    ... 
} 

그것은 내 취향에 비하면 많은 컴파일시 안전을 제공하지 않지만, 다른과에서 책임의 대부분을 유지 : 여기

다른 옵션의 라인을 따라 뭔가를 할 수 있습니다 기본 클래스 하지만 그것은 당신의 기본 클래스에서 빈 메서드 구현으로 발견 할 수없는 것으로 나타났습니다.

기본 클래스의 추상 메소드에 빈 구현을 원하지 않으면 검색 가능성과 컴파일 타임 안전을 균형있게 조정하는 프로토콜이 더 적합 할 수 있습니다.

@protocol PickerProtocol <NSObject> 
- (void)showPicker; 
@end 

@interface SomeBaseClass : UIViewController 
    ... 
@end 

@implementation SomeBaseClass 

- (void)someBaseClassMethod { 
    if ([self conformsToProtocol:@protocol(Picker)]) { 
    [(id<PickerProtocol>)self showPicker]; 
    } 
} 

@end 

귀하의 서브 클래스는 옵트 인 그들은 당신이 모든 @required 메소드를 구현하지 않은 경우 컴파일러가 경고를 할 수 있도록 프로토콜을 구현 한 것을 선언.

@interface MySubClass <PickerProtocol> 
    ... 
@end 

@implementation MySubClass 

- (void)showPicker { 
    ... 
} 

@end 

이렇게하면 컴파일러에서 경고와 코드 완성을 표시 할 수 있습니다. 빈 기본 클래스 메소드만큼 간단하지는 않지만 하위 클래스가 일부 동작을 제공한다고 명시 적으로 선언 할 수 있습니다.

여기 또는 그저 유일한 방법이라면 빈 방법 접근 방식을 사용합니다. 함께 구현해야하는 메소드 그룹이 있다면 프로토콜을 사용합니다.

+0

우수 답변! 비어있는 메소드 접근 방법을 고수 할 것입니다. 사용하려는 메소드 중 하나 일뿐입니다. 다시 한 번 감사드립니다! –

1

하위 클래스로 설계된 클래스를 만드는 것은 효과가 있으며 잘못된 것은 아닙니다 (대부분의 프레임 워크는 이러한 클래스에 따라 달라집니다).이것이 실제로 당신에게 가장 좋은 선택인지 아닌지는 당신이 그 수업이 어떻게 사용되기를 기대하는지에 달려 있습니다. 당신은이 방법의 기본 구현을 제공 할

  • : 경우

    서브 클래스는 의미가 있습니다.

  • 슈퍼 클래스를 호출 할 if 및 when을 제어하여 서브 클래스가 기본 구현을 재정의하고 바꿀 수 있기를 원합니다.
  • 이 메시지는 수신 클래스와 만 관련이 있습니다 (예 : 결과 조치가 보통 컨트롤러 개인 메소드 또는 특성과 상호 작용할 경우). 그것을 다른 물체에 노출 시키면 그들 사이의 긴밀한 결합이 생겨 단일 책임 원리를 위반하게됩니다. 이 문제는 선택 사항입니다

    • : 경우

  • 은 다른 한편으로 대리인은 더 나은 선택이 될 수 있습니다.
  • 메시지는 송신 클래스의 책임이 아닌 우려 사항의 일부입니다. 아마도 컨트롤러가 사용자 의도 ("이 옵션 선택")를 결정했지만 그 의도에 따라 행동하는 것이 그 직업이 아닙니다. 적절한 경우 개체가 자체 대리자가 될 수 있습니다 (예 : 무효 대리자에 defaultin 대신 기본 동작 제공).
  • 한 개체가 여러 소스에서이 메시지에 응답하는 것이 합리적입니다.
  • 보내는 개체의 동작을 재정의하지 않는 것이 중요합니다. UIKit에 나타나는 횟수에도 불구하고 "반드시 super를 호출해야합니다"는 좋은 패턴이 아닙니다.

블록은 추가 클래스 없이도 작은 단위의 사용자 지정 동작을 허용하는 데 적합 할 수 있습니다.

관련 문제