2010-02-11 2 views
1

예를 들어, 창 (비 문서 모델)이 있습니다. 연결된 컨트롤러가 있습니다. 이 창 안에는 목록이 있고 버튼을 추가합니다. 추가 버튼 버튼을 클릭하면 사용자가 세부 정보를 입력하고 확인을 클릭 한 다음 항목을 원래 창 목록으로 다시 전파 할 수있게 해주는 다른 "세부 정보"창/대화 상자 (연결된 컨트롤러 포함)가 나타납니다. 분명히, 나는 이러한 엔티티들의 콜렉션을 보유하고있는 기본 모델 객체를 가질 것이다. (단 하나의 엔티티를 참조를 위해 엔티티라고 부르 자.)소유권 및 다중 컨트롤러와 반 공유 객체 간의 참조 패턴?

아마도 메인 윈도우가 하나 뿐이므로 가능한 엔티티 집합이 하나만있을 것입니다. 메인 윈도우의 컨트롤러에서 숨길 수는 있지만, 어떻게 세부 창으로 전달할 수 있습니까? 내 말은, 아마이 컬렉션을 지나치고 싶지는 않을 것입니다. 읽기/유지/다중 스레드가 어렵습니다. 상위 컨트롤러에 대한 참조를 전달하여 컬렉션에 액세스 할 수 있지만 냄새가 나는 것 같습니다. appDelegate에 숨긴 다음 [[NSApplication sharedApplication] delegate]를 통해 "전역 변수"로 액세스 할 수 있습니다. 이는 앱 위임자가 실제로 모델과 관련이 없다고 생각하면 다소 과도한 것 같습니다. 또 다른 전역 변수 스타일은 옵션 일 수 있습니다. Entity 클래스가 콜렉션에 대한 싱글 톤 팩토리를 가지게하고 콜렉션에 액세스하는 클래스 메소드를 만들 수 있습니다. 이것은 appDelegate보다 더 큰 학대처럼 보입니다. 특히 엔티티 객체와 해당 엔티티의 콜렉션을 고려할 때 두 가지 별도 관심사가 있습니다. 싱글 톤 팩토리 메소드를 가진 EntityCollection 클래스를 생성 한 다음 콜렉션과의 상호 작용을위한 객체 메소드를 만들 수 있습니다 (또는 테스트 객체에 대한 좀 더 많은 OO 장점과 손쉬운 대체를 위해 실제 팩토리 클래스와 콜렉션 클래스로 분리). NSDocument 모델을 사용하고 있었다면, 거기에 숨길 수있을 것 같았지만, NSDocument 자체가 겉으로는 그 모델을 어떤 식 으로든 나타내지 만 애플리케이션 위임에 stash하는 것과 크게 다르지 않습니다.

나는 서버 측에서 꽤 많은 시간을 보냈다. 그래서 나는 클라이언트 측을 많이 다루지 않아도되었다. 그리고 내가 가지고있을 때, 나는 단지 짐승만으로 해결책을 강요했다. 결국,이 고양이를 껍질을 벗기는 10 억 가지 방법이 있으며, 그 중 아무도 끔찍하게 깨끗하거나 예쁘지 않은 것처럼 보입니다. 코코아 프로그래머가 일반적으로 받아들이는 방법은 무엇인가? 또는, 더 나은 아직, 이것을하는 최적의 방법은 무엇입니까?

답변

7

당신의 개념적 문제는 인터페이스의 핵심을 응용 프로그램의 핵심으로 생각하고 데이터 모델을 뭔가 어딘가에 쑤셔 넣을 장소로 생각해야한다는 것입니다.

역행입니다. 데이터 모델은 프로그램의 핵심이며 다른 모든 것은 데이터 모델에 접목됩니다. 모델은 데이터에서 수행 할 수있는 모든 논리 연산을 캡슐화해야합니다. GUI 또는 기타 인터페이스는 특정 동작을 요청하는 메시지를 데이터 모델로 보냅니다.

이 개념부터는 데이터 모델을 보편적으로 액세스 할 수 있다는 것이 쉬운 일이 아닙니다. 모델에는 데이터를 변경하기위한 모든 로직이 포함되어 있기 때문에 모델이 내부 규칙에 따라 데이터를 변경하기 때문에 데이터가 혼잡 해 지거나 코드가 복잡 해지는 일없이 액세스하는 임의의 수의 인터페이스를 가질 수 있습니다.

