객체 지향 프로그래밍 (OOP)에 대해서 알아보자

😀이전 포스팅(절차지향vs객체지향vs함수형)에 이어서 이번 포스팅에 객체지향 설계와 객체지향 프로그래밍에 대해서 알아보자

객체지향 설계

훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것이다.

• 좋은 설계란 요구하는 기능을 온전히 수행하면서 추후의 변경을 매끄럽게 수용할 수 있는 설계이다.

• 변경 가능한 코드란 이해하기 쉬운 코드다. 만약 코드를 변경해야 하는데 그 코드를 이해할 수 없다면 변경에 유용하더라도 코드를 수정하겠다는 마음이 선뜻 들지는 않을 것이다.

• 변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계이다.

😀이전의 객체지향의 특징을 살리면서 설계를 짜는 것을 객체지향적 설계라고 할 수 있고, 이 설계를 기반으로 프로그래밍하는 것이 객체지향 프로그래밍 이다.

객체 지향 설계의 5원칙 (SOLID)

SOLID는 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 사용한다.

😀객체 지향 프로그래밍 및 설계의 다섯가지 기본원칙으로 각 원칙의 맨 앞단어를 하나씩 가져와 만든 것이다.
다섯가지 각각의 원칙에 대해서 알아보자

1. 단일 책임의 원칙 (Single Responsibility Principle, SRP)

하나의 객체는 단 하나의 책임을 가져야 한다.
즉, 클래스나 모듈을 변경할 이유가 단 하나 뿐이어야 한다는 원칙이다.

• SRP는 책임이라는 개념을 정의하며 적절한 클래스의 크기를 제시한다.

• SRP는 객체 지향설계에서 중요한 개념이고 이해하고 따르기 쉬운 개념이지만, 프로그래머가 가장 무시하는 규칙이다. 일반적인 프로그래머는 “깨끗하고 우아하게 작성된 소프트웨어"보다 “동작하기만 하는 소프트웨어"에 초점을 맞추기 때문이다.

2. 개방-폐쇄 원칙 (Open-Closed Principle, OCP)

소프트웨어 엔티티 또는 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
즉, 소프트웨어 개체의 행위는 확장될 수 있어야 하지만, 개체를 변경해서는 안된다.

• 조금 더 쉽게 설명하자면, 기존 코드에 영향을 주지않고 소프트웨어에 새로운 기능이나 구성 요소를 추가할 수 있어야 한다는 것이다.

• 만약 요구사항을 조금 확장하는 데 소프트웨어를 엄청나게 수정해야 한다면, 소모되는 개발 코스트또한 엄청나게 증가할 것이다.

3. 리스코프 치환 원칙 (Liskov substitution principle, LSP)

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

• 여기서 하위 타입이란 S 타입의 객체 o1, 각각에 대응하는 T 타입 객체 o2가 있고, T 타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다.
  즉, S가 T의 하위 유형이면 해당 프로그램의 속성을 변경하지 않고 T 객체를 S 객체로 대체할 수 있다.

• 만약 부모 클래스와 자식 클래스가 있는 경우 서로를 바꾸더라도 해당 프로그램에서 잘못된 결과를 도출하지 않는 것이다.

4. 인터페이스 분리 원칙 (Interface segregation principle, ISP)

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
즉, 클라이언트가 필요하지 않는 기능을 가진 인터페이스에 의존해서는 안 되고, 최대한 인터페이스를 작게 유지해야한다.

• 조금 더 쉽게 설명하자면, 사용자가 필요하지 않은 것들에 의존하지 않도록, 인터페이스를 작게 유지해야 한다는 것이다.

5. 의존성 역전 원칙 (Dependency Inversion Principle, DIP)

프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.
즉, 높은 계층의 모듈(도메인)이 저수준의 모듈(하부구조)에 의존해서는 안된다.

• 고수준 계층의 모듈(도메인)은 저수준 계층의 모듈(하부구조)에 의존해서는 안된다. 둘 다 추상화에 의존해야 한다.

• 추상화는 세부 사항에 의존해서는 안 된다. 세부 사항은 추상화에 의존해야 한다.

객체지향 프로그래밍(OOP)

데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식을 객체지향 프로그래밍(Object-Oriented Programming)이라고 부른다.

• 객체 지향 프로그래밍은 코드를 추상화해 직관적으로 사고할 수 있기 때문에, 대표적인 프로그래밍 방법론으로 적용되고 있다.

• 객체 지향 프로그래밍에서는 자동차, 동물, 사람 등과 같은 현실 세계의 객체를 유연하게 표현할 수 있다.

