오브젝트 오르기
Object orgy |
컴퓨터 프로그래밍에서 오브젝트 오기는 오브젝트가 정보 숨김을 통해 충분히 캡슐화되지 않고 오브젝트 내부에 제한 없이 접근할 수 있는 상황입니다.이는 객체 지향 설계 또는 객체 지향 프로그래밍에서 흔히 발생하는 장애(또는 안티 패턴)로 유지 보수 요구와 문제가 증가하고 유지보수가 불가능할 수도 있습니다.
결과들
오브젝트 orgy의 결과는 주로 다음과 같은 캡슐화의 이점을 잃게 됩니다.
- 제한되지 않은 접근은 독자가 물체의 동작을 추론하는 것을 어렵게 만든다.이는 내부 상태에 대한 직접 액세스가 시스템의 다른 모든 부분이 시스템을 조작할 수 있다는 것을 의미하기 때문에 검사할 코드 양이 증가하고 향후 악용에 대한 수단이 생기기 때문입니다.
- 추론의 어려움 때문에 계약에 의한 설계는 사실상 불가능하다.
- 많은 코드가 캡슐화 부족의 이점을 활용한다면, 그 결과는 일반적으로 쥐 둥지 또는 스파게티 코드로 알려진 거의 유지보수가 불가능한 상호작용의 미로입니다.
- 원래 디자인은 지나치게 넓은 객체 인터페이스로 인해 가려집니다.
- 인터페이스가 넓기 때문에 시스템의 나머지 부분을 방해하지 않고 클래스를 재실장하는 것이 어려워집니다.이것은 클래스의 클라이언트가 다른 팀 또는 조직에 의해 개발되는 경우 특히 어렵습니다.
폼
캡슐화는 다음과 같은 여러 가지 방법으로 약화될 수 있습니다.
- 내부 멤버를 퍼블릭으로 선언하거나 퍼블릭 뮤테이터 방식(세터 또는 게터)을 통해 데이터에 대한 무료 액세스를 제공합니다.
- 공개되지 않은 접근을 제공함.예를 들어 C#[1]의 Java 액세스 수식자 및 접근성레벨을 참조해 주세요.
- C++에서는, 상기의 몇개의 방법으로, 및 선언을 실시합니다.
friend클래스 또는 함수.
오브젝트는 참조를 다른 클래스의 메서드 또는 생성자에게 인수로서 전달함으로써 내부 데이터에 접근할 수 있도록 할 수도 있습니다.이러한 데이터는 참조를 유지할 수 있습니다.
이와는 대조적으로 서로 참조를 유지하는 개체는 때때로 개체 정렬의 한 형태로 설명되지만 그 자체로 캡슐화를 위반하지는 않습니다.
원인들
회원에게 적절한 접근자를 제공하는 노력이나 구문상의 오버헤드를 피하기 위해 회원을 공개로 선언할 수 있습니다.이는 위에서 설명한 결과를 희생하면서 클래스의 가독성을 높일 수 있다.
언어에 따라서는 읽기 전용 접근을 위한 편리한 구조가 없기 때문에 다른 오브젝트가 읽을 수 있도록 의도된 구성원을 변경할 수 있다.
설계자가 오브젝트 간의 상호작용을 충분히 분석하지 않은 경우 오브젝트 오기는 미숙하고 빈약한 설계로 코딩되는 증상일 수 있다.이는 특히 프로그래머가 디자이너와 충분한 의사소통을 하지 않거나 문제가 발생했을 때 디자인을 수정하는 것을 꺼리는 등의 게으름이나 성급함에서 발생할 수 있으며, 이는 또한 많은 다른 안티 패턴들을 장려한다.
많은 프로그래머가 객체를 빈약한 데이터 저장소로 보고 정보 숨기기, 캡슐화 및 계약에 의한 설계 원칙을 위반하여 조작합니다.
솔루션
일반적으로 캡슐화는 다른 클래스의 설계에 필요한 캡슐화와 재설계가 필요하기 때문에 깨집니다.그렇지 않으면 베스트 프랙티스에 따라 시스템을 재코드하는 것으로 충분합니다.인터페이스가 취소 불능으로 공개되면 수정이 늦어질 수 있습니다.
레퍼런스
- ^ MSDN: 접근성 수준, Visual Studio.NET 2003 Wayback Machine에서 2008-04-17 아카이브 완료).
