협회, 집계 및 구성의 사용은 무엇입니까?

캡슐화 란 무엇이며이를 구현하는 세 가지 기술 (협회, 집계 및 구성)에 대한 많은 이론을 살펴 보았습니다.

내가 찾은 것은 :

캡슐화

캡슐화는 클래스의 필드를 개인용으로 만들고 공용 메소드를 통해 필드에 대한 액세스를 제공하는 기술입니다. 필드가 개인용으로 선언되면 클래스 외부의 사용자가 필드에 액세스 할 수 없으므로 클래스 내의 필드가 숨겨집니다. 이러한 이유로 캡슐화를 데이터 숨기기라고도합니다.

캡슐화는 코드와 데이터가 클래스 외부에 정의 된 다른 코드에 의해 무작위로 액세스되는 것을 방지하는 보호 장벽으로 설명 할 수 있습니다. 데이터와 코드에 대한 액세스는 인터페이스에 의해 엄격하게 제어됩니다.

캡슐화의 주요 이점은 코드를 사용하는 다른 사람의 코드를 손상시키지 않고 구현 된 코드를 수정할 수 있다는 것입니다. 이 기능을 통해 Encapsulation은 코드의 유지 관리 성, 유연성 및 확장 성을 제공합니다.

협회

연결은 모든 개체에 고유 한 수명주기가 있고 소유자가없는 관계입니다. 교사와 학생의 예를 들어 봅시다. 여러 학생이 단일 교사와 연결할 수 있고 한 학생이 여러 교사와 연결할 수 있지만 개체간에 소유권이 없으며 둘 다 자체 수명주기가 있습니다. 둘 다 독립적으로 만들고 삭제할 수 있습니다.

집합

집계는 모든 개체에 고유 한 수명주기가 있지만 소유권이 있고 자식 개체가 다른 부모 개체에 속할 수없는 특수한 형식의 연결입니다. 부서와 교사의 예를 들어 봅시다. 단일 교사는 여러 부서에 속할 수 없지만 부서를 삭제해도 교사 개체는 삭제되지 않습니다. 우리는 이것을“하스-아”관계라고 생각할 수 있습니다.

구성

컴포지션은 다시 집계의 특수한 형태이며이를 "죽음"관계라고 부를 수 있습니다. 강력한 집계 유형입니다. 자식 개체에는 수명주기가 없으며 부모 개체가 삭제되면 모든 자식 개체도 삭제됩니다. 집과 방의 관계에 대한 예를 다시 살펴 보겠습니다. 집은 여러 개의 방을 포함 할 수 있지만 방의 독립적 인 수명은 없으며 어떤 방도 두 개의 다른 집에 속할 수 없습니다. 우리가 집을 삭제하면 방이 자동으로 삭제됩니다.

질문은 ~이야:

이제이 모든 것이 실제 사례입니다. 실제 클래스 코드에서 이러한 기술을 사용하는 방법에 대한 설명을 찾고 있습니다. 내 말은 캡슐화를위한 세 가지 기술을 사용하는 지점이 무엇인지 , 이러한 기술이 구현 될 수있는 방법 과 어떻게 한 번에 적용 할 수있는 기술을 선택합니다.

설명, 연관, 집계 및 구성의 차이점은 이전의 수동 메모리 관리로 거슬러 올라가는 유산입니다. 예를 들어 C ++에서 객체가 사용하는 메모리는 수동으로 해제해야하므로 작성된 객체의 수명주기를 신중하게 디자인하는 것이 가장 중요합니다. 많은 교과서에서 집계와 구성의 차이점을 여전히 가르치고 있지만 자동 메모리 관리 환경에서 프로그래밍 할 때는 본질적으로 관련이 없습니다. 가비지 콜렉션이 있으면 모두 구성, 기간입니다.

반면에 캡슐화는 설명하는 것보다 훨씬 일반적인 원칙입니다. 데이터와이 데이터에서 작동하는 기능을 하나의 모듈로 묶는 것이 가장 중요합니다. 이를 구현하는 한 가지 방법은 모듈 상태를 개인용으로 유지하고 공공 서비스를 통해 해당 상태에 대한 변경 사항을 노출하는 것입니다. 따라서 클라이언트는 자체적으로 상태에 액세스 할 수 없지만 메시지를 보내 모듈에 의도를 알려야합니다. 따라서 캡슐화는 객체로 제한되지 않고 서비스에도 적용됩니다. 실제로 객체를 보는 한 가지 방법은 객체를 서비스로 보는 것입니다.

