중첩 클래스 : 유용한 도구 또는 캡슐화 위반?

그래서 나는 이것들을 사용 해야하는지 아닌지에 대해 여전히 울타리에 있습니다.

캡슐화가 극단적으로 위반된다고 생각하지만 코드에서 더 많은 유연성을 얻으면서 어느 정도의 캡슐화를 달성 할 수 있음을 알았습니다.

이전 Java / Swing 프로젝트 중첩 클래스를 어느 정도 사용했지만 이제는 C #의 다른 프로젝트로 이동했으며 사용을 피합니다.

중첩 클래스에 대해 어떻게 생각하십니까?

중첩 클래스는 캡슐화를 위반하지 않으며 일반적으로 언어 기능은 프로그래밍 원칙을 위반하지 않습니다. 프로그래머는 프로그래밍 원칙을 위반합니다.

재미있게도 중첩 클래스는 캡슐화가 증가 한다고 주장 합니다 .

캡슐화 증가 —B가 달리 비공개로 선언 된 A의 멤버에 액세스해야하는 두 개의 최상위 클래스 A와 B를 고려하십시오. 클래스 A 내에 클래스 B를 숨기면 A의 구성원을 비공개로 선언하고 B가 액세스 할 수 있습니다. 또한 B 자체는 외부 세계에서 숨길 수 있습니다.

거기에는 약간의 진실이 있습니다.

일반적으로 B는 A에 SRP 를 적용한 결과입니다 . 그러나 B 자체는 많은 원칙을 위반할 수 있습니다.

숨겨진 클래스가 유용 할 수 있다고 생각합니다. 그러나 오용의 가능성이 많습니다.

우리는 항상 중첩 클래스를 사용합니다. 많은 상황에서 비즈니스 소프트웨어 / 프로세스에는 중첩 된 비즈니스 오브젝트가 있습니다. 우리는 모두 중첩 된 OrderItem 컬렉션을 가진 Order 객체의 예제를 보았습니다.

결론은 코드를 쉽게 읽고 쓸 수 있으며 Order 클래스가 필요하고 OrderItem에 대해 알 필요가없는 경우는 거의 없다는 것입니다.

개인적으로 디자인을 다양한 (보통 바람직하지 않은) 방식으로 결합하기 때문에 피해야한다고 생각합니다.

그러나 프로젝트에 설정된 범위가 있고 클래스 (예 : Node 클래스 또는 특정 클래스의 데이터 구조를 통과하는 데 사용되는 일종의 객체)를 캡슐화하면 해가되지 않습니다.

실제로 특정 유형의 프로젝트에서는 코드 (및 추론)를 더 읽기 쉽고 이해하기 쉽게 만듭니다. 그러나 확장 성을 염두에 둔 대부분의 프로젝트는 문제를 일으키는 경우가 거의 없기 때문에 나쁜 생각입니다.하지만 함께두면 나중에 시간을 낭비하게됩니다.

(C #에서는) 클래스의 목적이 정확히 무엇인지에 따라 다르지만 일반적으로 피하는 것이 좋습니다.

나는 어떤 종류의 도메인 모델 클래스에도 사용하지 않을 것입니다.

나는 외부 클래스에서 개인 데이터를 구조화하는 데 사용했지만, 프로젝트의 수명주기에서 나중에 항상 외부 적으로 필요하다는 것을 알았으므로 일반적으로 더 이상 이것에 신경 쓰지 않습니다.

내가 지금 사용하는 유일한 시간은 다른 작은 클래스를 사용하면 특정 클래스를 쉽게 구현하거나 실제로 이벤트 알림 패턴 인 인터페이스를 구현하는 이상한 작은 코딩 트릭입니다 (내부 클래스가 인터페이스를 구현하고 전달하는 경우) 외부 클래스를 다시 제어하십시오).