양식의 공개/보호 구성 요소에 대한 접근자 메서드/Getter Setter를 제공해야 합니까?

Question

상위 또는 다른 양식에서 액세스해야 하는 텍스트 상자와 같은 구성 요소/객체가 포함된 .Net 양식이 있는 경우 분명히 이 구성 요소에 대한 수정자를 내부 또는 공용 수준 변수로 "업그레이드"해야 합니다.

이제 int 또는 string 유형 등의 공개 변수를 제공한다면내 양식 클래스에서는 변수에 대한 직접 액세스를 제공하는 것 외에는 아무것도 수행하지 않더라도 Getter 및 (아마도) Setter를 사용하는 것에 대해 두 번 생각하지 않을 것입니다.

그러나 VS 디자이너는 양식의 구성 요소인 공용 개체에 대해 이러한 Getters/Setter를 구현하지 않는 것 같습니다(따라서 좋은 프로그래밍 관행을 따르지 않습니다).

그래서 질문은 다음과 같습니다."올바른 일"을 수행하려면 이러한 VS 디자이너 구성 요소나 개체를 Getter 및/또는 Setter로 래핑해야 합니까?

Answer 1

"그러나 VS 디자이너는 양식의 구성 요소인 공용 개체에 대해 이러한 Getters/Setter를 구현하지 않는 것 같습니다(따라서 좋은 프로그래밍 관행을 따르지 않습니다)."

양식에 끌어서 놓는 컨트롤을 의미하는 경우 해당 컨트롤은 전용 인스턴스 멤버로 표시되고 양식의 Controls 컬렉션에 추가됩니다.왜 그렇지 않을까요?양식에는 40~50개의 컨트롤이 있을 수 있으므로 양식의 모든 컨트롤에 대해 getter/setter를 제공하는 것은 다소 불필요하고 다루기 힘들 것입니다.디자이너는 공개 getter/setter를 통해 특정 컨트롤에 대한 위임된 액세스를 제공하는 것을 사용자에게 맡깁니다.

디자이너는 여기서 옳은 일을 합니다.

Answer 2

내가 생각하는 양식의 구성 요소에 대해 Getter 및 Setter를 구현하지 않는 이유는 "스레드 안전"이 아니기 때문입니다. .Net 개체는 해당 개체를 만든 양식 스레드에 의해서만 수정된다고 가정합니다. getter 및 setter를 사용하는 경우 잠재적으로 모든 스레드에 대해 열 수 있습니다.대신 이러한 객체에 대한 변경 사항을 해당 객체를 생성하고 실행한 스레드에 위임하는 위임 시스템을 구현한다고 가정합니다.

Answer 3

이는 객체 지향 설계에서 캡슐화의 전형적인 예입니다.

Form은 사용자에게 UI를 제공하고 입력을 받아들이는 책임을 맡은 개체입니다.Form 개체와 코드의 다른 영역 사이의 인터페이스는 Form의 내부 구현 세부 정보를 노출하는 인터페이스가 아니라 데이터 지향 인터페이스여야 합니다.양식의 내부 작업(즉, 컨트롤)은 소비 코드로부터 숨겨진 상태로 유지되어야 합니다.

성숙한 솔루션에는 아마도 다음과 같은 설계 사항이 포함될 것입니다.

• 공용 메서드 또는 속성은 동작(표시, 숨기기, 위치) 또는 데이터 지향(데이터 설정, 데이터 가져오기, 데이터 업데이트)입니다.
• Form에 의해 구현된 모든 이벤트 핸들러는 Form 스레드 실행 규칙을 적용하기 위해 적절한 스레드 위임 코드로 래핑됩니다.
• 컨트롤 자체는 코드를 줄이기 위해 기본 데이터 구조(해당하는 경우)에 데이터 바인딩됩니다.

그리고 그것은 단위 테스트와 같은 메타 개발에 대해서는 언급조차 하지 않습니다.

Answer 4

나는 항상 그렇게 하며, MVP 디자인을 따르고 있다면 뷰 구성 요소에 대한 getter/setter를 만드는 것이 디자인 요구 사항이 될 것입니다.

"좋은 프로그래밍 관행을 준수하지 않는다"는 것이 무슨 뜻인지 이해가 되지 않습니다.마이크로소프트는 위반한다 많이 빠른 앱 개발을 위해 Visual Studio에서 항목을 더 쉽게 만들 수 있도록 하는 좋은 프로그래밍 방법이 있으며 컨트롤에 대한 getter/setter가 부족하다는 것이 그러한 모범 사례를 위반했다는 증거로 보지 않습니다.