유니버설 액세스를 수행하는 가장 좋은 방법은 싱글 톤 생성 클래스를 만든 다음 클래스의 헤더를 응용 프로그램 접두사 헤더에 넣는 것입니다. 그렇게하면 앱의 모든 개체가 데이터 모델에 액세스 할 수 있습니다.

Edit01는 :

나를 벌거 벗은 전역 변수와 전역 적으로 액세스 클래스 캡슐화 된 데이터 모델 사이의 중요한 차이를 명확히하자.

역사적으로 전역 변수는 원래 변수 였기 때문에 나쁜 디자인으로 간주했습니다. 코드의 어떤 부분도 마음대로 변경할 수 있습니다. 이 벌거 벗음으로 인해 명백한 문제가 발생했습니다. 글로벌 코드를 변경 한 다음 응용 프로그램을 중단시키는 코드 조각에 대해 끊임없이 경계해야했습니다.

그러나 클래스 기반 전역 변수에서 전역 변수는 캡슐화 클래스에 의해 구현 된 논리로 캡슐화되고 보호됩니다. 이 캡슐화는 코드의 길잃은 조각이 클래스 내부의 전역 변수를 변경하려고 시도하지만, 캡슐화 클래스가 변경을 허용하는 경우에만 그렇게 할 수 있음을 의미합니다. 자동 유효성 검사는 코드의 복잡성을 줄입니다. 모든 유효성 검사 로직은 데이터가 조작 될 수있는 임의의 임의의 장소에서 앱 전체에 퍼져있는 대신 단일 클래스에 있기 때문입니다.

벌거 벗은 전역 변수의 경우와 같이 약점을 만드는 대신 강력하고 보편적 인 유효성 검사 및 데이터 관리를 만듭니다. 데이터 관리에 문제가있는 경우 한 곳에서 해결하면됩니다. 데이터 모델을 적절히 구성하면 나머지 응용 프로그램이 무척 쉽게 작성 될 수 있습니다.

+0

나는 당신의 가장 중요한 점에 동의한다고 생각합니다. 모델에 초점을 맞추는 관점의 변경이 적절한 것으로 보입니다. 코코아 (및 그 도구)는 종종 모델보다는 UI/뷰/컨트롤러에서 운전에 집중하는 것처럼 보입니다. 이 조명에서 볼 수있는 것처럼 전역 적으로 액세스되는 모델은 실제로는 단일 공유 컬렉션이라고 가정하면 나쁘지 않습니다 (일반적으로 나는 그것이 있다고 가정했습니다). – rcw3

+0

예. Mac과 iPhone의 사용자 인터페이스는 디자이너에게 UI에 대한 관심을 끌고 프로그램의 가장 중요한 부분 인 것처럼 보이는 최면의 품질을 제공합니다. 귀여운 얼굴 대 개인 캐릭터의 오래된 문제입니다. 성격을 무시하면서 예쁜 얼굴을 선택하면 결국 마음이 아플 수 있습니다. 코딩 방법은 같습니다. 예쁜 UI는 피부 깊숙이 있지만 나쁜 데이터 모델은 뼈까지 줄곧갑니다. – TechZen

0

저는 EntityCollection 클래스를 지원합니다. 개체 목록이 있다면 해당 목록은 특정 컨트롤러 외부에서 관리해야합니다.

+0

이것은 나쁜 제안이 아니므로 NSArrayController의 사용을 제안하는 것처럼 들립니다. – RibaldEddie

2

초기 반응은 NSAlert처럼 "모달 대리인"을 사용하는 것입니다. 대리자에 대한 참조를 전달하여 세부 정보 창을 만들면 세부 정보 창이 개체 만들기를 완료하면 메시지가 표시됩니다. 대리인 (메인 윈도우의 컨트롤러 일 것임)은 "완료된 편집"메시지를 처리하고 컬렉션에 개체를 추가 할 수 있습니다. 나는 수집품을 직접 주변에 전달하고 싶지 않은 경향이있다.

+0

나는이 솔루션이 정말로 마음에 듭니다 - 간결하고 자신의 클래스에서 Apple이 자주 사용하는 패턴과 관련이 있습니다. – rcw3

0

클래스 자체가 자체 컬렉션, 설정 및 해체를 관리하는 싱글 톤 방법을 사용합니다. 필자는 컨트롤러에서 데이터베이스/스토리지 기능을 분리하여 깨끗하게 유지합니다. 멋지고 쉽게 [Object objects]에 전화를 걸어 내 물건 목록에 대한 참조를 돌려 주도록하십시오.