다음은 캡슐화의 예입니다.

public class Counter {
    private int n = 0;
    public int inc() { return n++; }
}

또는 람다 함수를 사용하여 동일

var counter = (function() {
    var n = 0;
    var inc = function() { return n++; }
    return inc;
})();

두 경우 모두 변수 n인 변수는 데이터에서 inc작동 하는 함수와 함께 번들로 제공됩니다 . 그리고 다른 함수가 액세스 할 수있는 방법이 없으므로 n서비스로 계산을 제공하는 캡슐화 된 모듈이 있습니다.

주의 : 접근자를 통해 객체의 모든 내부 상태를 노출시키는 것은 실제로 캡슐화를 위반하는 것입니다. 아아, 그것은 많은 사람들이 그것을 좋은 객체 지향 디자인과 혼동하는 일반적인 위반입니다.

캡슐화는 클래스의 필드를 개인용으로 만들고 공용 메소드를 통해 필드에 대한 액세스를 제공하는 기술입니다. 필드가 개인용으로 선언되면 클래스 외부의 사용자가 필드에 액세스 할 수 없으므로 클래스 내의 필드가 숨겨집니다. 이러한 이유로 캡슐화를 데이터 숨기기라고도합니다.

    public class Test{

    private String name;

       private int age;

       public int getAge(){
          return age;
       }

       public String getName(){
          return name;
       }
    }

이 질문 도 참조하십시오 .

연결 은 개체 간의 관계를 나타냅니다. 예 : 컴퓨터는 키보드를 입력 장치로 사용합니다.

연결은 한 객체가 다른 객체가 서비스를 수행하기를 원할 때 사용됩니다.

집계 는 특별한 연결 사례입니다. 객체 간의 지향성 연관. 객체가 다른 객체를 '가지고있는'경우 객체간에 집계가 이루어집니다.

예 : 테이블에 테이블이 있지만 테이블이 룸없이 존재할 수 있습니다.

    class Room {

      private Table table;

      void setTable(Table table) {
        this.table = table;
      }

    }

구성 은 특별한 집계의 경우입니다. 구성이 더 제한적입니다. 두 객체 사이에 구성이있는 경우 다른 객체가 없으면 작성된 객체를 존재할 수 없습니다. 이 제한은 집계에 없습니다. 예 : 집안의 방. 집안의 수명이 지난 후에는 존재할 수 없습니다.

    class House {

      private  Room room;

      House(Room roomSpecs) {
        room = new Room(roomSpecs);
      }

    }

컴포지션은 코드 재사용을 위해 상속 또는 객체 컴포지션을 통해 클래스에서 관계를 구현하는 디자인 기법입니다.

Java 프로그래밍에서 가장 좋은 방법 중 하나는 상속보다 컴포지션을 사용하는 것입니다.

이러한 기술을 사용하면 일반적으로 SOLID 또는 다양한 디자인 패턴 과 같은 디자인 방식이 적용 됩니다.

패턴, 관행 등을 사용하는 요점은 유지 관리 가능하고 확장 가능한 특정 문제에 대한 솔루션을 설명하는 것입니다. 어떤 패턴이나 기술을 사용할 위치를 알 수있는 충분한 경험이 필요합니다.

나는 학계에서 가르치는 이러한 개념들이 사물 오리엔테이션과 수업 디자인의 맥락에서 중요하다고 생각합니다. 이러한 개념은 시스템을 처음부터 모델링 할 때 많은 도움이됩니다. Association, Aggregation 및 Composition은 UML의 클래스 다이어그램에만 속하며 메모리 문제와 같은 기술 제약과 완전히 독립적입니다.

