🟠 객체 지향 프로그래밍(Object-Oriented Programming)
컴퓨터 프로그래밍의 패러다임 중 하나이다.
컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 독립된 단위인 '객체'들의 모임으로 파악한다.
각 객체는 메시지를 주고 받고 데이터를 처리할 수 있다.
🟠 특징
SW 개발과 보수를 간편하게 한다.
대규모 SW개발에 많이 사용된다.
프로그래밍 학습이 더 쉬워진다.
코드 분석을 보다 직관적으로 할 수 있다.
🟠 단점
설계 및 개발 속도가 느리다.
지나친 프로그램의 객체화 경향은 실제 세계의 모습을 그대로 반영하지 못한다.
🟠 구성요소
- 클래스
같은 종류(또는 문제 해결을 위한)의 집단에 속하는 속성(attribute)과 행위(behavior)를 정의한 것.
OOP의 기본적인 사용자 정의 데이터형(user defined data type).
한 클래스는 다른 클래스 또는 외부 요소와 독립적으로 디자인된다.
- 객체
클래스의 인스턴스로 실제 메모리상에 할당된다.
객체는 자신의 고유한 속성(attribute)을 가지며 클래스에서 정의한 행위(behavior)를 수행한다.
객체는 클래스에 정의된 행위에 대한 정의를 공유함으로써 메모리를 경제적으로 사용한다.
- 메서드, 메시지
클래스로부터 생성된 객체를 사용하는 방법.
객체에 명령을 내리는 메시지.
한 객체의 서브루틴(subroutine)형태로 객체의 속성을 조작하는데 메서드 사용메시지를 통해 객체간의 통신이 이루어진다.
🟠 OOP 4가지 특징
-
추상화
불필요한 정보는 숨기고 중요한 정보만을 표현함으로써 프로그램을 간단히 만든다.
추상 자료형 : 추상화를 통해 정의된 자료형.
추상 자료형은 자료형의 자료 표현과 자료형의 연산을 캡슐화한 것으로 접근 제어를 통해 자료형의 정보를 숨길 수 있다.
OOP에서 일반적으로 추상 자료형을 클래스, 추상 자료형의 인스턴스를 객체, 추상 자료형에서 정의된 연산을 메서드, 메서드의 호출을 생성자라 한다.
-
상속
새로운 클래스가 기존 클래스의 자료와 연산을 이용할 수 있게 하는 기능.
상속을 통해 기존 클래스를 상속받은 하위 클래스를 이용해 프로그램의 요구에 맞추어 클래스를 수정할 수 있다.
클래스 간의 종속 관계를 형성함으로써 객체를 조직화할 수 있다.
-
다형성
어떤 한 요소에 여러 개념을 넣어 놓는 것.
일반적으로 오버라이딩(overriding) 이나 오버로딩(overloading)을 의미한다.
오버라이딩 : 같은 이름의 메서드가 여러 클래스에서 다른 기능을 하는 것
오버로딩 : 같은 이름의 메서드가 인자의 개수나 자료형에 따라 다른 기능을 하는 것
다형 개념을 통해 프로그램 안의 객체 간 관계를 조직적으로 나타낼 수 있다.
- 캡슐화
🟠 OOP의 5대 원칙 - SOLID
SOLID 원칙을 적용하면 시스템에 새로운 요구사항이나 변경이 발생했을 때, 유연하게 대처하고 기존 코드의 변경을 최소화 할 수 있다.
SOLID의 개념들은 자바의 객체 지향 파트에서 학습하는 추상화, 상속, 인터페이스, 다형성 등의 개념을 재정립한 것과 같다.
5가지 원칙들은 서로 독립된 개별적 개념이 아니라 연관되어 있다.
-
단일 책임 원칙(SRP, Single Responsibility Principle)
하나의 클래스는 단 하나의 책임(기능)만 가져야 한다.
하나의 클래스가 여러 책임을 가지게 되면 유지보수성이 떨어지고 코드가 복잡해지며, 확장성이 떨어진다.
이러한 문제가 발생하지 않도록 단일 책임 원칙을 따르도록 설계하는 것이 좋다.
책임의 범위는 프로그램과 개발자에 따라 기준이 다르므로 적절한 범위를 설정해야 한다.
-
개방 폐쇄 원칙(OCP, Open Closed Principle)
새롭게 추가된 클래스는 상위 인터페이스의 추상메서드만 구현하면 되고(확장에 열려있음)
유저 입장에서는 어떤 변경이 일어나더라도 기존의 기능들이 수행되어야 한다(변경에 닫혀있음).
다시 말해, 코드를 수정하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙이다.'운전면허'라는 인터페이스가 '시동을 건다', '액셀을 밟는다' 등의 추상 메서드를 가지고 있다면
어떤 자동차 클래스가 추가되더라도 해당 메서드를 구현을 통해 차를 운전할 수 있는 것과 같다.
→ 차 종류의 확장에는 열려있되 어떤 차로 변경되더라도 이용에 문제가 없는 것은 변경에 닫혀있다는 것-
리스코프 치환 원칙(LSP, Liskov Substitution Principle)
하위에 존재하는 클래스는 상위 클래스의 역할을 할 수 있어야 한다.
-
인터페이스 분리 원칙(ISP, Interface Segregation Principle)
큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시켜서, 하위 클래스가 꼭 필요한 메서드만 사용할 수 있어야 한다.
분리 원칙을 통해 시스템의 의존성을 낮춘다.
단일책임원칙(SRP)과 인터페이스 분리 원칙(ISP)은 같은 문제를 다른 방향으로 해결한 것이다.
프로젝트 환경에 맞게 적절하게 사용해야 한다.
- 의존 역전 원칙(Dependency Inversion Principle)
상위 계층이 하위 계층에 의존하는 전통적인 의존 관계를 반전 시킨다 → 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다.- 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다.
- 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다.
🐌 참고
