1. 객체지향이란?

객체 지향이란 프로그래밍에서 필요한 데이터를 추상화 시켜 상태와 행위를 가진 객체로 만들고, 객체들간의 상호작용을 통해 로직을 구성하는 프로그래밍 방법이다.
나는 현실세계에서 제품을 만들때 부품을 만들어서 이 부품들을 조립하여 완성품을 만들듯이 소프트웨어를 개발할때에도 부품에 해당되는 객체들을 먼저 만들고 이것들을 조립하여 만드는 것을 객체 지향 프로그래밍이라고 이해하고 있다.

2. 객체 지향의 4가지 특징

2.1 캡슐화

캡슐화란 객체의 데이터(필드), 동작(메소드)를 하나로 묶고 (캡슐형태) 실제 구현 내용을 외부에 감추는 것을 말한다.
외부 객체는 객체 내부의 구조를 알지 못하고 객체가 노출해서 제공하는 필드와 메소드만 이용할 수 있다.
이 것을 하는 이유는 외부의 잘못된 사용으로 객체가 손상되지 않도록 하는데 이유가 있다.

2.2 추상화

공통의 속성이나 기능을 묶어 이름을 붙이는 것이다.
클래스들의 중요하고 공통된 성질들을 추출해서 모으는 것이라고 이해하면 될 것 같다.
예를들어 개 고양이라는 클래스가 있을 때 동물이라는 하나의 카테고리로 추상화하여 공통 기능 예를들어 운다 등을 묶는 것을 추상화라고 생각한다.

2.3 상속

객체 지향프로그래밍에는 부모 역할의 상위 객체와 자식 역할의 하위객체가 있다. 부모 객체가 자기가 가지고 있는 필드와 메소드를 자식 객체에게 물려주어 자식객체가 사용할 수 있도록 한다.
이는 코드의 재사용성을 높여주고 유지보수 시간을 최소화한다는 장점이 있다.

2.4 다형성

다형성은 사용 방법은 동일하지만 실행 결과가 다양하게 나오는 성질을 말한다.
자동차의 부품을 교환하면 성능이 다르게 나오듯이 프로그램을 구성하는 객체(부품)을 바꾸면 프로그램의 실행 성능이 다르게 나올 수 있다.
다형성을 지원하기 위해 오버로딩과 오버라이딩을 지원하고 있다.
오버로딩은 메소드나 생성자에 있어서 같은 이름이지만 매개변수를 다르게 하여 상황마다 다르게 사용될 수 있도록 하는 것이다.
오버라이딩은 자식클래스나 구현클래스에서 상속받은 메소드 내용을 다르게 변경해서 사용하는 것이다. 필요한 연산 결과를 추가함으로써 다른 효과를 만들 수 있다.

3. 객체지향의 5가지 원칙(SOLID)

3.1 단일책임의 원칙(SRP : Single Responsibility Principle)

한 클래스는 하나의 책임만 가져야한다.
여기서 책임이라는 의미는 하나의 기능만 담당한다고 이해하면 될 것 같다.
하나의 클래스에 여러가지 기능이 있다며 기능 변경이 일어낫을때 수정해야할 코드가 많아진다.
한 책임 변경으로 다른 책임의 변경으로의 연쇄작용을 막기 위한 것이다.

책임의 범위는 딱 정해져있는 것이 아니고 어떤 프로그램을 개발하느냐에 따라 개발자마다 생각 기준이 달라질 수 있다고 한다. 따라서 단일 책임 원칙에 100%해답은 없다.

3.2 개방 폐쇄 원칙(OCP : Open/Closed Principle)

확장에는 열려있어야하며 수정에는 닫혀있어야한다를 의미한다.
기능 추가 요청이 오면 클래스 확장을 통해 손쉽게 구현하고 확장에 따른 클래스 수정은 최소화하도로고 설계하는 것이다.
추상화를 이용해서 관계를 구축하는 것을 생각하면 좋을 것 같다.
상속과 구현클래스를 생각하면 될 것 같다.

3.3 리스코프 치환 원칙(LSP Liskov Substitution Principle)

LSP원칙은 서브 타입은 언제나 기반(부모)타입으로 교체할 수 있어야 한다는 원칙이다.
다형성 원리를 이용하기 위한 원칙이다.
상위 클래스 타입으로 객체를 선언하여 하위 클래스의 인스턴스를 받으면 부모의 메소드를 사용해도 동작이 의도대로 흘러가야하는 것을 의미한다.
따라서 기본적으로 부모 메소드의 오버라이딩을 조심스럽게 따져가며 해야한다.
부모클래스와 동일한 선행조건을 기대하고 있는 프로그램 코드에서 예상하지 못한 문제를 일으킬 수 있기 때문이다.

3.4 인터페이스 분리 원칙(ISP : Interface Segregation Principle)

인터페이스를 각각 사용에 맞게 잘 분리해야한다.
단일책임원칙이 클래스를 분리하는 것이라면 ISP는 인터페이스를 분리하는 것이라고 이해하면 될 것 같다.
클라이언트의 목적과 용도에 적합한 인터페이스만을 제공하는 것을 목표로한다.
한번 인터페이스를 분리해서 구성해두고 나중에 무언가 수정사항이 생겨 또 인터페이스를 분리하는 행위를 가하지 말아야한다.

3.5 의존 역전 원칙(DIP : Dependency Inversion Principle)

어떤 클래스를 참조해서 사용해야한다면 그 클래스를 직접 참조하는 것이아니라 대상의 상위 요소(추상클래스 OR 인터페이스)로 참조하라는 원칙이다.
쉽게 이야기해서 구현 클래스를 직접 의존하지 않고 인터페이스에 의존하라는 것이다.
구현클래스나 자식클래스는 변화할 수 있기 때문에 자주 변화하는 것 보다는 변화하기 어려운 것을 의존하라는 것이다.
이 원칙은 각 클래스간의 결합을 낮출 수 있다.
스프링이 이 원칙을 잘 사용하고 있다는 생각이 든다.