OOP(Object-Oriented Programming, 객체 지향 프로그래밍) 이란?

OOP(객체 지향 프로그래밍)란?

객체 지향 프로그래밍(Object-Oriented Programming, OOP)은 C언어와 같은 절차 지향 프로그래밍 방식과는 다릅니다.

• 현실 세계의 객체처럼 데이터(속성)와 기능(동작)을 하나의 덩어리(객체)로 묶어 관리하는 프로그래밍 방식입니다.
• 클래스라는 설계도를 통해 객체(인스턴스)를 생성합니다.
• 생성된 객체들이 서로 상호작용(메소드 호출)하며 프로그램을 구성합니다.

객체란 무엇일까요?

객체(Object)는 우리 주변의 모든 사물이나 개념이 될 수 있습니다.

• 예시: TV, 컴퓨터, 책, 건물, 의자, 사람 등.
• 모든 객체는 자신만의 고유한 특성(속성)과 행동(동작)을 가집니다.
• 다른 객체들과 정보를 주고받거나 행동을 요청하며 상호작용합니다.

객체는 크게 속성(필드, Field)과 동작(메소드, Method)으로 구성됩니다.

• 예시) 학생 객체
  • 속성 (필드): 이름, 학년, 학번 등
  • 동작 (메소드): 공부하다, 밥 먹다, 놀다 등

---

객체 지향 프로그래밍 vs. 절차 지향 프로그래밍

프로그래밍 방식에는 크게 객체 지향과 절차 지향이 있어요. 두 방식의 특징을 비교하여 살펴볼게요.

구분	객체 지향 프로그래밍	절차 지향 프로그래밍
처리 방식	문제를 여러 개의 객체로 나누어 처리	문제를 여러 개의 함수로 나누어 처리
장점	코드 재사용이 용이, 유지보수가 쉬움, 대형 프로젝트에 적합	처리 속도가 빠름, 실행 속도가 빠름
단점	처리 속도가 상대적으로 느림, 객체가 많으면 용량 증가, 설계에 시간과 노력 필요	유지보수가 어려움, 대규모 프로젝트에 부적합
예시 언어	Java, Python, C# 등	C언어

사진 출처: 단미라이프 - 객체지향 프로그래밍

---

객체 지향의 핵심 4가지 특징

이 특징들은 객체 지향 언어의 강점을 보여주는 요소들이랍니다.

1. 캡슐화 (Encapsulation)

• 정의: 관련된 데이터(필드)와 기능(메소드)을 하나의 단위로 묶고, 실제 구현 내용을 외부에 감추는 기법입니다.
• 목적: 정보 은닉을 통해 중요한 데이터가 외부에서 직접 변경되는 것을 막고, 데이터의 무결성을 유지합니다.
• 특징: 외부에서는 공개된 메소드를 통해서만 객체에 접근할 수 있습니다.

2. 상속 (Inheritance)

• 정의: 상위 클래스(부모 클래스)의 모든 특성(속성과 동작)을 하위 클래스(자식 클래스)가 이어받는 기법입니다.
• 목적: 이미 작성된 코드를 재사용하여 코드 중복을 줄이고 효율적인 개발을 가능하게 합니다.
• 효과: 개발 및 유지보수 비용을 절감하는 데 중요한 역할을 합니다.

3. 추상화 (Abstraction)

• 정의: 객체에서 공통된 속성과 행위를 추출하여 표현하는 기법입니다.
• 목적: 실제 존재하는 복잡한 객체들을 프로그램으로 만들기 위해 공통적인 특성을 파악하고 불필요한 특성을 제거하여 핵심만 간추리는 과정입니다.
• 효과: 시스템의 복잡성을 낮추고 유연성을 높입니다.

4. 다형성 (Polymorphism)

• 정의: 같은 이름의 메소드를 호출하더라도 객체의 종류에 따라 다르게 동작하는 것을 의미합니다.
• 유형 1) 오버라이딩 (Overriding): 상위 클래스의 동작을 하위 클래스에서 재정의하는 것입니다.
• 유형 2) 오버로딩 (Overloading): 하나의 클래스 내에서 이름은 같지만 매개변수나 동작 방식이 다른 메소드를 여러 개 만드는 것입니다.

---

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

SOLID 원칙은 로버트 C. 마틴이 제시한 객체 지향 설계 원칙으로, 유지보수 및 확장성이 좋은 소프트웨어를 개발하는 데 도움이 되는 5가지 가이드라인입니다.

1. 단일 책임 원칙 (SRP - Single Responsibility Principle)

   • 하나의 클래스는 단 하나의 변경 이유만 가져야 합니다. 즉, 하나의 책임만 가지도록 설계합니다.

2. 개방-폐쇄 원칙 (OCP - Open/Closed Principle)

   • 소프트웨어 요소는 확장에는 열려 있어야 하지만, 변경에는 닫혀 있어야 합니다. 기존 코드를 수정하지 않고도 기능을 확장할 수 있도록 설계합니다.

3. 리스코프 치환 원칙 (LSP - Liskov Substitution Principle)

   • 서브타입은 언제나 기반 타입(부모 클래스)으로 대체될 수 있어야 합니다. 부모 클래스가 들어갈 자리에 자식 클래스를 넣어도 프로그램이 문제없이 동작해야 합니다.

4. 인터페이스 분리 원칙 (ISP - Interface Segregation Principle)

   • 클라이언트가 사용하지 않는 인터페이스에 의존하도록 강요해서는 안 됩니다. 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫습니다.

5. 의존 관계 역전 원칙 (DIP - Dependency Inversion Principle)

   • 상위 모듈은 하위 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 추상화는 세부 사항에 의존해서는 안 되며, 세부 사항은 추상화에 의존해야 합니다.

참고: 망나니개발자 - 실무코드로 살펴보는 SOLID 원칙

추가로 SOLID 원칙에 대한 자세한 설명이 나와있어서 참고하기 좋은 블로그이다.