[OOP] 객체지향 프로그래밍

작성일자 : 2021.02.27

 

객체지향 프로그래밍(Object-Oriented Programing)

 

객체지향 프로그래밍(Object-Oriented Programing)이란?

 

객체 지향 프로그래밍은 컴퓨터 프로그래밍 패러다임중 하나로, 프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체를 만들고 그 객체들 간의 유기적인 상호작용을 통해 로직을 구성하는 프로그래밍 방법이다. 말 그대로 객체를 중심으로 프로그래밍을 하는 것.

 

객체란?
사물, 개념 등의 현실의 객체를 추상화 혹은 은유하여 소프트웨어 세상에서 재창조한 것

객체의 특징
OOP의 주요 개념은 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보며, 객체를 이용해 시스템을 분할하는 것이다. 여기서 자율적인 객체란 상태와 행위를 함께 지니고 스스로 자기 자신을 책임지는 객체를 의미한다. 어떠한 객체의 책임의 집합이 그 객체의 역할이 되며, 시스템의 행위를 구현하기 위해 객체는 다른 객체와 협력한다.

 

객체지향 프로그래밍의 장/단점

 

장점

• 코드 재사용이 용이
• 유지보수가 쉬움
• 대형 프로젝트에 적합

 

단점

• 처리속도가 상대적으로 느림
• 객체가 많으면 용량이 커질 수 있음
• 설계 시 많은 시간과 노력 소요

 

객체지향의 4대 특징

 

캡슐화 (Encapsulation)

• 객체의 정보를 숨기고 외부에서 인터페이스를 통해서만 접근이 가능하도록 설계하는 것 (접근 제어 지시자, Access Specifiers)
• 단순히 private으로 설정해놓고 getter, setter를 제공한다면 이는 캡슐화가 아니다. 변할 수 있는 어떤 것이라도 감추어 응집도는 높게, 결합도는 낮게하고 내부 구현의 변경이 있더라도 외부의 객체는 영향이 없도록 하는 것이 캡슐화이다.

상속성 (Inheritance)

• 기존 객체를 재사용하여 조상과 자손 관계의 새로운 객체를 설계하는 것. 상속받은 자손 객체는 조상 객체의 모든 멤버를 사용할 수 있다. (extends, overriding)

추상화 (Absctraction)

• 불필요한 부분은 빼고 필요한 핵심적인 개념 또는 기능만을 추려 표현하는 행위 (abstract, 객체 설계)

다형성 (Polymorphism)

• 서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것. 즉 서로 다른 타입에 속하는 객체들이 동일한 메시지를 수신할 경우 서로 다른 메서드를 이용해 메시지를 처리할 수 있는 메커니즘 (overloading, List -> ArrayList 관계)

 

 

객체지향의 설계 

 

SOLID 원칙을 지키며 적절한 협력, 책임, 역할을 가지는 객체를 설계하여 OOP 패러다임을 올바르게 실현하는 것

 

 

객체지향 설계 주요 개념

 

SOLID(5대 원칙)

• 단일 책임 원칙 ( Single Responsiblility Principle )
  • 객체는 단 하나의 책임 혹은 목적만 가져야 함
• 개방/폐쇄 원칙 ( Open Closed Principle )
  • 객체가 확장에는 개방되어 있고, 변경에는 닫혀있어야 함.
  • > 새로운 기능을 제공하기 위해서 기존 클래스를 수정하는 것을 허용하거나 권장하지 말고 기존 클래스를 확장하는 방법을 찾아야 한다는 것을 의미
• 리스코프 치환 원칙 ( Liskov Substitution Principle )
  • 한 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 치환이 가능해야 함.
  • > 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 함을 의미
• 인터페이스 분리 원칙 ( Interface Segregation Principle )
  • 클라이언트가 사용하지 않는 메서드에 대해서는 의존하지 않아야 함
  • > 범용 인터페이스 하나를 사용하기보다는, 특정 클라이언트에 특화되도록 인터페이스 여러 개로 분리해야 함을 의미
• 의존 역전 원칙 ( Dependency Inversion Principle )
  • 상위 계층이 하위 계층에 의존하는 전통적인 의존 관계를 역전시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다.
  • > 의존관계를 맺을 때 변화하기 쉬운 것(구체적인 것)보다는 변화하기 어려운 것(추상적인 것)에 의존해야 함을 의미. Strategy 디자인 패턴 참고

객체 요소

• 협력
  • 스스로 해결하기 어려운 문제를 해결하기 위해 다른 객체의 도움을 구하는 것. 객체는 메시지를 통해 또 다른 객체에게 도움을 요청하고, 요청을 받은 객체는 필요한 도움을 메시지의 형태로 응답한다. 이것이 협력의 과정이며 이때 두 객체는 협력의 관계에 있다고 표현한다. (객체 간 메시지 송수신 과정)
• 책임
  • 어떤 협력에 참여하여 적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 가진다고 표현하다. (인터페이스 구현체, 객체의 메서드)
• 역할
  • 어떤 협력안에서 책임의 집합을 역할이라고 한다. 한 역할 안에는 하나 이상의 책임이 존재한다. (인터페이스)

 

소프트웨어 설계에 법칙이란 존재하지 않는다. 법칙에는 예외가 없지만 원칙에는 예외가 넘쳐난다. 초보자는 원칙을 맹목적으로 추종한다. 심지어 적용하려는 원칙들이 서로 충돌하는 경우에도 원칙에 정당성을 부여하고 억지로 끼워맞추려고 노력한다. 원칙이 현재 부적합하다고 판단된다면 과감하게 원칙을 무시하라. 
- 오브젝트 中 -

 

Reference

객체지향의 사실과 오해 - 조영호

오브젝트 - 조영호