Object-Oriented Programming(OOP)
정의
프로그램 설계 방법론이자 개념의 일종으로
프로그램을 단순히 데이터와 처리 방법으로 나누는 것이 아니라,
프로그램을 수많은 '객체(object)'라는 기본 단위로 나누고 이들의 상호작용으로 서술하는 방식이다.
객체란 하나의 역할을 수행하는 '메소드와 변수(데이터)'의 묶음으로 봐야 한다.
객체 {(속성), (행동)}
Q. 객체란 무엇인가?
우리가 살아가면서 보는 모든 존재라 할 수 있다.
대상의 특징을 속성이라 하고, 대상의 움직임을 행동이라 한다.
어떤 특징을 갖고 움직이는 모든 것이 객체다.
Q. 모든 게 객체인가?
그렇다. 현실에 존재하든, 가상으로 존재하든 속성과 행동을 떠올릴 수 있다면 모두 객체이다.
객체지향은 특정 언어가 아니라 개념이다.
"클래스는 객체이며 구조체는 객체가 아닌 데이터의 집합"이라는 설명 역시 틀렸고,
특정 언어가 객체지향 언어라는 말도 완전히 틀린 표현이다.
객체 지향 프로그래밍이란 프로그램을 객체들과 객체들 간의 소통으로 바라보는 것!
역사
초기 프로그래밍 방식은 절차적 프로그래밍방식이었다.
입력을 받아 명시된 순서대로 처리한 다음, 그 결과를 내는 것뿐이라는 생각이 지배적이었다.
프로그램을 명령어의 모음으로 인식한 것이다.
또한 프로그래밍이란 어떻게 어떤 논리를 어떤 순서대로 써나가는 것인가로 간주되었다.
즉, 프로그램 자체가 가지는 기능에 대해서만 신경을 썼지,
이 프로그램이 대체 어떤 데이터를 취급하는 것인가에는 그다지 관심이 없었던 것이다.
그래서, 이 방식은 조금만 복잡해지면 순서도로 나타내는 것이 불가능할 정도로 꼬였다.
다른 사람이 보고 이해하는 것이 거의 불가능할뿐더러 심지어는 작성한 본인조차도 유지보수에 어려움을 겪게 된다. 명령어의 양이 많아지는 것은 기본이고, 특정 코드 부분은 어디에 사용되는 코드고 해당 코드 부분은 어디까지 이어지는지의 흐름을 파악하기도 힘들어지며, 중복 코드 대처도 매우 골치 아프다.
이 문제를 해결하기 위해 에츠허르 다익스트라가 1968년 GOTO문의 해로움이라는 논문에서
프로그램을 프로시저(procedure) 단위로 나누고 프로시저끼리 호출을 하는
구조적 프로그래밍 방식을 제안하면서 이러한 위기를 벗어나게 된다.
프로그램이라는 큰 문제를 해결하기 위해 그것을 몇 개의 작은 문제들로 나누어 해결하기 때문에
하향식(Top-down) 방식이라고도 한다.
하지만, 함수는 데이터의 처리 방법을 구조화했을 뿐, 데이터 자체는 구조화하지 못했다.
코드의 덩치가 커지면서 함수가 접근할 수 있는 데이터의 범위에 명시적인 제한을 걸어야 하는 상황이 도래했다.
이를 지역 변수나 구조체(struct) 등으로 어찌 제어하고 있기는 했지만 더 근본적인 해결책이 필요했다.
이를 극복하기 위한 대안으로 등장한 것이 바로 객체 지향 프로그래밍이다.
큰 문제를 작게 쪼개는 것이 아니라, 먼저 작은 문제들을 해결할 수 있는 객체들을 만든 뒤,
이 객체들을 조합해서 큰 문제를 해결하는 상향식(Bottom-up) 해결법을 도입한 것이다.
이 객체란 것을 일단 한번 독립성/신뢰성이 높게 만들어 놓기만 하면
그 이후엔 그 객체를 수정 없이 재사용할 수 있으므로 개발 기간과 비용이 대폭 줄어들게 된다.
객체 지향 프로그래밍으로 프로그램을 만들려면
1. 프로그램에 어떤 객체들이 필요할지 정한다.
2. 객체들의 속성과 행동을 정한다.
3. 객체들이 서로 어떻게 소통할지 정한다.
객체 지향 4가지 필수 개념
추상화(Abstraction)
캡슐화(Encapsulation)
상속(Inheritance)
다형성(Polymorphism)
객체 설계 5원칙
단일 책임 원칙 (Single Responsibility Principle)
개방 폐쇄 원칙 (Open-closed Principle)
리스코프 치환 원칙 (Liskov Substitution Principle)
인터페이스 분리 원칙 (Interface Segregation Principle)
의존 관계 역전 원칙 (Dependency Inversion Principle)