• 객체는 어떠한 특성을 가지고 있으며 특정 기능을 수행할 수 있다.

• 자동차는 객체이고 출발, 정지, 운행 및 제동과 같은 기능을 수행할 수 있다.

OOP의 등장배경

객체지향 프로그래밍의 등장 배경은 프로그래밍에서 발생하는 복잡성과 유지보수성 문제를 해결하기 위해서이다.

이전의 절차지향적 프로그래밍에서는 데이터와 함수가 분리되어 있었기 때문에 코드의 재사용성과 유지보수성이 낮았다.

하지만 객체지향 프로그래밍에서는 데이터와 함수를 하나의 단위인 객체로 묶어 처리하므로, 코드의 재사용성과 유지보수성이 높아진다.

why? 왜 OOP를 사용해야할까?

객체지향 프로그래밍은 데이터와 프로세스를 하나의 단위로 처리하는 특성을 가지고 있기 때문에 코드를 수정해야할 때 어떤 코드에서 문제가 발생했는지 개발자들이 직관적으로 인지할 수 있으며 여러곳에 분산된 모든 코드를 수정해야하는 것이 아닌 해당 로직을 수행하는 코드만 수정하더라도 문제가 해결될 수 있다.

😀우리는 프로그래밍을 하면서 효율적으로 시간을 관리할 수 있어야한다. 그렇게 하기 위해선 코드를 얼마나 깔끔하게 짜느냐도 중요하지만, 코드 변경점이 발생하더라도 최대한 코드를 적게 수정하여 더욱 많은 시간을 만들 수 있어야한다.

만약 API를 만들 때 마다 복사 → 붙여넣기 방식으로 동일한 코드를 여러군데 분산을 시켜놓았을 때, 해당 로직을 수행하는 코드를 수정해야할 때 복사한 모든 코드를 일일히 찾아가며 수정을 해야하는 상황이 발생 할 것이다.

발생한 문제 상황을 빠르게 인지하고, 어떤 코드에서 오류가 발생했는지 빠르게 찾아보며, 오류 사항을 빠르게 고쳐 개발에 사용하는 시간을 최대한으로 줄이는것을 목표로 삼아야한다.

OOP의 장단점

😀 객체지향 프로그래밍을 하였을 때의 장단점은 아래와 같다.

장점

• 코드의 재사용성과 유지보수성이 높다.
  의존성을 효율적으로 통제할 수 있는 다양한 방법을 제공함으로써 요구사항 변경에 좀 더 수월하게 대응할 수 있는 가능성을 높여준다.

• 코드의 가독성이 좋고, 디버깅이 쉽다.
  동작을 기준으로 프로그래밍을 진행하는 것보다 데이터를 중심으로 프로그래밍을 하게되면 코드의 덩치가 커지더라도 일관성을 유지하기 좋다.

• 프로그램의 확장성과 유연성이 높다.
  이해하기 쉽고, 객체 내부의 변경이 객체 외부에 파급되지 않도록 제어할 수 있기 때문에 변경하기 수월하다.

• 객체의 재사용이 가능하므로 개발 속도가 빠르다.

단점

• 초기 개발 비용이 높다.
  객체지향 프로그래밍은 매우 복잡한 시스템에서 사용할 때 가장 효과적이다. 하지만 복잡하지 않은 문제에 대해서는 코드를 작성하기가 더 어려울 수 있다. 또한 객체간의 관계를 모델링하기 위한 상속과 같은 개념들이 이해하고, 설계하는데 개발자의 코스트가 소모된다.

• 객체 간의 상호작용이 많아질 경우 코드의 복잡성이 증가할 수 있다.
  상속을 사용하는 것은 코드를 복잡하게 만들어서, 유지 보수성을 떨어뜨릴 수 있습니다. 또한 자식 클래스가 부모 클래스의 기능을 오버라이딩 하면, 이전에 구현한 코드가 의도치 않게 동작할 수 있는 문제가 발생할 수 있다.

• 성능 저하가 발생할 수 있다.
  객체 지향 프로그래밍은 일반적으로 더 많은 메모리를 사용하고 CPU 사용량이 높아지기 때문에 성능 저하가 발생할 수 있다.

참고자료(출처)
노마더 코더 유튜브 동영상 객체지향 프로그래밍? 문과도 이해쌉가능. 10분컷.
스파르타 코딩클럽 Node.js 심화 강의자료
위키백과 검색결과 객체 지향 프로그래밍
ChatGPT 검색결과
면접을 위한 CS전공지식 노트 (도서)