객체 지향 프로그래밍
Object Oriented Programming
"데이터를 객체로 정의하고, 객체 간의 상호작용을 통해 프로그램을 만드는 방법"
객체 (Object)
데이터의 추상화; 상태(State)와 행위(Behave)를 가지는 것
현실 세계가 돌아가는 원리로 부터 영감
→ 객체 간의 상호작용을 통해 프로그램 로직을 구성
절차적 프로그래밍 vs 객체 지향 프로그래밍
절차적 프로그래밍 (Procedural Programming)
"순서가 정해진, 틀에 박힌 작업(routine, procedure)의 연속으로 프로그램을 만드는 방법"
-
장점
컴퓨터의 처리 순서와 유사해 실행 속도가 빠름
-
단점
유지 보수의 어려움 (특히, 프로젝트의 스케일이 커지면 스파게티 코드가 됨)
코드의 실행 순서가 결과에 영향을 미침
디버깅 어려움
PP와 OOP의 차이점
프로그램의 구현에 있어서 무엇을 초점에 두고 구현하는가?
PP
→ 데이터의 변화를 중심으로 함수를 구현
OOP
→ 기능을 중심으로 메소드를 구현
OOP 등장 계기
시간이 지남에 따라 하드웨어의 발전 속도가 소프트웨어의 발전 속도를 따라잡지 못하게 됨
객체 지향 프로그래밍은 기능별로 묶어서 모듈화 및 재사용 → 하드웨어의 중복 연산을 방지하여 성능 개선
OOP 특징
1. 캡슐화 (Encapsulation)
"관련된 데이터와 코드를 한 곳에 묶어서 분류하는 것"
변수와 함수가 코드 전체에 걸쳐 분산되면, 코드를 재활용(유지 보수 및 확장)하는 것이 어려움
→ 캡슐화를 통해서 데이터와 기능의 재활용 증가
정보 은닉
"데이터를 캡슐의 내부로 감추고, 메소드를 통해서만 외부 세계와 상호작용"
(Python의 경우, 클래스를 통한 캡슐화로 OOP가 가능하지만 정보 은닉은 제공하지 않음)
(Java의 경우, private과 같은 키워드를 통해 클래스 내의 정보 은닉이 가능)
→ 즉, 캡슐화가 무조건 정보 은닉을 보장하는 것은 아니지만, 정보 은닉의 장점을 가질 수도 있다는 것이 포인트
2. 상속 (Inheritance)
"이미 정의된 어떤 클래스(캡슐화)의 특성을 물려받는 것"
기존 속성 및 기능을 변경하거나, 추가하여 새로운 클래스로 정의
→ 상속은 캡슐화를 유지하면서, 기존 클래스의 재사용을 도와줌
3. 다형성 (Polymorphism)
"같은 자료 형에 여러가지 객체를 대입하여 다양한 결과를 얻어내는 성질"
→ 어떤 역할(인터페이스, 슈퍼 클래스)에 대해 다양한 구현(클래스 및 객체)이 존재하는 것
e.g.,
Hamburger burgerA = new BigMac();
Hamburger burgerB = new Whopper();Overriding & Overloading
다형성 실현을 도와주는 기술
-
Overriding
기존에 정의된 메소드를 재정의 하는 것
-
Overloading
같은 이름이지만 입력 매개 변수의 타입과 개수를 다르게 설정해서 함수를 호출하는 것
추상화 (Abstraction)
"필요한 특성(속성과 메소드)을 일반화, 단순화 시키는 작업"
흔히, 설계 상으로 동작할 메소드를 미리 인터페이스로 만들거나, 추상 클래스를 선언하는데 사용
추상화가 왜 필요한가?
역할(Role)과 구현(Implementation) 사이의 분리를 위해
객체들 간의 어떤 의존 관계를 구성할 때,
의존 되는 객체(Server) 측에서 변경이 있어도 의존 하는 객체(Client) 측의 코드에는 변경이 없도록 하기 위함
즉, 클라이언트는 서버의 구현(클래스 또는 객체)에 의존하는 것이 아니고, 역할(인터페이스)에 의존하도록 관계를 설정하면 인터페이스의 구현이 바뀌어도 클라이언트 측에서 별도의 변경이 필요 없거나 최소화 시킬 수 있음
OOP 장점
-
코드의 재사용
-
PP보다 쉬운 구조와 간편한 코딩
-
유지보수, 확장의 쉬움
-
데이터 모델링을 할때 객체와 데이터의 맵핑이 수월함
→ 요구사항을 보다 명확하게 파악 가능
OOP 단점
-
PP보다 느린 처리 속도
-
설계에 필요한 소요 시간이 큼
-
객체가 변수를 통해 상태를 가짐
→ 예측할 수 없는 상태가 되면 애플리케이션의 버그를 초래할 수 있음 (함수형 프로그래밍 각광의 계기)
객체 지향적 설계 원칙 (SOLID)
-
SRP (Single Responsible Principle / 단일 책임 원칙)
클래스는 하나의 책임(목적, 역할)을 가짐
변경이 있을 때, 파급 효과(side effect)가 적다면 SRP를 잘 따른 것
-
OCP (Open-Closed Principle / 개방-폐쇠 원칙)
컴포넌트는 확장에 열려 있고, 변경에는 닫혀 있을 것
→ 다형성과 인터페이스를 사용
-
LSP (Liskov Subsitution Principle / 리스코브 치환 원칙)
상위 타입 객체를 하위 타입으로 치환할 때, 상위 타입을 요구하는 프로그램의 정확성을 위배하지 않을 것
→ 다형성을 지원하기 위한 원칙으로, 인터페이스의 구현체(클래스)들은 이 원칙을 지킬 필요가 있음
-
ISP (Interface Segregation Principle / 인터페이스 분리 원칙)
인터페이스는 사용자를 기준으로 상세하게 분리할 것
-
DIP (Dependency Inversion Principle / 의존성 역전의 원칙)
고수준 모듈은 저수준 모듈에 의존하지 말 것
→ 클라이언트는 추상화된 개념에 의존하도록 관계를 설계해야 한다
