1. 객체지향 프로그래밍(OOP, Object-Oriented Programming)
- 현실 세계를 모델링 > 객체(Object)라는 단위로 프로그램을 구성하는 방식
- 객체들의 집합으로 프로그램의 상호작용을 표현 > 데이터를 객체로 취급 > 객체 내부에 선언된 메서드를 활용하는 방식
- 즉, 현실 세계처럼 객체 단위로 데이터와 동작을 묶어서, 확장성과 유지보수가 좋은 소프트웨어를 만들기 위한 프로그래밍 방식
2. 객체 ?
> 현실 세계에는 사람, 자동자, 강아지 처럼 구체적인 존재( =객체)가 있고, 각각 속성( =데이터)과 행동( =기능)을 가진다
> ex) 강아지 객체
- 속성: 이름, 나이, 품종
- 행동: 짖는다, 먹는다, 뛴다
3. 객체지향 프로그래밍의 특징
1. 캡슐화(Encapsulation)
> 데이터와 메서드를 하나로 묶고, 외부에서 필요한 것만 노출
> ex) private 변수 + public 메서드
2. 상속성(Inheritance)
> 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용, 추가, 확장
3. 추상화(Abstraction)
> 불필요한 세부 사항은 감추고, 중요한 부분만 보여줌
> ex) 인터페이스, 추상 클래스
4. 다형성(Polymorphism)
> 하나의 메서드나 클래스가 다른 방식으로 동작함 > 오버로딩, 오버라이딩
> ex) speak() >> 사람은 말하고, 개는 짖음
5. 오버로딩(Overloading) vs 오버라이딩(Overriding)
5-1. 오버로딩(Overloading)
> 같은 이름의 메서드를 여러 개 정의함
> 편리함을 위한 기술이다(기능은 비슷하지만 입력값이 다를 때 사용)
> 정적 다형성
> 즉, 같은 이름의 메서드를 매개변수만 다르게 해서 여러 버전으로 제공함
5-2. 오버로딩의 예시(Java)
public class Calculator {
int add(int a, int b) {
return a + b;
}
// 오버로딩
double add(double a, double b) { // 자료형을 double로 바꿈
return a + b;
}
// 오버로딩
int add(int a, int b, int c) { // 개수를 추가함
return a + b + c;
}
}*메서드 시그니처(Method Signature): 메서드를 구분하는 식별자
즉, 메서드 이름 + 매개변수들의 타입/순서/개수 조합
- 메서드 이름은 add로 다 똑같다
- 매개변수의 타입, 개수가 달라서 오버로딩이 가능하다 !
- 컴파일러가 *메서드 시그니처를 보고 자동 구분한다.
5-3. 오버라이딩(Overriding)
> 부모 클래스로부터 상속받은 메서드를 자식 클래스가 재정의 하는 것
> 주로 메서드 오버라이딩(Method Overriding)을 의미함
> 동적 다형성
> 즉, 부모의 동작을 자식이 새로 정의함
5-4. 오버라이딩의 예시(Java)
class Animal {
void sound() {
System.out.println("으르르 월 월 !!!");
}
}
//오버라이딩
class Dog extends Animal {
@Override
void sound() {
System.out.println("멍멍멍~!!!");
}
}
Animal a = new Dog();
a.sound(); // "멍멍멍~!!!" 출력 == 자식 클래스에서 재정의한 값*런타임 다형성(runtime polymorphism): 프로그램 실행 중(런타임)에 어떤 객체의 메서드를 호출할지 결정되는 것
즉, 부모 타입으로 선언된 객체가 실제로는 어떤 자식 객체인지에 따라 다르게 동작하는 것
- 부모의 sound() 메서드를 자식 클래스인 Dog가 재정의
- 실행 시점에 어떤 클래스인지 판단해서 호출됨 > *런타임 다형성(동적 다형성)
6. 객체지향 프로그래밍의 설계원칙
SOLID 원칙
S: 단일 책임 원칙(SRP)
O: 개방-폐쇄 원칙(OCP)
L: 리스코프 치환 원칙(LSP)
I: 인터페이스 분리 원칙(ISP)
D: 의존 역전 원칙(DIP)
6-1. 단일 책임 원칙(SRP, Single Responsibility Principle)
> 하나의 클래스는 하나의 책임만 가져야 한다
> ex) A라는 로직이 있으면 어떠한 클래스는 A에 관한 클래스여야 하고, 이를 수정할 때도 A와 관련된 수정이어야함
6-2. 개방-폐쇄 원칙(OCP, Open-Close Principle)
> 유지 보수 사항이 생기면 코드를 쉽게 확장할 수 있어야 하고, 수정할 때는 닫혀 있어야 함
> 즉, 기존의 코드는 잘 변경하지 않으면서 확장은 쉽게 할 수 있어야 함
6-3. 리스코프 치환 원칙(LSP, Liskov Substitution Principle)
> 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서, 하위 타입의 인스턴스로 바꿀 수 있어야 함
> 자식 클래스는 언제나 부모 클래스 대신 사용될 수 있어야 함
> 즉, 부모 클래스의 기능을 자식이 정상적으로 대체할 수 있어야 함
> ex) A객체가 B객체의 자식 계층일 때, A객체는 B객체와 바꿔도 문제 없어야 함 !!
6-4. 인터페이스 분리 원칙(ISP, Interface Segregation Principle)
> 하나의 큰 인터페이스보다, 구체적인 여러 개의 인터페이스를 만드는게 낫다
6-5. 의존 역전 원칙(DIP, Dependency Inversion Principle)
> 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어서 변하기 쉬운 것의 변화에 영향X
> 즉, 상위 모듈은 하위 모듈에 의존하면 안되고, 둘 다 추상화에 의존해야 함
> ex) 타이어를 갈아끼울 수 있는 틀을 만들고 다양한 타이어를 교체할 수 있어야함 > 상위 계층은 하위 계층의 변화에 대한 구현으로부터 독립해야 함 !
7. SOLID 원칙 정리
단일 책임 원칙(SRP) - 하나의 클래스는 하나의 책임만 가져야 한다.
개방-폐쇄 원칙(OCP) - 확장엔 열려 있고, 변경엔 닫혀 있어야 한다.
리스코프 치환 원칙(LSP) - 자식은 부모를 대체할 수 있어야 한다.
인터페이스 분리 원칙(ISP) - 인터페이스는 작게 쪼개야 한다.
의존 역전 원칙(DIP) - 구현이 아니라 추상화에 의존해야 한다.
8. 객체지향 프로그래밍의 장단점
장점
1. 코드 재사용성: 상속을 이용해 공통된 기능은 부모 클래스에, 다른 기능은 자식 클래스에 > 중복 줄이고, 코드재활용 가능
2. 유지보수 용이: 캡슐화를 이용해 객체 내부 구현을 숨기고(private), 외부에 필요한 기능만 제공(public)
3. 협업에 적합함: 클래스 단위로 업무 분리가 가능해 객체 단위로 개발 가능
4. 확장성 good: 다형성을 이용해 같은 메서드명이라도 상황에 따라 다르게 동작이 가능하게 할 수 있음
단점
1. 초기 설계가 어려움: 클래스 구조나 관계를 처음에 잘못 잡으면 전체 구조가 무너짐..
2. 코드 양이 많아질 수도?: 간단한 작업도 클래스를 만들고 객체를 만들어야 하니까 복잡하고 길어질 수 있음
3. 실행 성능이 떨어질 수도?: 동적 바인딩 등으로 인해 함수형 프로그래밍보다 느릴 수 있음
4. 지나친 추상화는 오히려 해로움: 너무 많은 상속 구조나 인터페이스를 쓰면 오히려 이해하기 어려운 코드가 될 수도..
9. 결론
객체지향 프로그래밍은 데이터와 기능을 객체 단위로 묶어서 추상화, 캡슐화, 상속, 다형성을 활용해
유지보수성과 재사용성이 높은 소프트웨어를 만드는 프로그래밍 패러다임이다.
객체지향 프로그래밍은 SOLID 원칙을 준수하여 설계해야 한다.
'Computer Science > Programming Paradigm' 카테고리의 다른 글
| 절차형 프로그래밍(Procedural Programming) (0) | 2025.03.27 |
|---|---|
| 선언형과 함수형 프로그래밍(Declarative, Functional Programming) (0) | 2025.03.25 |