싱글 톤보다는 약한 "할당"참조

Question

많은 객체가 동일한 클래스의 저장된 데이터를 참조합니다. 이전 프로그램에서는 싱글 톤을 사용해 왔지만 그 연습을 포기하고 필요한 경우 최후의 수단으로 사용했습니다. 주로 나쁜 평판으로 인해서였습니다 (실제로 나는 과거에 그들을 학대했습니다).

하지만 새로운 기술이 얼마나 많은 이점이 있는지 궁금합니다. 나는 같은 데이터 세트에 대한 약한 참조를 만들기 만하므로 여러 클래스가 같은 메모리를 가리켜 필요에 따라 데이터를 가져온다. 예를 들면 : 클래스 정의에 init

@property (nonatomic, assign) MyDataClass*mydata;

, I는 다음 property이 참조를 할당하는 방법의 파라미터로 참조를 전달한다.

이 작업은 유효하고 허용되는 방법입니까? 싱글 톤을 사용하는 것보다이 작업을 수행하는 데있어서 조직적 이점의 상당 부분을 찾는 데 어려움을 겪고 있습니다.

Answer 1

사용 패턴은 훌륭합니다. 결국이 패턴은 참조 계산이나 기타 고급 메모리 관리 도구가없는 모든 표준 C++ 프로그램에서 사용됩니다. 객체 계층 구조가 참조의 약점, 즉 그 참조 뒤에있는 객체에 대한 참조를 갖는 객체의 종속성을 엄격히 준수하는지 확인해야합니다. 즉, 참조 소유자가 참조 번호 보다 먼저 참조 번호 참조를 보장해야하며 참조 카운팅을 사용하지 않으므로 수동으로 확인해야합니다.

이것은 당신이 항상 당신의 객체의 수명을 완전히 제어해야하기 때문에 프로그래머에게 더 많은 책임이 있음을 의미합니다. 약한 참조가있는 코드에서 원래의 객체가 존재하거나 삭제되었는지 여부를 알 수 없으므로 패턴을 잘못 작성하는 것은 매우 쉽습니다. 디자인 패턴으로이를 보장해야합니다.

이런 이유로 나는 retain 유형 속성에 의해 제어가 벗어날 수있는 객체에 대한 약한 참조를 갖는 두 가지 접근 방식을 혼합하는 것을 제안하지 않습니다 (속성 값이 귀하의 개체), autorelease 또는 ARC.

프로그래머가이 책임을지고 안전한 코드를 작성하기 쉽게하기 위해 참조 카운트가 도입되었습니다. 귀하의 패턴은 괜찮아요, 그것은 C++ 프로그램의 수백만에 의해 사용되지만 당신은 당신의 책임을 의식해야합니다.

Answer 2

일반적으로 둘 이상의 개체가 존재하지 않는 개체에 대해서는 싱글 톤 클래스 만 사용해야합니다. 그렇지 않으면 커플 링을 도입하기 때문에 피하기가 가장 좋습니다. 싱글 톤을 사용하는 모든 클래스는 싱글 톤에 밀접하게 결합됩니다.

물건에 대한 참조를 전달하는 것이 좋습니다. 유지 사이클을 피하기 위해 필요한 경우를 제외하고는 약한 참고 문헌 일 필요는 없습니다.

많은 수의 클래스간에 동일한 객체를 전달하는 경우 책임 분담 및 앱 재구성에 대해 생각해 볼 수 있습니다.

Answer 3

보유/할당 및 사용 싱글 톤은 상호 배타적 인 패턴이 아닙니다. 나는 싱글 톤에 대해 그렇게 주저하지 않을 것이고, iOS를 시작할 때 나는 처음이었다.

Java 웹 응용 프로그램 개발자가되어 왔기 때문에 싱글 톤은 밀 결합 때문에 좋지 않았습니다. 특히로드 밸런서/(클라우드)에 응용 프로그램을 배포하려는 경우 싱글 톤이 병목 현상이 발생하여 쉽게 확장 할 수 없습니다.

싱글 톤을 사용하는 단위 테스트에 문제가 있으며 테스트 중에 상태를 재설정하거나 조롱하려고하는 경우에도 문제가있었습니다.

그러나 Objective-C 및 iOS 개발에서 싱글 톤에 대한 많은 단점을 실제로 볼 수 없습니다. 앱의 크기가 조정되지 않고 sdk가 이미 유닛 테스트를 방해하는 싱글 톤으로 흩어져 있습니다.