YdMinS | 객체 지향 프로그래밍에 대해서

 

객체 지향 프로그래밍에 대해 학습한 내용을 기억하기 위한 글이다. 이해를 돕기 위한 설명보다는 요점을 정리하는 데 중점을 두었다.

객체 지향 프로그래밍에 대해서

객체 지향 프로그래밍

객체 지향 프로그래밍 패러다임이란

[ydmins' 한줄정리]
객체 지향 프로그래밍 패러다임은 현실 세상에 존재하는 개체들을 가상의 객체로 모델링해, 이 객체들끼리 상호작용하도록 소프트웨어를 만드는 방법을 말한다.

 

여기서 객체는 객체 지향 프로그래밍 패러다임의 코드를 구성하는 기본단위로, 실제 코드로 작성할 땐 클래스형태로 작성한다. 클래스는 두가지 정보로 구성된다. 속성값을 담아두는 변수들과 이 변수들을 다루는 메서드이다. 클래스(객체)들은 객체 지향의 주요 4가지 특성(캡슐화, 상속, 다형성, 추상화)을 따르며 상호작용한다.

객체 지향 프로그래밍 언어는 객체 지향적 코드를 작성할 수 있는 언어이다. 이를 위해선 클래스 또는 객체의 개념을 다루는 문법을 제공해야 하며, 이 문법을 이용해서 객체 지향의 4자기 특징을 구현할 수 있어야 한다. 객체 지향 프로그래밍 패러다임을 대표하는 프로그래밍 언어는 C++, Java가 있다.

객체 지향의 4대 속성

캡슐화

캡슐화는 정보의 은닉이라고 표현할 수 있다. 클래스 내 데이터를 외부에서 직접 접근할 수 없게해 세부 구현 내용을 감추고 인터페이스만을 제공하는 것이 캡슐화의 핵심이다. 이런 특징은 자연스럽게 코드를 모듈화 해 코드 재사용성을 높혀 객체의 응집도를 높히고 객체간 결합도를 낮춘다. 이런 모듈화는 코드의 변경 및 유지 보수성을 높여준다는 장점이 있다.

상속

상속은 부모 클래스의 변수와 메서드를 물려 받아 새로운 클래스를 확장해 나가는 것을 말한다. 상속을 할 때는 부모의 모든 변수와 메서드를차용해 사용하면서 새로운 메서드를 추가할 수도 있고, 부모 클래스에 정의된 메서드를 재정의(오버라이딩)할 수도 있다. 자식클래스와 부모클래스 사이의 관계를 표현할 때 흔히 'is-a'관계이 있다고 하지만, 실제로는 'is-a-kind-of'가 명확하다.

상속의 장점은 부모 클래스의 코드를 재작성 없이 사용할 수 있다는 점에서 코드 재사용성을 높여준다. 또 상속이라는 계층적 관계를 통해 전체 코드를 구조적으로 이해하는데 도움을 주기도 한다.

추상화

추상화는 복잡한 시스템을 단순화해 모델링하는 과정을 말한다. 개체의 핵심 정보에 집중하고, 세부 사항은 무시함으로써 복잡성을 낮춘다. 이런 선택과 집중을 통해 개발자는 프로그램의 핵심 부분(로직)에 집중할 수 있다. 추상화는 인터페이스와 추상클래스라는 형식으로 구현한다. 추상화의 장점은 코드를 작성하고 이해하는데의 복잡성을 낮춰준다. 또 상속의 반대 방향의 개념으로써 코드 재사용성과 확장성에 도움을 준다.

다형성

다형성은 자신이 상속한 인터페이스나 부모 클래스의 타입으로 객체를 생성할 수 있는 특성을 뜻한다. 이런 다형성은 여러 타입으로 상속 구현된 다양한 클래스들을 일반적인 방식으로 다룰 수 있게 도와준다. 이를 활용해서 코드를 보다 유연하게 작성할 수 있고, 이는 코드 재사용성과 확장성에 큰 장점이 된다. 

다른 프로그래밍 패러다임

객체 지향 패러다임과 비교되는 대표적인 패러다임은 절차적 프로그래밍과 함수형 프로그래밍이 있다.

절차형 프로그래밍

절차적 프로그래밍 패러다임은 말 그래도 코드가 작성한 순서대로 실행되도록 개발하는 방식이다. 절차적 프로그래밍 패러다임을 대표하는 프로그래밍 언어에는 C언어가 있다.

함수형 프로그래밍

함수형 프로그래밍 패러다임은 함수를 프로그램의 기본 단위로 사용해, 이들의 조합으로 전체 프로그램을 구축하는 방식이다. 함수형 프로그래밍 패러다임을 많이 사용하는 대표적인 언어에 JavaScript가 있다.

장단점 및 사용 이유

객체 지향 프로그래밍 패러다임의 장점은 아래와 같다.

코드 재사용성

객체지향 프로그래밍은 모듈화한 코드를 상속과 다형성을 이용해 활용할 수 있기 때문에 코드 재사용에 매우 유리하다. 이에 반해 절차적 프로그래밍은 모듈화 되어 있지 않아 재사용하기 어렵고, 때문에 중복 코드가 많이 발생한다. 

유지보수성

객체 지향 프로그래밍에선 관련된 모드들을 묶어서 관리하기 때문에(캡슐화) 다른 패러다임들에 비해서 유지보수성이 좋다고 말할 수 있다. 일례로 절차적 프로그래밍에선 코드가 순차적으로 나열돼 있어 특정 코드 수정으로 이후 수 많은 로직에 연쇄적인 영향을 줄 위험이 있다.

확장성

객체지향의 상속을 활용하면 기존 코드에 기능을 추가하거나 변경하는 것이 간편해 객체지향 프로그래밍은 확장성이 좋다고 말한다. 이에 반해 절차적 프로그래밍 패러다임은 이미 코드가 하나의 절차 내에 있기 때문에, 기능을 추가하는 것이 쉽지 않고, 함수형 프로그래밍은 함수간 상태 변화를 반영하며 확장하는 것에 어려움이 있다.

현실 세계 모델링

객체 지향 프로그래밍 패러다임에선 현실 세계의 실제 개체를 모델링 해 사용하기 때문에 직관적으로 이해하기 좋다. 이에 반 해 절차적 프로그래밍과 함수형 프로그래밍은 현실 세계를 반영해 모델링 하는데 어려움이 있다. 왜냐하면 절차적 프로그래밍 방식에서 객체를 절차로 표현해야하고, 함수형 프로그래밍 패러다임에서 객체를 함수로 표현할 때 상태를 표현하고 관리하는 데 어려움이 있기 때문이다.

 

객체 지향 프로그래밍 패러다임의 단점은 아래와 같다.

초기 개념 이해와 설계의 어려움

객체 지향 패러다임은 위에 작성된 것 처럼 꼭 이해해야하는 여러 개념들이 있다. 이런 개념들을 정확히 이해해 실제로 설계에 적용하는 데에는 시간이 걸린다는 어려움이 있다. 

성능

런타임중에 객체를 생성할때와 부모 객체의 메서드를 호출 할 메모리와 연산에 리소스를 사용한다는 점을 알고 있어야 한다.

잦은 객체 생성과 가비지 컬렉션 작동은 메모리 관리 및 프로그램의 원활한 실행에 영향을 미칠 수 있다.

SOLID 원칙

SOLID는 5가지 객체 지향 설계 원칙을 말한다.

Single Responsibility Principle : 단일 책임 원칙

하나의 모듈(클래스, 인터페이스, 메서드 등)은 하나의 책임 또는 기능만을 가져야 한다는 원칙이다. 이 때 하나의 모듈이 단일 책임을 갖고 있다는 판단은 해당 모듈이 사용되는 로직의 시나리오를 살펴보고 판단해야 한다.

Open-Closed Principle : 개방 폐쇄 원칙

확장에는 열려있고 수정에는 닫혀 있어야 한다는 원칙이다. 개방 폐쇄 원칙을 잘 이행했는지를 판단하는 것 보다, 원칙을 위배하지 않았는지 생각하는 것이 편리하다. 

코드의 수정이 기존 코드와 단위 테스트를 해치치 않는다면 개방 폐쇄 원칙을 위반하지 않았다고 할 수 있다.

Liskov Substitution Principle : 리스코프 치환 원칙

상위 클래스가 하위 클래스를 대체할 수 있어야 한다는 원칙이다. 이는 "계약에 따른 설계"로 볼 수 있다. 상위 클래스가 규정해 놓은 규칙을 하위 클래스는 따라야만 한다는 계약!

Interface Segregation Principle : 인터페이스 분리 원칙

인터페이스는 가능한 작게 분리 해 필요한 기능들로만 구성해, 클라이언트가 불필요한 기능을 사용하도록 강요하지 않아야 한다.

Dependency Inversion Principle : 의존성 역전 원칙

상위 모듈은 하위 모듈에 의존하면 안되고, 하위 모듈 또한 상위 모듈에 의존하면 안된다. 둘 다 추상 모듈에 의존해야 한다.