객체지향 개념, 객체지향에서 사용되는 용어 정리

 

 

객체지향 개념

개념	설명
기능적 분해	구조적 언어를 사용하는 프로그래머들은 보통 기능적 분해 관점으로 프로그램 설계에 접근한다. 기능적 분해라고 하는 것은 문제들을 좀 더 작은 단위의 기능들로 나누는 방법을 의미한다. 각각의 함수는 제어하기 쉬워질 때까지 분해된다.
변경되는 요구사항들	변경되는 요구사항은 개발 프로세스의 관점에서 본다면 필수적인 것이다. 훌륭하고 완벽한 요구사항의 정의를 만들어내지 못한 것에 대해 우리 자신이나 사용자들에 대해 비난하기보다, 변경되는 요구사항을 더욱 효과적으로 대응할 수 있는 개발 방법을 채택해야 한다.
객체	객체는 자기 자신의 책임에 의해서 정의된다. 객체는 자기 자신에 대해 책임짐으로써 자신을 이용하는 프로그램의 작업을 단순화한다.
생성자와 소멸자	객체는 생성되고 소멸될 때 호출되는 특별한 메소드를 가지고 있다. 이 특별한 메소드들은 다음과 같다. - 생성자 : 객체를 초기화하거나 세팅한다. - 소멸자 : 객체가 삭제될 때 객체를 정리한다. 모든 객체지향 언어들은 객체를 효과적으로 다루기 위해 생성자와 소멸자를 사용한다.

 

 

객체지향 용어 

 

용어	정의
추상 클래스	개념적으로 유사한 클래스들의 집합이 갖는 공통적인 속성과 메소드를 정의한다. 추상 클래스는 절대 인스턴스화되지 않는다.
속성	객체와 관련된 데이터(또한 데이터 멤버, 멤버 필드 라고 부른다)이다.
클래스	객체의 청사진(blueprint)으로서, 자신의 타입인 객체의 메소드와 데이터를 정의한다.
생성자	객체가 생성될 때 호출되는 특별한 메소드 이다.
파생 클래스	상위 클래스로부터 상세화된 클래스이다. 상위 클래스의 모든 속성과 메소드를 가지지만 또한 다른 속성이나 다른 메소드 구현을 가질 수도 있다.
소멸자	객체가 삭제될 때 호출되는 특별한 메소드 이다.
캡슐화	'온갖 방법의 숨기기'이다. 객체는 자신의 데이터를 캡슐과한다. 추상 클래스는 자신으로부터 파생된 구체적인 클래스들을 캡슐화한다.
기능적 분해	제기된 문제점을 좀더 세분화한 기능들로 작게 나누는 분석 방법이다.
상속	하나의 클래스를 상세화하는 방법으로, 파생 클래스와 그들의 추상 클래스를 연결시킬 때 사용한다.
인스턴스	한 클래스의 특정한 객체이다.
인스턴스화	클래스의 인스턴스를 생성시키는 프로세스이다.
멤버	클래스의 데이터나 메소드이다.
메소드	객체와 관련된 기능이다.
객체	책임을 가지고 있는 하나의 개체이다. 데이터와 이 데이터를 운영하는 메소드를 스스로 포함하고 있는 특별한 보유자이다. 객체의 데이터는 외부 객체로부터 보호된다.
다형성	자신의 타입에 상세화되어 있는 메소드를 구현하는 것과 관련된 객체의 능력이다.
상위클래스	이 클래스로부터 다른 클래스들이 파생된다. 모든 파생 클래스들이 이용할 속성과 메소드의 주요 정의(그리고 재정의(override)가 가능하다)를 포함하고 있다.

출처 ] 알기 쉬운 디자인 패턴 _ 알란 섈로웨이, 제임스 트로트 공저 _ 김유지, 정지훈, 이형로 공역

 

 

728x90

 

 

책의 내용에서 공감되고 이해되며 시야가 조금 더 넓어진 기분이 들었던 것은 사실이다.

그래서 좋은 기분이 들었지만,

사실 개인적으로 이해할 수 없는 내용들이 있었다.

번역의 한계였을까? 아니면 일부러 어려워 보이게 쓰고 싶은 이유에서 였을까?

개인적으로 이해하기 어렵게 설명되어 있는 것 같다는 느낌에 개운하지 못한 부분이 있었다.

 

 

그 중에서 가장 이해할 수 없는 부분이 캡슐화에 대해 설명한 부분,

내가 배운 내용에 따르면 캡슐화는 위에 명시되어 있는 '온갖 방법의 숨기기'가 아니라는 것이다.

 

 

 

 

객체지향이 가지는 다섯가지 특징이 있다.

1. 추상화 _ Abstraction

2. 캡슐화 _ Encapsulation

3. 상속성 _ Inheritance

4. 다형성 _ Polymorphism

5. 정보 은닉 _ Information Hiding

 

 

본 책의 저자는 캡슐화와 정보 은닉을 구분하지 않고 사용한 것 같다.

캡슐화를 해도 정보 은닉을 하지 않을 수 있으며

제대로 캡슐화를 하지 않더라도 정보 은닉은 할 수 있다고 생각한다.

 

 

이 두 가지는 명확하게 구분 되어야 한다.

 

 

 

소프트웨어 공학에서 객체지향 설계를 할 때

loose coupling high cohesion 이라는 말이 있다.

바로 이 내용이 캡슐화에 해당하는 말이고,

하나의 클래스에는 가능하면 메서드를 통해서만 데이터에 접근해야 한다는게 정보 은닉이다.

 

 

물론 경우에 따라서는 클래스의 멤버 필드에 직접 접근해야 할 경우가 있겠지만

(정말 특이한 케이스가 될거라고 생각한다.)

이것은 클래스를 설계한 사람의 의도와 달리 데이터가 변경될 수 있는 위험을 안고 가는 것이기 때문이다.

그렇기 때문에 한 클래스의 멤버 필드는 가능하면 반드시 멤버 메소드에 의해서 변경되어야 한다.