또한 모델링하려는 시스템의 높은 수준 또는 비즈니스 목표도 고려해야합니다. 시스템에 House and Room과 같은 객체가 있지만 구성을 통해 강력하게 관련 될 수는 없습니다. 예를 들어, 부동산 시스템을 모델링하는 경우 어떤 방이 어떤 집에 속하는지 알아야합니다. 그러나 특정 지역에서 집의 각 방에 얼마나 많은 사람들이 살고 있는지 알고 싶은 측량 또는 인구 조사 시스템을 모델링하려고합니다. 그러면 방을 통해 집과 방을 연결할 필요가 없습니다.

또 다른 예는 과수원과 특정 종류의 과일 일 수 있습니다. 사과 나무가 심어 져있을 때만 과수원을 고려할 수 있다고하자. 결론은 전체 시스템의 요구 사항이 중요하다는 것입니다.

캡슐화 는 객체 지향 디자인의 기둥 중 하나입니다. 데이터와 데이터에서 수행 할 작업을 번들로 묶어야합니다. 또한 객체가 유효한 상태로 유지 되려면 객체의 특정 속성을 외부 세계에서 숨겨야합니다. 2 개의 객체가 상호 작용할 때 인터페이스를 통해 서로 상호 작용해야합니다. 이것이 바로 OO 시스템을 설계 할 때 캡슐화가 보장하는 것입니다.

이러한 개념이 코드에 적용되는 방법은 다음과 같습니다.

연관성 : 연관은 오브젝트 간의 관계를 나타냅니다. 프로그래머가 클래스에서 어떤 메소드를 작성하여 서로 상호 작용할 수 있는지 알려줍니다. 연관성을 이해하기위한 코드 및 클래스 다이어그램의 몇 가지 예를 찾을 수 있습니다. 교사와 학생의 모범에서 와 가르치고 가르치는 관계 가 있습니다. 따라서 어떤 학생이 어떤 교사를 가지고 있고 어떤 교사가 어떤 학생을 가지고 있는지 알 수있는 일련의 방법 (기술적으로 인터페이스라고 함)을 작성하기 만하면됩니다. 또한 연결을 통해 시스템 모델러는 데이터베이스 디자이너가 데이터베이스에 보관해야하는 속성 및 필드에 대해 도움을 줄 수 있습니다.

구성 : 한 객체가 다른 객체의 필수 부분 인 경우 다른 객체의 생성자에서이 관계를 표시해야 할 수도 있습니다. 예를 들어, 주택 및 방 시나리오에서 어떤 방이 어떤 집 유형에 속하는지 알고 싶다면 다음 코드를 작성할 수 있습니다.

class House{
          string _HouseType;   
     public:    
    void setHouseType(string house_type)
     {
        this. _HouseType = house_type;
     } 

     string getHouseType()
    {
       return _HouseType;
    }
};



 House HouseObject = new House();


class Room{

 public: 
 Room(string HouseType) {
       this._HouseType = HouseObject.getHouseType();  //as in my system a room cannot exist without a house

 } 

};

프로그래머는 또한 객체의 소멸자 를 호출하는 동안 다른 객체의 디스 트럭 터가 호출되도록합니다. 이것은 중요합니다.

어 그리 게이션 : 객체 사이의 관계가 약한 경우 프로그래머에게 관계를 나타내는 대신 인스턴스 변수를 사용하여 관계를 나타냅니다. 그런 다음 다른 객체에서 해당 객체에 값을 제공하기 위해 mutator functon (setter)을 작성하십시오.

class Department{

 string dept_name;

public:
   void setDeptName(string name)
   {
        this.dept_name=name;
   }

   string getDeptName()
   {
        return dept_name; 
   }

};



 Department DepartmentObject = new Department();

class Teacher{

 string dept_name;

public:

  setDeptName(string name)
  {
     this.dept_name = DepartmentObject.getDeptName();  //You only need to invoje this method when needed (aggregation)
  }
}

};

자, 이것을 의미가 이해되면 이해하기 쉬운 추상적 개념이 아닌 일부 핵심 속성에 매핑 해 봅시다. 일부 의견 제시 자와 마찬가지로 내가 받아 들인 대답에 동의하지 않는 것은 메모리 관리와 독립적 인 개념이라고 말합니다.

캡슐화

