Object Oriented Programming

OOP란 무엇인가? 사실 OOP에 대한 연역적이고 간결한 정의는 보지 못했던 것 같다. 귀납적으로 장황하게 설명한 글들만 봤던 것 같고. 사실 SOLID 원칙도 그림자일 뿐이다. SOLID라는 그림자를 통해 OOP의 실체를 그려봐야 하니까. 아마 단순한 정의만으로는 OOP가 추구하는 바를 세밀하게 표현하기 어렵기 때문일 것이다. 그래도 누구나 얘기하는 OOP에 대해 간결하게 개념 정의를 해보고 싶었고, 개념에 대한 가장 간결한 정의는 이름이니, “객체 지향”이라는 이름에 포커싱해서 생각을 정리해봤다.

객체란?

• 특정한 책임/역할을 갖고 있는, 데이터와 동작이 응집된 단위

지향이란?

• 특정한 책임/역할에 따라 데이터와 동작을 응집 시키는 방향으로 사고하고, 코드로 표현한다.
• 순서에 따라 동작하는 컴퓨터 처럼 사고하지 말고, 책임/관계에 따라 동작하는 인간처럼 사고 하자.

객체를 지향하려면 어떻게 해야 할까?

• 문제를 해결을 담당할 작은 단위(객체)들을 생각해본다.
• 이 때, 책임/역할에 따라 객체들을 구성해보고, 중복을 제거한 뒤, 다양한 객체지향의 원칙들(SOLID 원칙 등)에 부합하는지 확인해본다.
• 문제를 해결하기 위해 구성한 객체들을 배치한다. 객체들은 배치된 곳에서 책임/역할을 다해야 한다.
• 어떤 문제들을 해결하기 위해 객체를 구성해봤더니 그 구성을 어느 정도 일반화시켜 패턴으로 만들 수가 있더라. 이를 디자인 패턴이라고 한다. 객체를 구성할 때 참고해볼 수 있다.

SOLID 원칙

• 단일 책임 원칙(Single Responsibility Principle)
  • 하나의 객체는 하나의 책임만 가져야 한다.
• 개방 폐쇄 원칙(Open Closed Principle)
  • 확장은 쉬워야(Open) 하고, 확장할 때 변경은 적어야(Closed) 한다.
• 리스코프 치환 원칙(Liskov Substitution Principle)
  • 어떤 동작에 사용된 상위 객체를 is a 관계인 하위 객체(하위 객체 is a 상위 객체)로 치환하더라도 잘 동작해야 한다.
• 인터페이스 분리 원칙(Interface Segregation Principle)
  • 객체의 인터페이스가 비대해져서, 필요도 없는 메소드들이 잔뜩 들어있는 인터페이스를 각 사용자가 덩어리째 사용해야 한다면 인터페이스를 분리하라.
• 의존성 역전의 원칙(Dependency Inversion Principle)
  • 의존 관계를 맺어야 할 때에는, 변경이 적은 쪽에 의존하라.

디미터의 법칙(The Law of Demeter)

• 객체의 메소드는 다음의 메소드만 호출할 수 있다.
  • 객체의 메소드
  • 메소드의 파라미터로 넘어온 객체들의 메소드
  • 메소드 내에서 생성되거나 초기화된 객체의 메소드
  • 객체가 직접 소유하고 있는 메소드
  • 메소드에서 접근할 수 있는 전역 메소드
• 객체의 객체의 객체의 … 메소드를 호출하는 일 따위는 하지 말라는 뜻이다. 엮이면 떼어내기 힘드니까.