1. OOP
객체지향프로그래밍. 프로그램을 객체들로 구성한다
-
객체란 개념적인 용어로 기술적 용어인 class나 instance와 혼용하지 않도록 해야한다
-
객체는 한 책임을 가지고(담당하는 일) 서로 협력해서 프로그램을 이룬다
-
객체들은 형(type)으로 구분한다
2. OOP의 4가지 특징
OOP은 다음과 같은 특징들을 가진다
1. 캡슐화
2. 상속
3. 추상화
4. 다형성
- 이 특징들은 서로 연결된 것으로, 독립적으로 구분하려고 하면 이해에 어려움이 있을 수 있다
2-1. 캡슐화
-
완성도 : 객체는 기능을 수행하는 단위로 그 자체로 완전함을 갖춘다. 이때 완전함이란 높은 응집도를 달성하는 것을 말할 수 있다. 응집도란 하나의 책임을 위한 기능(메소드)들이 너무 분산되지 않고 한 객체에 모여있는 정도를 말한다.
-
정보 은닉 : 객체 안에서 밖으로, 또는 밖에서 안으로 정보에 접근할 수 없다
즉 객체는 스스로 동작할 수 있는 환경을 가지고(높은 응집도), 외부 의존을 최소화(낮은 결합도)하고 외부의 침략을 제한 해야한다.
2-2. 상속
-
객체는 다른 객체를 상속할 수 있다
-
상속에 대해 흔히하는 오해는 바로 상속을 공통적인 기능을 공유하기 위한 것으로 착각하는 것이다
-
상속의 목적은 객체의 부모 자식 관계, 즉 추상과 구체화의 관계를 위한 것이지 기능 공유가 아니다
2-3. 추상화
-
추상화된 객체를 추상체, 구체화된 객체를 구상체라고 한다
-
추상화는 상대적인 것으로, 상위 객체는 반드시 하위 객체보다 추상적이어야한다
2-4. 다형성
-
하나의 형(type)을 여러가지로 표현할 수 있다
-
인터페이스 변수로 객체를 레퍼런스하는 것이 대표적인 런타임 다형성이다
interface Animal {}
class Human implements Animal {}
class Dog implements Animal {}
Animal animal = new Human();
Animal animal = new Dog();3. OOP 설계
3-1. OOP의 표현
-
아래 2가지를 보여 OOP 설계를 설명할 수 있다. UML 중 class diagram이 이를 잘 표현한다
- 어떤 객체들로 구성할 것인가?
- 객체간 관계는 어떻게 할것인가?
-
실무에서 UML을 작성하는 경우는 드물고, 보통 더 간견할 객체간 관계도만 그린다고 한다
- 객체 : 사각형 안에 클래스명, 필드, 메소드를 표현한다
- 관계 : 객체간 연결된 선을 통해 표현한다
3-2. OOP 원칙
- 객체를 어떻게 잘 나누고 연관 지을 수 있는지 고민 끝에 SOLID 원칙이 고안 되었다
- S : Single Responsibility Principle
- O : Open Close Principle
- L : Liskov Substitution Principle
- I : Interface Seperation Principle
- D : Dependency Inversion Principle
- 각 원칙에 대한 자세한 설명은 이후 별도 포스트에서 다루도록 하겠다
3-3. 디자인 패턴
-
SOLID 원칙을 정확하게 따라서 설계하기란 쉬운일이 아니다
-
원칙들로만 이뤄져 있기 때문에 해석의 자의적이될 위험성이 있고, 객체 작성마다 각 원칙을 고려하기는 어렵다
-
여러 SW 엔지니어들이 SOLID 원칙에 따라 OOP를 설계 했고, 이런 설계들에서 나타나는 공통점들을 정리한 것이 바로 디자인 패턴이다
-
SOLID 원칙이 추상체라면, 디자인 패턴은 구상체라고 생각할 수 있다
객체지향프로그래밍이라는 패러다임은 소프트웨어가 고도화 되며, 더 빠른 개발과 쉬운 유지보수를 위해 탄생했다. 단순히 자바나 C++같은 객체지향형 언어를 사용한다고 OOP를 잘 사용하는 것은 아니다. OOP를 잘 사용하기 위해서는 SOLID 원칙에 맞는 소프트웨어를 작성해야하고, 이를 보다 쉽게 하기위해 디자인 패턴을 활용할 수 있다.
