개발을 처음 공부하기 시작하면 초기에 듣게 되는 개념중 하나가 객체 지향 프로그래밍입니다.
그만큼 많이 들었고, 익숙해서 잘 안다고 생각되었는데.. 얼마전 객체 지향 프로그래밍에 대한 설명이 필요한 상황에서 생각처럼 설명이 잘 되지 않아 다시한번 정리가 필요하다고 생각되어 글을 작성합니다. 🤣 🤣
상태(state)와 행위(behave)로 이루어진 어떠한 것이 객체이다. 예를 들어, '시계'를 하나의 객체라고 한다면 상태(state)에는 모양, 종류, 가격, 디지털인지 등이 있을 수 있고, 행위(behave)에는 '시간 흐름', '알람' 등이 있을 수 있을 수 있다.
프로그래밍의 패러다임 중 하나로, 여러 객체들 간의 상호작용을 통해 로직을 구성하는 프로그래밍
초기 프로그래밍 방식은 절차적 프로그래밍 방식이었다. 프로그램이 명령어의 모임으로 인식이 되었다. 이러한 방식은 프로그램이 조금만 복잡해지면 프로그래밍의 복잡도 상승은 물론 유지보수가 불가능한 수준이 될 수 있다. 간단하게 예를들어 롤이라는 게임을 이와 같이 순서도로 표현한다고 생각해보면 절차적 프로그래밍의 느낌을 알 수 있을 것 같다.. 🙂 🙂
이 문제를 해결하기위해 에츠허르 다익스트라가 1968년 GOTO문의 해로움이라는 논문에서 프로그램을 함수(procedure) 단위로 나누고 함수끼리 호출하는 구조적 프로그래밍 방식을 제안하였다. 프로그램이라는 큰 문제를 여러개의 작은 문제로 나누어 해결하기 때문에 하향식(Top-down)방식이라고도 한다.
하지만 함수는 데이터의 처리 방법이 구조화 되었을 뿐, 데이터 자체는 구조화하지 못했다. 프로그램의 모든 변수가 한 공간에 선언된다면 이름 짓는 것부터 힘들 것 같은 느낌이..
이런 이유로 작은 문제들을 해결할 수 있는 객체들을 만든 뒤, 이 객체들의 상호작용을 통해 큰 문제를 해결하는 상향식(Bottom-up) 해결법인 객체 지향 프로그래밍이 등장하였다.
객체는 오직 하나의 책임을 가져야 한다.
객체는 확장에 대해서는 개방적이고 수정에 대해서는 패쇄적이어야 한다는 원친이다. 즉, 객체 기능의 확장을 허용하고 스스로의 변경은 피해야 한다.
자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있다는 원칙이다. 즉 부모 클래스가 들어갈 자리에서 자식 클래스를 넣어도 계획대로 잘 작동해야 한다는 것이다.
클라이언트에서 사용하지 않는 메서드는 사용해선 안된다. 그러므로 인터페이스르 다시 작게 나누어 만든다. OCP와 비슷한 느낌도 들지만 엄연히 다른 원칙이다. 인터페이스의 SRP라고 할 수 있다.
추상성이 높고 안정적인 고수준의 클래스는 구체적이고 불안정한 저수준의 클래스에 의존해서는 안된다는 원칙으로서, 일반적으로 객체지향의 인터페이스를 통해서 이 원칙을 준수할 수 있게 된다. (상대적으로 고수준인) 클라이언트는 저수준의 클래스에서 추상화한 인터페이스만을 바라보기 때문에, 이 인터페이스를 구현한 클래스는 클라이언트에 어떤 변경도 없이 얼마든지 나중에 교체될 수 있다.