🥔 객체 지향 프로그래밍의 3요소 5원칙

📚 객체 지향 프로그래밍의 3요소

1. 캡슐화 (Encapsulation)

데이터(속성)와 이를 다루는 기능(메서드)을 하나의 단위(객체 또는 클래스)로 묶고, 외부에서는 내부의 구체적인 구현을 숨기는 것.

• 왜 필요한가?
  • 데이터 보호: 객체 내부의 데이터가 외부에서 직접 변경되지 않도록 함.
  • 인터페이스 제공: 외부에는 필요한 기능만 노출하여 사용법을 단순하게 만듦.

class Counter {
	// #count는 private 필드로, 클래스 외부에서 직접 접근할 수 없어서 내부 데이터 보호(캡슐화)됨.
	// '#'를 붙이면 외부에서 직접 접근할 수 없도록 함. (ES2021부터 지원)
	#counter = 0;
	
  // public 메서드: 클래스 외부에서 호출 가능한 함수들
  // 외부에 제공하는 "인터페이스" 역할을 함.
  
  // count 값을 1 증가시키는 메서드
  increment() {
    this.#count++;
  }

  // count 값을 반환하는 메서드
  getCount() {
    return this.#count;
  }
}

const counter = new Counter(); // Counter 클래스의 객체(인스턴스) 생성
counter.increment; // 객체의 public 메서드 호출 → 내부의 #count 값이 1 증가
console.log(counter.getCount()); // 객체의 public 메서드를 통해 내부 값 조회 → 출력: 1

2. 상속 (Inheritance)

기존 클래스(부모 클래스, 슈퍼클래스)의 특성과 기능을 새 클래스(자식 클래스, 서브클래스)가 물려받아 재사용 및 확장하는 것.

• 왜 필요한가?
  • 코드 재사용: 공통된 기능을 부모에 작성하여 여러 자식 클래스에서 공유.
  • 계층 구조 표현: “A는 B이다.” 라는 관계를 자연스럽게 모델링.

class Animal {
  constructor(name) {
    this.name = name;
  }
  
  speak() {
    console.log(`${this.name}이(가) 소리냅니다.`);
  }
}

class Dog extends Animal {
  speak() {
    console.log(`${this.name}이(가) 멍멍 짖습니다.`);
  }
}

const dog = new Dog("바둑이");
dog.speak(); // "바둑이이(가) 멍멍 짖습니다."

3. 다형성 (Polymorphism)

같은 메시지(메서드 호출)에 대해 여러 객체가 각자의 방식으로 반응할 수 있는 능력. 주로 메서드 오버라이딩(재정의)을 통해 구현됨.

• 왜 필요한가?
  • 코드의 유연성: 부모 클래스 타입으로 여러 자식 인스턴스를 다룰 수 있음.
  • 인터페이스 통일: 동일한 메서드 이름으로 다양한 구현을 제공하여 일관성 있는 코드 작성.

class Shape {
  draw() {
    console.log("도형을 그립니다.");
  }
}

class Circle extends Shape {
  draw() {
    console.log("원을 그립니다.");
  }
}

class Rectangle extends Shape {
  draw() {
    console.log("사각형을 그립니다.");
  }
}

const shapes = [new Circle(), new Rectangle()];
shapes.forEach(shape => shape.draw());
// 출력:
// "원을 그립니다."
// "사각형을 그립니다."

---

📚 SOLID 5원칙 (객체 지향 설계 원칙)

SOLID는 좋은 객체 지향 설계를 위한 다섯 가지 원칙을 말한다.

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

😼 한 클래스는 한 가지 책임(또는 기능)만 가져야 한다.

• 왜 필요한가?
  • 코드 유지보수 용이: 하나의 클래스가 한 가지 역할만 하므로 변경 시 영향이 최소화됨.

// 안 좋은 예: 한 클래스가 데이터 처리와 로깅을 모두 함
class UserManager {
  createUser(user) {
    // 사용자 생성 로직
  }
  log(message) {
    // 로그 기록 로직
  }
}

// 좋은 예: 역할을 분리
class UserManager {
  createUser(user) {
    // 사용자 생성 로직
  }
}

class Logger {
  log(message) {
    // 로그 기록 로직
  }
}

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

😼 소프트웨어 구성 요소(클래스, 모듈 등)는 확장에는 열려있고, 수정에는 닫혀 있어야 한다.

• 왜 필요한가?
  • 안정성 유지: 기존에 잘 동작하던 코드에 손을 대지 않으므로, 새로운 기능을 추가할 때 기존 코드에서 버그가 생길 위험이 줄어든다.
  • 유연한 확장: 새로운 기능을 추가할 때, 기존의 코드를 건드리지 않고 새로운 클래스를 만들어 기능을 확장할 수 있다.

