자바에서 추상화 대 캡슐화

자바에서 추상화 대 캡슐화 [중복]

---

중복 가능성 :
추상화 VS 정보 숨기기 VS 캡슐화

나는이 질문이이 포럼에서 수천 번 질문을 받았을 수도 있다는 것을 알고 있습니다. net조차도 이러한 개념에 대한 많은 정의로 채워져 있지만 모두 동일하게 들리고 모두 동일한 전문 용어를 사용합니다. 예를 들어 다음 정의

캡슐화 는 데이터와 데이터에서 작동하는 코드를 단일 엔터티로 바인딩하거나 래핑하는 프로세스입니다. 이것은 외부 인터페이스 및 오용으로부터 데이터를 안전하게 유지합니다. 캡슐화에 대해 생각하는 한 가지 방법은 래퍼 외부에 정의 된 다른 코드가 코드와 데이터에 임의로 액세스하는 것을 방지하는 보호 래퍼입니다.

위의 정의에서 이해 한 것은 변수를 만들고, 개인용으로 표시하고, 해당 변수에 대한 getter-setter를 생성하고, 개체를 사용하여 해당 getter 및 setter에 액세스한다는 것입니다. 이러한 방식으로 데이터는 개체 내부에 숨겨지고 개체를 통해서만 액세스 할 수 있습니다. 내가 옳길 바랍니다 .

---

추상화 는 특정 세부 사항을 숨기고 객체의 필수 기능 만 표시하는 데 사용되는 Java 프로세스입니다. 즉, 개체 (인터페이스)의 외부보기를 다룹니다.

이제 이것은 나를 항상 혼란스럽게하는 부분입니다. 추상화에 대해 생각할 때마다 내 마음에 떠오르는 것은 Abstract 클래스입니다 (둘 다 Abstract 키워드가 있기 때문일 수 있습니다). 위의 정의에 따르면 추상화는 데이터를 숨기고 필요한 세부 정보 만 표시하는 것을 의미하지만 캡슐화에서 이미 수행하고있는 작업입니다. 그렇다면 차이점은 무엇입니까? 또한 나는 물체 의 외부보기를 다루는 객체의 측면보기를 얻지 못했습니다 .

누군가가 실제 사례 또는 가능한 경우 프로그래밍 예제를 통해 이에 대해 더 밝힐 수 있습니까?

---

OO 추상화 는 기본 구현에 액세스하기 위해 '인터페이스'를 단순화하는 의미에서 API / 디자인 / 시스템에서 제공하는 기능 이 구현 된 방식 의 구현 복잡성 을 숨기는 목적으로 클래스 수준 디자인 중에 발생합니다.

추상화 과정은 점점 더 '높은'수준의 클래스 (계층)에서 반복 될 수 있으므로 코드의 복잡성을 증가시키고 각 계층에서 이해하지 않고도 대규모 시스템을 구축 할 수 있습니다.

예를 들어, Java 개발자는 작동 방식에 대한 걱정없이 FileInputStream의 고급 기능을 사용할 수 있습니다 (예 : 파일 핸들, 파일 시스템 보안 검사, 메모리 할당 및 버퍼링은 내부적으로 관리되며 소비자에게 숨겨집니다). 이를 통해의 구현을 FileInputStream변경할 수 있으며 API (인터페이스) FileInputStream가 일관성 을 유지하는 한 이전 버전에 대해 빌드 된 코드는 계속 작동합니다.

마찬가지로 자신의 클래스를 디자인 할 때 가능한 한 다른 사람으로부터 내부 구현 세부 정보를 숨기고 싶을 것입니다.

Booch 정의 ¹ 에서 OO Encapsulation 은 Information Hiding을 통해 달성되며, 특히 내부 데이터에 대한 액세스를 통제 된 방식으로 시행하고 직접 방지함으로써 클래스 인스턴스가 소유 한 내부 데이터 (상태를 나타내는 필드 / 멤버)를 숨기고, 이러한 필드에 대한 외부 변경은 물론 클래스의 내부 구현 메서드를 숨 깁니다 (예 : 비공개로 설정).

예를 들어, 클래스의 필드는 private기본적 으로 만들 수 있으며 이러한 필드에 대한 외부 액세스가 필요한 경우에만 클래스 에서 get()및 / 또는 set()(또는 Property)이 노출됩니다. (현대의 OO 언어에서 필드는 readonly/ final/ 로 표시 될 수 있으며 immutable이는 클래스 내에서도 변경을 더욱 제한합니다.)

정보 숨김이 적용되지 않은 예 (나쁜 사례) :

class Foo {
   // BAD - NOT Encapsulated - code external to the class can change this field directly
   // Class Foo has no control over the range of values which could be set.
   public int notEncapsulated;
}

필드 캡슐화가 적용된 예 :

class Bar {
   // Improvement - access restricted only to this class
   private int encapsulatedPercentageField;

   // The state of Bar (and its fields) can now be changed in a controlled manner
   public void setEncapsulatedField(int percentageValue) {
      if (percentageValue >= 0 && percentageValue <= 100) {
          encapsulatedPercentageField = percentageValue;
      }
      // else throw ... out of range
   }
}

필드의 변경 불가능 / 생성자 전용 초기화의 예 :

class Baz {
   private final int immutableField;

   public void Baz(int onlyValue) {
      // ... As above, can also check that onlyValue is valid
      immutableField = onlyValue;
   }
   // Further change of `immutableField` outside of the constructor is NOT permitted, even within the same class 
}

Re : 추상화 대 추상 클래스

Abstract classes are classes which promote reuse of commonality between classes, but which themselves cannot directly be instantiated with new() - abstract classes must be subclassed, and only concrete (non abstract) subclasses may be instantiated. Possibly one source of confusion between Abstraction and an abstract class was that in the early days of OO, inheritance was more heavily used to achieve code reuse (e.g. with associated abstract base classes). Nowadays, composition is generally favoured over inheritance, and there are more tools available to achieve abstraction, such as through Interfaces, events / delegates / functions, traits / mixins etc.

Re : Encapsulation vs Information Hiding

The meaning of encapsulation appears to have evolved over time, and in recent times, encapsulation can commonly also used in a more general sense when determining which methods, fields, properties, events etc to bundle into a class.

Quoting Wikipedia:

In the more concrete setting of an object-oriented programming language, the notion is used to mean either an information hiding mechanism, a bundling mechanism, or the combination of the two.

For example, in the statement

I've encapsulated the data access code into its own class

.. the interpretation of encapsulation is roughly equivalent to the Separation of Concerns or the Single Responsibility Principal (the "S" in SOLID), and could arguably be used as a synonym for refactoring.

---

^{[1] _{Once you've seen Booch's encapsulation cat picture you'll never be able to forget encapsulation - p46 of Object Oriented Analysis and Design with Applications, 2nd Ed}}

---

In simple words: You do abstraction when deciding what to implement. You do encapsulation when hiding something that you have implemented.

---

Abstraction is about identifying commonalities and reducing features that you have to work with at different levels of your code.

e.g. I may have a Vehicle class. A Car would derive from a Vehicle, as would a Motorbike. I can ask each Vehicle for the number of wheels, passengers etc. and that info has been abstracted and identified as common from Cars and Motorbikes.

In my code I can often just deal with Vehicles via common methods go(), stop() etc. When I add a new Vehicle type later (e.g. Scooter) the majority of my code would remain oblivious to this fact, and the implementation of Scooter alone worries about Scooter particularities.

참고URL : https://stackoverflow.com/questions/11965929/abstraction-vs-encapsulation-in-java