사용자 지정 프로토콜과 대리자를 사용하여 상대적인 이점이 양방향 통신을위한 다른 기술과 비교할 때 궁금한 점이 있습니까?객관적인 프로토콜 및 대리자를 만드는 상대적인 이점 -c
예에 대한 또 다른 해결책은 다음 가지고있다 :
A A
A와 B 모두가 서로 다른 정보에 대한 액세스를이 방법에 관련된 B를 ... B- 연결된
나는 프로토콜이 시스템 디자인의 모듈성을 증가시킬 수 있다는 것을 이해하지만, 왜 또는 어떻게 확신 할 수 없는가?
사용자 지정 대리자 프로토콜은 개체가 특정 클래스에 종속되지 않도록 허용합니다. 주어진 프로토콜을 따르는 모든 객체는 위임 될 수 있습니다. 예를 들어 NSTableViewDelegate 프로토콜을 구현하면 모든 객체가 테이블 뷰의 위임자가 될 수 있습니다.
그렇지 않으면 직접 연결을 사용하는 경우 특정 클래스의 개체를 사용해야합니다.
위임 패턴 (특히 프로토콜 사용)을 사용하면 클래스가 느슨하게 결합 된 상태로 유지됩니다. 이것은 MVC 패턴을 고려할 때 중요합니다. 위임 패턴을 사용하면보기가 컨트롤러에서 분리 된 상태를 유지할 수 있습니다.
또한 "A와 연결된 B B와 연결된 A"는 유지주기를 생성합니다. 위임 패턴은 메모리 관리 문제를 체계화합니다 (즉, 클래스는 델리게이트를 유지하면 안 됨).
이러한 양방향 종속성은 컴파일 수준에서 다른 유형을 포함하여 포함되어 있음을 의미하지 않습니다.
OO 프로그래밍의 목표 중 하나가 부품 연결을 줄이는 것이면 수업을 너무 많이하고 있습니다.
당신이 할 수 있다고하더라도 그것이 좋은 연습을 의미하지는 않습니다.
좋은의 연습 2 프로토콜, 서버/객체/생산을위한 하나/... 클라이언트/대표/소비자를위한 하나/...
그런 다음 A가 하나의 프로토콜을 구현하는 것를 지정하는 것입니다, 두 번째 것을 구현할 객체와 대화 할 수 있습니다. B는 두 번째 프로토콜을 구현합니다. 등이 커플 링을 감소 새 API/프로그래밍 모델/테스트 스텁에 맞게 미래에 B 구현을 대체 할 수있는 것은 결국
은, 코드의 modulartity 및 테스트 용이성을 도와 평균입니다.당신은 필요는 없지만, 지금부터 6개월 나중에 코드에 돌아올 때 기뻐하실 겁니다 :)
는 일반적으로 전체 양방향 통신을하는 두 객체에 대한 필요가 없습니다 .
일반적으로 iPhone에서는 B에서 A (예 : 목록보기 컨트롤러의 상세보기 컨트롤러)를 시작하고 A를 B의 대리인으로 설정하여 관련 이벤트에 대한 직접 알림을받습니다.
완전 양방향 연결에서 2 개의 객체를 연결하는 것은 객체 지향 설계/프로그래밍 측면에서 올바르지 않습니다.
이 경우 캡슐화가 느슨합니다.
일단 위임 디자인 패턴을 사용하면 객체는 서로를 알지 못하지만 통신 할 수 있습니다.
또한이 방법은 특정 프로토콜을 구현하는 모든 개체를 대리자로 설정할 수 있습니다.
이 방법으로 객체를 서로 유지할 필요가 없습니다.