// 1. 기본 할인 계산기 (기본 동작: 할인 없음)
class DiscountCalculator {
  calculate(price) {
    // 할인 없음 → 원래 가격 반환
    return price;
  }
}

// 2. 퍼센트(%) 할인 정책: DiscountCalculator를 확장하여 새로운 기능 추가
class PercentageDiscount extends DiscountCalculator {
  constructor(percentage) {
    super(); // 부모 클래스의 생성자 호출
    this.percentage = percentage; // 할인율 (예: 10% → 10)
  }
  
  // 기존 calculate 메서드를 오버라이딩(재정의)
  calculate(price) {
    // 원래 가격에서 percentage만큼 할인한 가격 계산
    return price - (price * this.percentage / 100);
  }
}

// 3. 고정 금액 할인 정책: 역시 DiscountCalculator를 확장
class FixedDiscount extends DiscountCalculator {
  constructor(amount) {
    super();
    this.amount = amount; // 할인 금액 (예: 15원 할인)
  }
  
  calculate(price) {
    // 원래 가격에서 고정 금액 만큼 할인
    return price - this.amount;
  }
}

// 4. 할인 적용 함수: 할인 정책(DiscountCalculator)을 인자로 받아 계산
function applyDiscount(price, discountCalculator) {
  return discountCalculator.calculate(price);
}

// 사용 예제:
const price = 100;
const noDiscount = new DiscountCalculator();         // 할인 없음
const percentageDiscount = new PercentageDiscount(10); // 10% 할인
const fixedDiscount = new FixedDiscount(15);           // 15원 할인

console.log(applyDiscount(price, noDiscount));         // 100 출력
console.log(applyDiscount(price, percentageDiscount));   // 90 출력 (100 - 10%)
console.log(applyDiscount(price, fixedDiscount));        // 85 출력 (100 - 15)

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

😼 부모 클래스의 객체를 자식 클래스의 객체로 대체해도 프로그램의 정상적인 동작이 유지되어야 한다.

• 왜 필요한가?
  • 다형성과 상속의 신뢰성을 보장하여, 코드 재사용과 확장이 용이해짐.

class Bird {
  fly() {
    console.log("날개로 날다");
  }
}

class Eagle extends Bird {
  // Eagle은 Bird를 상속받아 fly()를 그대로 사용
}

function letBirdFly(bird) {
  bird.fly();
}

const eagle = new Eagle();
letBirdFly(eagle); // 정상적으로 "날개로 날다" 출력
// 만약 자식 클래스가 부모의 기능을 깨뜨린다면 LSP 위반!

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

😼 클라이언트는 사용하지 않는 인터페이스에 의존하지 않아야 하므로, 특정 클라이언트에 맞게 인터페이스를 분리해야 한다.

• 왜 필요한가?
  • 불필요한 메서드 구현 강요를 피하고, 클라이언트가 필요한 기능만 사용하도록 함.

// 안 좋은 예: 하나의 객체에 너무 많은 역할을 부여
class MultiFunctionPrinter {
  print() { /* ... */ }
  scan() { /* ... */ }
  fax() { /* ... */ }
}

// 좋은 예: 역할에 따라 인터페이스(기능)를 분리
class Printer {
  print() { /* ... */ }
}

class Scanner {
  scan() { /* ... */ }
}

5. 의존 역전 원칙 (Dependency Inversion Principle, DIP)

😼 고수준 모듈(비즈니스 로직)은 저수준 모듈(세부 구현)에 의존하지 않고, 둘 다 추상화(인터페이스)에 의존해야 한다.

• 왜 필요한가?
  • 유연성 향상: 고수준 모듈이 구체적인 저수준 구현에 의존하지 않으면, 저수준 모듈을 변경하거나 교체할 때 고수준 모듈을 수정할 필요가 없다.
  • 재사용성 증가: 추상화에 의존하면 다양한 구체 클래스(저수준 모듈)를 쉽게 교체할 수 있다. 예를 들어, 로깅 방법을 변경할 때 고수준 코드(예: 사용자 서비스)는 변경 없이 새로운 로거만 주입하면 됨.

// 1. 추상화 역할을 하는 Logger "인터페이스"
// 실제로는 추상 클래스처럼 동작한다고 생각하면 돼.
class Logger {
  log(message) {
    // 실제 구현은 하위 클래스에서 제공해야 함.
    throw new Error("log() 메서드는 구현되어야 합니다.");
  }
}

