객체지향 개념정리

객체지향이란? 먼저 객체지향에 정답이 있다고 생각하지 않는다 그러하여 나의 견해에 대해 설명하겠다.

 

 

객체 지향 4가지 특성

 

1 - 추상화 (Abstraction) : 불필요한 부분을 제거함으로써 필요한 핵심만 나타낸 것을 추상화라고 할 수 있다. 흔히 일반화, 단순화라고도 하고, 이를 사용하는 목적은 복잡한 특징을 제거하는 것이다.

 

2 - 다형성 (Polymorphism) : 말 그대로 다양한 형태를 가지는 것을 다향성이라고 결론을 내 견해를 가지고있다. 쉽게 말해서 하나의 타입으로 여러 종류의 객체를 참조하는 것.

 

3 - 캡슐화 (Encapsulation) : 객체 내부의 세부사항을 외부로부터 감추는 것을 캡슐화라고 견해를 가지고 있다. 목적으로는 인터페이스만 공개해서 변경하기 쉬운 코드를 만들기 위함이라고 생각한다.

 

4 - 상속 (Inheritance) : 부모로 부터 물려받는것.

 

- 객체지향은 다른 패러다임과 구분하는 중요한 특징이기도 하다. -

 

객체지향의 5가지 설계 원칙 ( SOLID )

 

1. SRP : Single Responsibility Principle ( 단일 책임의 원칙 ) : 하나의 책임을 가진다.

 

2. OCP : Open/Closed Principle ( 개방 폐쇄의 원칙 ) : 합장에는 열려있고 , 변경에는 닫혀있다. 즉, 기존 코드를 변경하지 않고 기능을 추가할 수 있어야 한다는 원칙

 

3. LSP : Liskov`s Substitution Principle ( 리스코프 치환의 원칙 ) : 상위 타입의 객체를 하위 타입의 객체로 치안해도 동작에 전혀 문제가 없어야한다.

 

4. ISP : Interface Segregation Principle ( 인터페이스 분리의 원칙 ) : 많은 기능을 가진 인터페이스를 작은 단위로 분리시킴으로써 클라이언트에게 필요한 인터페이스들만 구현하도록 한다는 개념이라고 생각한다. 즉 , 이를 통해서 클라이언트가 사용하지 않는 기능에 의존하게 되면 예상하지 못한 문제가 발생할 수 있는데, 이를 예방할수있다고 생각한다.

 

5. DIP : Dependency Inversion Principle ( 의존성 역전의 원칙 ) : 의존관계를 맺을 때 자주 변경되는 쪽이 아니라 변경이 거의 일어나지 않는 쪽에 의존하라는 의미며,  자기보다 변하기 쉬운 것에 의존하게 되면 변화의 영향을 많이 받기 때문에 추상화된 인터페이스나 상위 클래스를 둬서 변화의 영향을 받지 않게 하기 위한 원칙이라고 생각한다. 

 

- 객체지향의 다섯 가지 설계 원칙인 솔리드는 훌륭한 객체지향 코드를 작성할 수 있는 원칙이라고 생각한다. -

 

객체지향 패러다임

 

- 적절한 객체에게 적절한 책임을 할당하여 서로 메시지를 주고 받으며 협력하도록 하는 것.

 

- 점점 증가하는 SW 복잡도를 낮추기 위해 객체지향 패러다임 대두

 

- 개인적으로 생각하는 두가지 중요 포인트

1) 클래스가 아닌 객체에 초점을 맞추는 것

2) 객체들에게 얼마나 적절한 역활과 책임을 할당하는지

 

 

절치지향 프로그래밍 VS 객체지향 프로그래밍 (차이)

 

- 책임이 한곳에 집중돼 있는 방식 (getter) -절차

- 책임이 여러 객체로 적절히 분산돼 있는 방식 - 객체

 

객체지향 설계를 표현 하자면

 

- high cohesion(높은 응집도)

- loose coupling (낮은 결합도) 

 

위 두 부분을 객체지향 설계를 할 때 가장 염두해야하는 것이라고 생각한다

쉽게 표현해서 서랍정리라는 개념을 가지고 설명할수 있겠다. 

즉 응집도가 높은 비슷한 것들을 하나로 모아둔다

다른 성격의 것들을 분리 시킴으로써 높은 응집도와 낮은 결합도라고 생각한다.

장점은 응집도가 높으면 어떠한 변경이 생겼을 때 변경의 포인트가 하나로 집중될 수 있다는 부분 즉, 영야 범위를 파악하는것이 한곳에 집중되어 있다는 것이다.  예로 프로그램중 수정에 대한 요구사항을 받을 때가 있을때 영야 범위가 어디까지인지 모르겠고 어디까지 영향을 주는지도 모를 때 이런 표현을 쓴 다는 자체가 객체지향으로 설계가 운전이 되지 않았다는 것을 반증 한다고 생각한다.

객체지향에 있어서 변경에 대한 요구사항이 들어왔을 때 특정 한 부분만 수정을 하면 된다는 것은 응집도가 높다는 부분이고 어떠한 변경이 생겼을 때 다른 곳에 영향을 미치지 않는다면 낮은 결합도라고 생각한다. 즉 , 어떠한 변화가 생겼을 때 다른 곳에 영향을 미치지 않는것을  높은 응집도와 낮은 결합도라고 생각한다.

즉, 이 표현은 유지보수와 관련이 크다고 생각을하고 어떠한 변경이 생겼을 때 높은 응집도와 낮은 결합도를 가지고 유연하게 대응할 수 있음을 의미한다고 생각함.

 

 

객체지향 설계에 있어서 여섯가지 순서로 설계를 한다면

 

1 - 도메인을 구성하는 객체에는 어떤 것들이 있는지 고민

 

2 - 객체들 간의 관계를 고민

 

3 - 동적인 객체를 정적인 타입으로 추상화해서 도메인 모델링 하기 :

객체들이 어떤 상태와 행동을 가지는지 결정이 되면 공통적인 상태와 행동을 가진 객체들을 타입으로 분류할 수 있고 치 타입을 기반으로 클래스를 구현할 수 있다.

즉, 클래스는 공통적인 상태와 행동을 가지는 객체들을 추상화한 것이라고 생각한다.

 

4 - 협력을 설계

 

5 - 객체들을 포괄하는 타입에 적절한 책임을 할당 :

클라이언트와 협력할 수 있는 퍼블릭 인터페이스를 정의한다.

 

6 - 구현하기 

 

참고 - 객체지향 세계에서는 모든 객체가 능독적인 존재