클라이언트의 복잡성을 숨기고 클라이언트의 관점에서 중요한 내용 만 게시하여 클라이언트가 더 쉽게 할 수 있습니다. 보너스로 캡슐화 된 코드로 아무것도 망칠 수 없다는 확신을 얻습니다. 인터페이스와 기능을 존중하는 한 물건을 재 작업하고 아무것도 깨지 않을 것입니다. 종속성은 게시 된 인터페이스에만 있습니다.

캡슐화는 객체 방향의 주요 기둥 중 하나입니다. 패턴이 아니라 원칙이며 논리 및 데이터에 모두 적용될 수 있습니다. 처음에는 클래스를 사용하는 것이 기본적인 이점 일뿐 다이어그램이나 디자인 문서에 명시 적으로 언급 된 내용이 아닙니다.

협회

이것은 기본적으로 객체 간의 종속성을 설명하는 매우 느슨한 개념입니다. 한 객체는 다른 객체의 존재를 알고 있으며 어느 시점에서 그 기능을 사용할 수 있습니다. 다이어그램에서 연결은 종속성이 있으며 한 개체를 변경하면 다른 개체에 영향을 줄 수 있음을 경고합니다. 그것은 해결해야 할 문제가있을 때 적용하는 기술이 아니며, 그것이있을 때 알아야 할 삶의 사실과 비슷합니다. 관계입니다. Orders 속성이있는 송장처럼 주문과 송장에는 각각 고유 한 수명주기가 있습니다. 하나는 상품에 관한 것이고 다른 하나는 지불에 관한 것입니다. 이는 본질적으로 독립적으로 만들지 만 어떤 상품이 지불되고 있는지를 아는 것이 중요합니다.

봉쇄

시리즈에 속하고 집계가 더 의미가 있기 때문에 이것을 추가하고 있습니다. 나는 더 이상 SE 컨텍스트에서 사용되는 용어를 듣지 않지만 여전히 유용하다고 생각합니다. 포함은 캡슐화를 의미하지만 포함하는 클래스의 개인용 객체 인스턴스에 관한 것입니다. 포함 된 개체의 기능은 공용 인터페이스를 통해 선택적으로 노출됩니다. 포함하는 클래스는 제어 대상의 수명주기를 제어합니다. 포함 클래스를 기능적으로 만들기 위해 기존 클래스의 일부 기능이 필요할 때 이것을 사용합니다. 이것은 XML 파서 일 수 있으며 포함하는 클래스의 클라이언트는 XML과 관련된 것을 보거나 알 수 없습니다. 은유로 포함 된 개체를 백 오피스 작업자로 생각하십시오. 고객은 이러한 사람들을 만나지 않고 서비스를 제공해야합니다.

집합

이는 수명주기 제어 및 집계 된 개체의 가시성을 제외하고는 격리와 매우 유사합니다. 집계 된 오브젝트는 이미 다른 컨텍스트에서 사용 가능하며 다른 엔티티에 의해 관리됩니다. 애그리 게이터는 단순히 집계 된 오브젝트에 대한 포탈 인 정면을 제공합니다. 클라이언트가 집계를 처리하면 래퍼가 아닌 집계 개체 자체의 인터페이스를 가져옵니다. 집합의 요점은 사물을 논리적으로 그룹화하는 것입니다. 서비스 나 다른 래퍼 객체에 대한 액세스 포인트를 생각하십시오.

구성

아마도 이것은 최근에 격리 된 인기있는 책에서 만들어 졌기 때문에 격리에 대한 더 현대적인 용어 인 것 같습니다. 격리가 객체 관계의 기술적 측면에 중점을 둔 경우 구성은 일반적으로 디자인 결정의 맥락에서,보다 구체적으로 상속을위한보다 유연한 대안으로 사용됩니다.

객체 관계 또는 소유권의 성격에 대해 많이 말하지 않고 단순히 기존 클래스의 기능을 결합하여 기능이 구현되었음을 나타냅니다. 따라서 나는이 시리즈에 속하지 않는다고 주장 할 것이다. 왜냐하면 다른 사람들이하는 구현의 기술적 측면에 대해 아무 것도 말하지 않기 때문이다.