// 2. 저수준 모듈: 콘솔에 로그를 출력하는 구체적인 Logger 구현
class ConsoleLogger extends Logger {
  log(message) {
    console.log("ConsoleLogger:", message);
  }
}

// 3. 고수준 모듈: 사용자 관련 로직을 담당하는 UserService
// 이 클래스는 구체적인 로거(ConsoleLogger)에 의존하지 않고, Logger라는 추상화에 의존함.
class UserService {
  // 생성자에서 Logger(추상화)를 주입받음.
  constructor(logger) {
    // logger는 반드시 Logger 타입(또는 Logger를 구현한 객체)이어야 함.
    this.logger = logger;
  }
  
  createUser(user) {
    // 사용자 생성 로직 (예: 데이터베이스 저장 등)
    // ...
    // 생성된 후 로그 기록
    this.logger.log(`사용자 ${user} 생성됨`);
  }
}

// 4. 사용 예제
// 여기서 ConsoleLogger를 생성하고, UserService에 주입(의존성 주입)함.
const logger = new ConsoleLogger();
const userService = new UserService(logger);

// UserService는 내부에서 어떤 구체 로거를 사용하는지 몰라도, 단지 logger.log()라는 추상화된 인터페이스만 사용함.
userService.createUser("Alice");  // 출력: "ConsoleLogger: 사용자 Alice 생성됨"

항목	설명	예시 코드 부분
추상화 (인터페이스)	고수준 모듈과 저수준 모듈 모두가 의존하는 계약. 구체 구현 없이 기능의 틀만 정의	class Logger { log(message) { ... } }
저수준 모듈	구체적인 구현을 담당하는 클래스. 추상화에 따라 구현됨	class ConsoleLogger extends Logger { ... }
고수준 모듈	핵심 비즈니스 로직을 수행하며, 추상화에만 의존하는 클래스	class UserService { constructor(logger) { ... } }

추상화(Abstraction)는 복잡한 시스템이나 객체에서 필요한 핵심 기능만 노출하고, 세부 구현은 감추는 개념이다.
추상화의 목적: 사용자(개발자)가 복잡한 내부 동작을 신경 쓰지 않고, 간단한 인터페이스(사용법)만 보고 사용할 수 있게 만드는 것.
예시: 자동차를 운전할 때, 운전자는 엔진 내부의 복잡한 작동 원리를 몰라도 키를 돌리면 차가 출발하는 것과 같다. 여기서 “시동 걸기“가 추상화된 인터페이스고, 내부 엔진 메커니즘은 감춰진 세부 사항이다.

나: 추상화랑 캡슐화랑 뭐가 달라 그러면

GPT:

구분	추상화 (Abstraction)	캡슐화 (Encapsulation)
목적	필요한 기능만 노출하여 사용자가 복잡한 내부 구현을 몰라도 되게 함.	데이터와 메서드를 하나로 묶고, 내부 상태를 숨김으로써 보호함.
관점	사용자 입장: “어떻게 사용해야 하는가?” (인터페이스 제공)	구현자 입장: “내부 데이터를 안전하게 관리하고, 변경을 제한”
예시	자동차의 시동 버튼 (엔진 내부 작동 원리는 숨김)	은행 계좌: 잔액은 은행 시스템에 감추고, 입출금은 정해진 인터페이스만 사용

• 추상화는 “어떤 기능(인터페이스)을 제공할 것인가“에 집중하는 개념
• 캡슐화는 “어떻게 내부 데이터를 보호하고, 외부에 접근을 제한할 것인가“에 초점을 둔 개념

📚 요약

원칙	의미 및 목적	자바스크립트 예시
단일 책임 원칙 (SRP)	한 클래스는 하나의 책임만 가져야 함	UserManager와 Logger를 분리
개방-폐쇄 원칙 (OCP)	기존 코드를 수정하지 않고 기능 확장이 가능해야 함	Discount 클래스를 확장하여 새로운 할인 정책 추가
리스코프 치환 원칙 (LSP)	자식 클래스는 부모 클래스 대신 사용되어도 문제 없어야 함	Bird 클래스와 Eagle, letBirdFly 함수 사용
인터페이스 분리 원칙 (ISP)	클라이언트는 불필요한 메서드에 의존하지 않도록 인터페이스를 분리해야 함	MultiFunctionPrinter 대신 Printer, Scanner 분리
의존 역전 원칙 (DIP)	고수준 모듈은 저수준 모듈에 의존하지 않고, 추상화에 의존해야 함	UserService가 Logger 추상화에 의존