프로그래밍 패러다임 (객체지향 프로그래밍)

객체지향 프로그래밍(OOP, Object-Oriented Programming)

객체지향 프로그래밍은 객체들의 집합으로 프로그램의 상호 작용을 표현하며 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식을 말한다.

설계에 많은 시간이 소요되며 처리 속도가 다른 프로그래밍 패러다임에 비해 상대적으로 느리다.

 

특징

객체지향 프로그래밍은 추상화, 캡슐화, 상속성, 다형성이라는 4가지 특징이 있다.

 

1. 추상화 (abstraction)

추상화란 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것을 의미한다.

예를 들어 사람이라는 객체가 있다고 가정을 해보자. 사람은 모두 밥을 먹고, 잠을 잔다. 하지만 운전을 하는건 성인만 가능하다고 하면 추상화를 통해 밥을 먹는다, 잠을 잔다라는 기능을 구현하고 사람 아래에 성인이라는 객체를 생성하여 성인 객체에 운전을 한다라는 기능을 구현하면 되는 것이다.

 

2. 캡슐화 (encapsulation)

캡슐화는 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감춰 은닉하는 것을 말한다.

객체의 필드는 private로 선언하고 Getter/Setter를 통해 필드에 접근할 수 있도록 하는것이 대표적인 방법이다.

Getter/Setter를 쓰지 말라는 말이 많은데, 해당 내용은 나중에 자세히 다뤄보려고 한다. (객체지향 생활체조원칙 참고)

 

3. 상속성 (inheritance)

상속성은 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것을 말한다.

코드의 재사용, 계층적인 관계 생성, 유지보수성 측면에서 중요하다.

 

4. 다형성 (polymorphism)

다형성은 하나의 메서드나 클래스가 다양한 방법으로 동작하는 것을 말한다. 대표적으로 오버로딩, 오버라이딩이 있다.

오버로딩은 매개변수를 다르게 하여 같은 이름의 메서드를 여러 개 생성하는 것을 말한다.

오버라이딩은 상속받은 메서드를 재정의하는 것을 말한다.

오버로딩과 오버라이딩의 차이는 추후에 따로 자세히 정리하려고 한다.

---

설계 원칙

객체지향 프로그래밍을 설계할 때는 SOLID 원칙을 지켜야한다. S : 단일 책임 원칙, O : 개방-폐쇄 원칙, L : 리스코프 치환 원칙, I : 인터페이스 분리 원칙, D : 의존 역전 원칙 총 5개의 원칙의 앞글자를 따서 SOLID라고 부른다.

 

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

단일 책임 원칙은 모든 클래스는 각각 하나의 책임만 가져야 하는 원칙이다.

예를 들어 아래의 그림과 같이 Worker라는 클래스가 있다.

Worker 클래스는 지금 택시기사가 하는 역할인 drive, 작가가 하는 역할인 write, 화가가 하는 역할인 draw를 모두 포함하고 있다.

이는 단일 책임 원칙을 위배하기 때문에 아래와 같이 역할을 분리해줘야 한다.

 

2. 개방-폐쇄 원칙

개방-폐쇄 원칙은 유지보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고, 수정할 때는 닫혀 있어야 한다는 원칙이다.

즉, 기존 코드는 변경하지 않고 확장을 할 수 있어야 한다는 뜻이다.

해당 원칙은 우리가 추상화를 배우면서 자연스럽게 배운 원칙이다. 그리고 해당 원칙의 대표적인 예시로 JDBC가 있다.

우리가 만약 어플리케이션을 개발하고 있는데 기존에 MySQL을 사용하고 있다가 Oracle로 변경해야 한다고 가정해보자. 이 때 우리는 JDBC를 사용하고 있기 때문에 다시 코딩할 필요없이 Connection 부분만 교체해주면 된다. 이는 OCP 원칙을 따르고 있는 JDBC가 데이터베이스 확장에 대해 열려있기 때문에 가능한 것이다.

 

3. 리스코프 치환 원칙 (LSP, Liskov Substitution Principle)

리스코프 치환 원칙은 프로그램의 객체는 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야 한다는 원칙이다.

즉, 부모 클래스 타입의 인스턴스를 사용하는 부분에서 자식 클래스 타입의 인스턴스로 대체했을 때 부모 클래스의 의도대로 동작해야한다는 뜻이다. 이는 위에서 설명한 다형성과 관련되어 있다.

해당 원칙의 대표적인 예시로는 컬렉션 프레임워크(Collection Framework)가 있다.

 컬레션 프레임워크 중 List를 예로 들어보도록 하자.

부모는 List 인터페이스가 될 것이고, 자식 클래스인 ArrayList를 이용하여 예제를 만들어보려고 한다.

List<String> list = new ArrayList<>();
list.add("LSP");
list.add("LSP2");
list.remove(1);

변수의 타입을 부모인 List 인터페이스로 선언하였고, 인스턴스를 자식 클래스인 ArrayList로 생성하였다.

실행해보면 알겠지만 문제 없이 동작할 것이다. 이는 LSP를 잘 지켰기 때문이라고 할 수 있다.

LSP를 위반하는 경우는 아마 자식 클래스에서 오버라이딩할 때 제멋대로 만드는 경우가 있을 것 같다.

 

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

인터페이스 분리 원칙은 하나의 인터페이스보다 인터페이스를 목적에 맞게 각각 분리해야한다는 원칙이다.

즉, 인터페이스를 분리함으로써 클라이언트에게 목적에 맞는 인터페이스만을 제공한다는 의미이다.

해당 원칙은 위에서 설명한 단일 책임 원칙과 비슷해보인다. 단일 책임 원칙은 객체가 하나의 책임만을 갖도록 한다면 인터페이스 분리 원칙은 인터페이스를 하나의 책임만 갖게하라는 의미같다.

 

 

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

의존 역전 원칙은 추상화된 인터페이스나 상위 클래스를 두어 의존을 해야지 구체화에 의존하지 말라는 원칙이다.

쉽게 설명하면 상속 관계로 이루어진 모듈을 사용할 때, 하위 모듈을 직접 인스턴스로 생성하여 쓰지 말라는 뜻이다. 그 이유는 만약 하위 모듈을 직접 사용한다면 하위 모듈에 변화가 있을 때마다 클라이언트나 상위 모듈을 자주 수정할 수 있기 때문이다.

3. 리스코프 치환 원칙의 소스 예제를 보면 ArrayList를 사용할 때, 상위 모듈인 List 인터페이스로 변수를 생성한 것을 볼 수 있다.

List<String> list = new ArrayList();

이 또한, DIP를 지키는 코드라고 봐도 된다. 상위 모듈이라고 하면 보통 인터페이스나 부모 클래스가 해당 되는데, 한 번 생각을 해보자.

인터페이스나 부모 클래스를 상속 받는 하위 모듈(구현체)가 더 많이 수정될까? 추상화된 인터페이스나 부모 클래스가 더 많이 수정될까?

보통 구현체인 하위모듈이 더 많이 수정될 것이다. 그래서 변하지 않을 가능성이 더 높은 상위 모듈을 의존하라는 것이다.

---

참고

• 면접을 위한 CS 전공지식 노트
• 리스코프 치환 원칙
• 의존 역전 원칙