토비의 스프링 - 1. 객체 지향 프로그래밍

객체 지향 프로그래밍

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.

이전에는 상태와 함수를 각각 관리했었는데 프로그램이 커지니 관리하기 어려워 관련 있는 상태와 함수를 모은 객체를 만들었다.

객체를 사용함으로써 유연하고 변경이 쉬운 소프트웨어를 개발할 수 있다.

캡슐화

객체의 정보의 접근과 연산을 제어함으로서 아래와 같은 이득을 얻는다.

• 내부 로직을 외부에서 알 필요가 없이 사용할 수 있다.
• 변경에 영향을 줄 수 있는 범위를 최소화하는 변경 용이성을 확보한다.

하지만 이러한 개념이 객체 지향에만 국한 된 것은 아니다. C 언어에서도 .h 파일로 완벽한 캡슐화가 가능하다.

그리고 여러 객체 지향 언어가 캡슐화를 강제하지 않고, 데이터를 우회해서 사용하지 않을 것이라는 믿음을 기반으로 사용한다.

때문에 캡슐화가 객체 지향의 특징이라고 말하기에는 어려울 것 같다. ( 개인 생각 )

상속

상속은 새로운 클래스가 기존의 클래스의 자료와 연산을 이용할 수 있게 하는 기능으로 아래와 같은 이득을 얻는다.

• 코드 재사용성이 높아진다.
• 공통된 인터페이스를 강제함으로써 안전한 소프트웨어 개발이 가능해졌다.

상속을 흉내내는 요령이 C 에는 존재하지만 상속만큼 편리하지 못했지 못했다.

• 부모 타입에 대해 명시적인 타입 캐스팅이 필요했다.
• 부모에서 요구하는 동작을 강제할 수 없었다.

다형성

다형성이란 프로그램 언어 각 요소들(상수, 변수, 식, 객체, 메소드 등)이 다양한 자료형(type)에 속하는 것이 허가되는 성질을 가리킨다.

C 로 다형성을 구현할 수 있지만 상속과 동일한 문제를 가지고 객체 지향은 언어 차원에서 안전한 다형성을 구현할 수 있게 해주었다.

interface Car { public void moveForward(); }
class Tesla implements Car { public void moveForward() { ... } }

class User {
	void driveCar() {
		**Car car = new Tesla();
		car.moveForward();**
		// ...
	}
}

객체 지향의 핵심

역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며, 변경이 편리해진다.

• 클라이언트는 대상의 역할 ( 인터페이스 ) 만 알면 된다.
• 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
• 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
• 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

객체 지향 설계 원칙 5 가지 - SOLID

위의 내용은 언어에서 지원해주는 특성을 이야기하고 설계 원칙은 따르면 유연한 프로그래밍을 개발할 수 있다는 권장사항에 가깝다.

SRP ( Single responsibility principle )

• 한 클래스는 하나의 책임만 가져야 한다.
• 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다.

OCP ( Open / closed principle ) *

• 확장에는 열려있어야 하고 변경에는 닫혀있어야 한다.
• 클라이언트가 구현 클래스를 직접 선택하지 않아야 한다.
  • 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.

LSK ( Liskov substitution principle )

• 다형성을 지원하기 위해 인터페이스를 구현한 구현체를 믿고 사용하기 위해 구현체는 인터페이스를 모두 준수해야한다는 원칙

ISP ( Interface segregation principle )

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
• 인터페이스가 명확해지고, 대체 가능성이 높아진다.

DIP ( Dependency inversion principle ) *

• 역할에 의존해야지 구현에 의존해서는 안된다.