객체지향을 이루는 개념과 5대 설계 원칙

객체지향을 이루는 개념과 5대 설계 원칙

OOP, Object Oriented Programming

객체지향(Object Oriented)이란, 현실 세계를 반영하는 객체 기반의 모델링 기법이다. 근래에 유행하는 대부분의 언어는 모두 객체에 기반하고 있으며, 이러한 언어들을 객체지향 언어라고 지칭할 수 있다. 객체지향 언어는 현실 세계의 문제를 추상화하고 캡슐화하며, 상속과 다형성을 통해 다양한 문제를 해결할 수 있는 OOP(Object Oriented Programming)의 도구로 작용한다. 즉, 객체지향 언어를 이용한 프로그래밍 기법으로 코드의 재사용성을 높이고 유지보수 비용을 감소시키는 것이 OOP 패러다임의 근본적인 목표라 할 수 있다.

Features

객체지향을 이루는 개념으로 보통 아래 네 가지 특징을 언급하며, 이러한 특징을 지원하는 언어를 객체지향 언어라고 할 수 있다.

  • Encapsulation
    • 구현 수준의 행위와 상태는 감추고 공개할 인터페이스를 정의한다.
    • 노출된 인터페이스는 클라이언트와 상호 작용하기 위한 행위를 묘사한다.
    • 구현체는 오직 인터페이스에 의존하고, 상속과 더불어 다형적 행위를 가능하게 한다.
  • Abstraction
    • 클래스의 공통적 특징을 추출하여 상위 계층으로 표본화한다.
    • 공통적 특징은 상속을 통해 하위 계층으로 전파되고, 중복을 제거한다.
  • Inheritance
    • 상속은 추상 계층을 구조화, 일반화한다.
      • 추상 계층이 아닌, 공통 기능을 위한 모델링이라면 상속보다 위임을 통해 클래스의 상하 계층 관계를 제거한다.
    • 보통 추상화 계층을 표현하기 위해 사용한다.
  • Polymorphism
    • 캡슐화, 상속과 함께 동작하며 실행 시점에 동작의 구현을 결정하고, 애플리케이션의 흐름을 제어(flow of control)한다.

Principles

위에서 언급한 OOP 특징을 바탕으로 한, 대표적인 객체지향적 설계 원칙들을 몇 가지 추려서 -SOLID 원칙-이라고 부른다. 객체지향 모델링을 포함하여 패턴, 설계의 기본이 되는 원칙으로 통용된다.

  • SRP, Single Responsibility Principle
    • 단일 책임의 원칙.
    • 클래스는 그 기능을 수행함에 있어서 오로지 하나의 책임을 가질 수 있도록 설계되어야 한다.
    • 하나의 책임을 가질 수 있도록 잘 쪼개진(fine-grained) 관심사의 크기를 가지고 구현되어진 클래스는 클라이언트와의 상호 작용에 있어서 코드 변경의 범위를 최소화 할 수 있다.
  • OCP, Open-Close Principle
    • 개방-폐쇄의 원칙.
    • 확장에는 개방적이고, 변경에는 폐쇄적이어야 한다.
    • 클래스의 행위는 응집력있게 구현되어야 하고, 추상화와 다형성을 통해 확장성있게 제어될 수 있어야 변경에 대한 비용을 최소한으로 줄일 수 있다.
    • 객체지향에서 재사용 가능한 코드를 만드는 기반 원칙이다.
  • LIP, Liskov Substitution Principle
    • 리스코브 치환의 원칙.
    • 하위 타입은 언제나 상위 타입으로 치환 가능하여야 한다.
    • 이는 하위 구현에 의존하지 않고, 노출된 인터페이스나 추상 클래스를 통해 상위 수준에서 호환성을 염두하고 설계되어야 한다는 의미이다.
  • ISP, Interface Segregation Principle
    • 인터페이스 분리의 원칙.
    • 클래스는 원하는 인터페이스를 선별적으로 선택하고 구현할 수 있어야 하며, 이를 위해서 인터페이스는 책임 별로 잘 분리되어 있어야 한다.
    • 인터페이스가 크기가 크면, 구현 주체인 클래스의 구현 범위도 덩달아 커지게 되고 의미가 모호해진다.
  • DIP, Dependency Inversion Principle
    • 의존성 역전의 원칙.
    • 구현 타입이 아닌 추상 또는 인터페이스 타입을 사용해야 한다.
    • 구현 내용은 변경 가능성이 높기 때문에, 구현을 묘사하는 추상 타입으로 동작할 수 있어야 코드 변경에 대한 비용을 줄일 수 있다.

Conclusion

객체지향 패러다임으로 관점을 넓히는 것은 많은 연습과 노력이 필요하다. OOP가 소프트웨어 개발의 만능은 아닐지라도, 아직까지 많은 객체지향 프로그램에서 절차-구조적 관점으로 개발되어 있는 사례를 볼 수 있다. 상황에 따라 적절한 원리, 원칙을 따져보고, 코드의 지속적인 리팩토링을 통해 유지보수와 확장이 쉬운 애플리케이션을 지향한다면, 위에 설명한 객체지향의 개념과 원칙들은 분명 중요한 기반이 된다.

Tags:

Updated:

Comments