H.Dev Log

[OOP] GoF(Gang of Four) 디자인 패턴 장점 과 종류 !!

hlxecz — Mon, 26 Jan 2026 19:03:55 +0900

SOLID 랑 이것 저것 찾아보다가 디자인 패턴은 어떤 것 들이 있을까 해서 찾아봤습니다..

공부 할게 너무너무 많은 것 일단 종류만 먼저 정리해 볼게요 !!

디자인 패턴(Design Pattern)이란?

개발 중 발생하는 반복적인 문제들에 대한 해결책으로, 많은 개발자가 인정한 모범 사례(Best Practice)입니다. 객체 지향 4대 특성과 SOLID 원칙을 기반으로 합니다.

디자인 패턴의 장점

재사용성: 검증된 솔루션을 재사용하여 반복적인 문제 해결
가독성: 명확한 구조로 코드를 이해하기 쉬움
유지보수성: 모듈화가 용이하여 변경 시 해당 부분만 수정 가능
확장성: 기존 코드를 건드리지 않고 새로운 기능 통합 용이
안정성: 수많은 검증을 거친 신뢰할 수 있는 방식

디자인 패턴

객체 지향과 디자인 패턴의 비유

프로그래밍 개념	요리 비유	설명
객체 지향 4대 원칙	요리 도구	캡슐화, 상속, 추상화, 다형성
설계 원칙 (SOLID)	도구 사용법	도구를 올바르게 다루는 방법
디자인 패턴	레시피	표준화된 문제 해결 방법

GoF의 23가지 디자인 패턴

1. 생성 패턴 (Creational Pattern)

객체 생성에 관련된 패턴으로, 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공합니다.

Singleton (싱글톤)	하나의 인스턴스만 생성되도록 보장하고, 어디서든 접근 가능하게 함
Factory Method (팩토리 메서드)	객체 생성을 서브 클래스로 미루어 어떤 클래스의 인스턴스를 생성할지 결정
Abstract Factory (추상 팩토리)	관련된 객체들의 집합을 생성하는 인터페이스를 제공하여 구체적인 생성을 추상화
Builder (빌더)	복잡한 객체의 생성 과정을 단순화하여 단계적으로 생성 및 조립
Prototype (프로토타입)	기존 객체를 복제(Clone)하여 새로운 객체를 생성

2. 구조 패턴 (Structural Pattern)

클래스나 객체를 조합해 더 큰 구조를 만드는 패턴입니다.

Adapter (어댑터)	호환되지 않는 인터페이스를 가진 클래스들을 함께 사용할 수 있도록 래퍼(Wrapper) 제공
Bridge (브릿지)	추상화와 구현을 분리하여 각각 독립적으로 확장 가능하게 함
Composite (컴포지트)	개별 객체와 복합 객체를 동일하게 다루며 트리 구조를 구성
Decorator (데코레이터)	객체에 동적으로 새로운 기능을 추가하여 확장
Facade (퍼사드)	복잡한 서브시스템을 쉽게 사용할 수 있도록 단순한 통합 인터페이스 제공
Flyweight (플라이웨이트)	대량의 작은 객체들을 공유하여 메모리 사용 최적화
Proxy (프록시)	다른 객체에 대한 대리자를 제공하여 접근 제어, 지연 로딩 등을 수행

3. 행위 패턴 (Behavioral Pattern)

객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴입니다.

Observer (옵저버)	상태 변경 시 의존하는 다른 객체들에게 자동으로 알림
Strategy (전략)	알고리즘을 정의하고 캡슐화하여 실행 중에 교체 가능하게 함
Command (커맨드)	요청을 객체로 캡슐화하여 큐 저장, 로깅, 실행 취소 등을 지원
State (상태)	객체의 내부 상태에 따라 스스로 행동을 변경하도록 함
Chain of Responsibility (책임 연쇄)	요청을 처리하는 객체들을 체인으로 연결하여 처리할 때까지 넘김
Visitor (방문자)	객체 구조를 변경하지 않고 새로운 연산을 수행할 수 있게 함
Interpreter (인터프리터)	언어의 문법을 정의하고 해석기를 제공하여 문제 해결
Memento (메멘토)	객체의 내부 상태를 저장해 두었다가 나중에 복원
Mediator (중재자)	객체 간의 복잡한 통신을 캡슐화하여 결합도를 낮춤
Template Method (템플릿 메서드)	알고리즘의 골격은 상위 클래스에, 구체적 단계는 하위 클래스에 구현
Iterator (이터레이터)	내부 구조를 노출하지 않고 컬렉션의 요소에 순차적으로 접근

갑자기 또 궁금해진 GoF 저만,, 영어 약자 나오면 궁금해지는거 아니겠죠 아래에다가 정리해볼게요 !

디자인 패턴의 기원: GoF(Gang of Four)

우리가 학습하는 디자인 패턴의 표준은 1994년 출간된 책 《Design Patterns: Elements of Reusable Object-Oriented Software》에서 정립되었습니다.

이 책은 소프트웨어 설계의 공통된 문제에 대한 해법과 작명법을 제안하였으며, 공동 저자인 에리히 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vlissides) 네 명을 가리켜 이 분야의 '4인방(Gang of Four, GoF)'이라 부릅니다.

책의 전반부는 패턴의 정의를, 후반부는 실용적인 23가지 패턴을 다룸
예제 코드는 객체지향 언어인 C++과 스몰토크(Smalltalk)로 작성됨
한국어판은 피어슨 에듀케이션 코리아를 통해 출판됨

참고 및 출처: IT is True:티스토리

[OOP] 객체 지향 설계의 5가지 원칙 - S.O.L.I.D

hlxecz — Mon, 26 Jan 2026 18:39:08 +0900

Design Pattern:SOILD
Problem Source: GitHub - Sw_Pilot_Java (Chapter 4 / Step 4)

SOLID 원칙이란?

객체지향 설계 5대 원칙으로, 유지보수성과 확장성을 높이고 코드의 복잡도를 줄이기 위한 핵심 설계 지침입니다.

SOLID 원칙은 특정 언어나 프레임워크에 종속되지 않는, "변화에 유연하고 유지보수하기 쉬운 코드"를 만들기 위한 기본 철학입니다.

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

"한 클래스는 하나의 책임(기능)만 가져야 한다."

하나의 클래스에 여러 책임이 섞여 있으면, 한 기능의 변경이 다른 기능에 연쇄적인 영향을 줄 수 있습니다. 책임을 명확히 분리하면 변경의 파급효과를 줄이고 유지보수성이 높아집니다.

Tip:
청소기는 청소만 잘하면 됩니다. 화분에 물 주고 드라이 기능까지 넣으면 하나만 고장 나도 전체를 못 쓰게 되죠. 하나의 클래스는 한 가지 책임만 지게 하세요!

✅ 간단한 예시

// 보고서 생성 책임
public class ReportGenerator {
    public String generate() {
        return "Report 내용";
    }
}

// 보고서 출력 책임 (분리됨)
public class ReportPrinter {
    public void print(String report) {
        System.out.println(report);
    }
}

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

"클래스는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다."

기능이 변경되거나 추가될 때, 기존 코드를 뜯어고치지 않고 새로운 기능을 추가할 수 있도록 설계해야 합니다. 주로 추상화(인터페이스/상속)를 통해 이를 달성합니다.

Tip:
역할(인터페이스)과 구현(클래스)을 분리하세요. 기존 코드는 건드리지 말고, 새로운 클래스를 추가(상속/구현)하는 방식으로 기능을 확장하세요.

✅ 간단한 예시

interface Payment {
    void pay();
}

// 새로운 결제 수단이 추가되어도 Payment 인터페이스만 구현하면 됨
class CardPayment implements Payment {
    public void pay() {
        System.out.println("카드 결제 진행");
    }
}

class OrderService {
    private Payment payment;
    
    // 생성자 주입을 통해 유연하게 변경 가능
    public OrderService(Payment payment) {
        this.payment = payment;
    }
    
    public void checkout() {
        payment.pay(); // 기존 코드는 수정할 필요 없음
    }
}

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

"자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 한다."

다형성을 활용할 때, 부모 클래스 타입으로 선언된 변수에 자식 객체를 대입해도 프로그램이 원래 의도대로 동작해야 한다는 원칙입니다. 즉, 자식 클래스는 부모의 규약을 철저히 지켜야 합니다.

Tip:
자바의 Collection 프레임워크가 대표적인 예입니다. LinkedList에서 HashSet으로 구현체를 바꿔도 .add() 동작은 논리적으로 문제없이 작동해야 합니다.

✅ 간단한 예시

// 부모 타입 Collection
Collection<String> myData = new LinkedList<>();
myData.add("apple");

// 자식 클래스를 HashSet으로 교체해도 add() 동작은 보장됨 -> LSP 만족
myData = new HashSet<>();
myData.add("banana");

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

"인터페이스는 작게 나눠서, 구현체가 필요한 기능만 구현하게 하자."

범용적인 큰 인터페이스 하나보다는, 구체적인 여러 개의 인터페이스가 낫습니다. 구현하는 클래스가 자신이 사용하지 않는 기능까지 억지로 구현하지 않도록 해야 합니다.

Tip:
인터페이스는 다중 상속(구현)이 가능합니다. 기능별로 잘게 쪼개서 필요한 것만 골라 구현하도록 설계하세요.

✅ 간단한 예시

// 기능별로 인터페이스 분리
interface Printer {
    void print();
}

interface Fax {
    void fax();
}

// 팩스 기능이 없는 프린터는 Printer만 구현하면 됨 (불필요한 fax() 구현 강제 X)
class BasicPrinter implements Printer {
    public void print() {
        System.out.println("프린트 출력 중");
    }
}

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

"구현 클래스에 의존하지 말고, 추상화(인터페이스)에 의존해야 한다."

변하기 쉬운 것(구현체)보다는 변하지 않는 것(인터페이스, 추상 클래스)에 의존해야 유지보수가 쉬워집니다. 이를 위해 보통 의존성 주입(DI)을 활용합니다.

Tip:
"저장한다"는 역할(인터페이스)에 의존해야지, "MySQL에 저장한다"는 구체적인 사실에 의존하면 나중에 오라클로 DB를 바꿀 때 코드를 다 뜯어고쳐야 합니다.

✅ 간단한 예시

// 추상화에 의존
interface Database {
    void save(String data);
}

class MySQLDatabase implements Database {
    public void save(String data) {
        System.out.println("MySQL에 저장: " + data);
    }
}

class DataService {
    private Database db; // 구체적인 MySQLDatabase가 아닌 인터페이스에 의존
    
    public DataService(Database db) {
        this.db = db;
    }
    
    public void store(String input) {
        db.save(input);
    }
}

마무리 요약

원칙	설명
SRP	하나의 클래스는 하나의 책임만 가져야 한다.
OCP	확장에는 열려 있고, 수정에는 닫혀 있어야 한다.
LSP	자식 클래스는 부모 클래스를 대체해도 문제없어야 한다.
ISP	필요한 기능만 가진 인터페이스로 분리해야 한다.
DIP	구현체가 아닌, 추상화(인터페이스)에 의존해야 한다.

Reference & Source

[Inpa Dev ‍ ] solid

SRP

ISP

[JAVA] 인터페이스 vs 추상클래스 차이점 정리

hlxecz — Wed, 7 Jan 2026 15:10:26 +0900

1. 한눈에 보는 비교 (Interface vs abstract)

인터페이스와 추상 클래스, 막상 비교하려면 헷갈리는 두 개념의 문법적 차이를 표로 정리했습니다.

구분	추상 클래스	인터페이스
사용 키워드	`abstract`	`interface`
사용 가능 변수	제한 없음	static final (상수)
접근 제어자	제한 없음 (public, private, protected, default)	`public`
사용 가능 메서드	제한 없음	abstract, default, static, private
상속 키워드	`extends`	`implements`
다중 상속 여부	불가능	가능 클래스에 다중구현, 인터페이스 끼리 다중 상속
공통점	1. 추상 메서드를 가지고 있어야 한다. 2. 인스턴스화 할 수 없다. (`new` 생성자 사용 불가) 3. 구현체(자식 클래스)의 인스턴스를 사용해야 한다. 4. 상속/구현 받은 클래스는 추상 메서드를 반드시 구현(Override) 해야 한다.

2. 인터페이스 (Interface)

인터페이스는 구현 객체가 "같은 동작을 한다"는 것을 보장하기 위한 설계도입니다.

상속 관계에 얽매이지 않고 자유롭게 기능을 장착할 수 있습니다.

핵심 특징

추상화의 극치: 모든 메서드는 기본적으로 public abstract입니다. (Java 8부터 default/static 메서드 가능)
상수만 허용: 일반 변수는 가질 수 없으며, 모든 필드는 public static final 상수입니다.
다중 구현 가능: 클래스는 여러 인터페이스를 동시에 구현(implements)할 수 있어 유연합니다.
행위 중심 (Can-do): "무엇을 할 수 있는가"에 초점을 둡니다. 보통 ~able로 네이밍합니다. (예: Runnable, Serializable)

간단 예시

// '날 수 있는' 기능 정의
interface Flyable {
    void fly(); // public abstract 생략 가능
}

// '수영할 수 있는' 기능 정의
interface Swimmable {
    void swim();
}

// 오리는 날 수도 있고, 수영할 수도 있음 (다중 구현)
class Duck implements Flyable, Swimmable {
    @Override
    public void fly() { System.out.println("오리가 날아갑니다."); }
    
    @Override
    public void swim() { System.out.println("오리가 수영합니다."); }
}

3. 추상 클래스 (Abstract Class)

추상 클래스는 하위 클래스들의 "공통점을 모아둔 미완성 클래스"입니다. 클래스 간의 명확한 계층 구조를 만들 때 사용합니다.

핵심 특징

단일 상속: 일반 클래스와 마찬가지로 하나만 상속(extends)받을 수 있습니다.
일반 멤버 보유: 추상 메서드 외에도 생성자, 일반 변수(필드), 일반 메서드를 가질 수 있습니다.
코드 중복 제거: 공통된 필드와 기능을 부모 클래스에 정의하여 자식 클래스의 코드 중복을 줄입니다.
족보 중심 (Is-a): "무엇인가"에 초점을 둡니다. 서로 연관된 클래스들의 뼈대 역할을 합니다.

간단 예시

// 동물이라는 공통 분모 (미완성 설계도)
abstract class Animal {
    String name; // 상태(변수)를 가질 수 있음

    // 공통 기능 (일반 메서드)
    void eat() { System.out.println("밥을 먹습니다."); }

    // 자식마다 다른 기능 (추상 메서드)
    abstract void sound(); 
}

class Dog extends Animal {
    @Override
    void sound() { System.out.println("멍멍!"); }
}

class Cat extends Animal {
    @Override
    void sound() { System.out.println("야옹!"); }
}

5. 그래서 언제, 무엇을 써야 할까?

이론적인 차이점은 알겠지만, 막상 코드를 짤 때 "지금 뭘 써야 하지?" 고민될 때가 많습니다. 상황별 선택 가이드를 제시합니다.

️ 추상 클래스 (Abstract Class)

"IS-A" 관계일 때: "강아지는 동물이다", "자동차는 탈것이다"처럼 명확한 계층 구조가 필요할 때.
코드 중복을 줄일 때: 여러 자식 클래스에서 공통으로 사용하는 변수(필드)나 메서드(구현부)가 많을 때.
접근 제어자가 중요할 때: public 이외에 protected나 private 멤버가 필요할 때.

️ 인터페이스 (Interface)

"CAN-DO" 관계일 때: "날 수 있다(Flyable)", "저장할 수 있다(Saveable)"처럼 기능을 장착해주고 싶을 때.
서로 다른 조상을 가질 때: 상속 계보와 상관없이 공통 기능을 부여하고 싶을 때. (예: Bird와 Airplane은 다르지만 둘 다 Flyable)
다중 구현이 필요할 때: 하나의 클래스가 여러 가지 역할을 수행해야 할 때.

6. 실전 패턴: 인터페이스와 추상 클래스의 조합 (Mixin)

사실 실무에서는 이 둘을 함께 사용하는 경우가 많습니다. 인터페이스의 "유연함(다중 상속)"과 추상 클래스의 "편리함(중복 제거)"을 모두 챙기는 강력한 설계 패턴입니다.

예시: 게임 캐릭터 만들기 (Game Character)

게임의 모든 캐릭터는 공격(Attack)하고 이동(Move)할 수 있어야 합니다. (인터페이스 역할)
하지만, 모든 캐릭터는 체력(HP)과 레벨(Level)이라는 공통 속성을 가집니다. (추상 클래스 역할)

Step 1. 인터페이스로 설계도(기능) 정의

interface Attackable {
    void attack(); // 모든 캐릭터는 공격해야 함 (강제성)
}

interface Movable {
    void move(); // 모든 캐릭터는 움직여야 함
}

Step 2. 추상 클래스로 공통 멤버(뼈대) 구현

인터페이스에는 변수(상태)를 담을 수 없으니, 추상 클래스를 중간에 둬서 공통 변수를 관리합니다.

// 인터페이스를 구현(implements)하면서, 공통 기능은 미리 만들어두는 추상 클래스
abstract class GameCharacter implements Attackable, Movable {
    // 1. 공통 필드 (중복 제거)
    protected int hp;
    protected int level;

    // 2. 공통 메서드 (중복 제거)
    public void levelUp() {
        this.level++;
        System.out.println("레벨 업! 현재 레벨: " + this.level);
    }
    
    // attack()과 move()는 자식마다 다르므로 추상 메서드로 남겨둠 (구현 강제)
}

Step 3. 실제 클래스 구현 (단순화)

이제 실제 캐릭터 클래스들은 hp, level 변수를 일일이 선언할 필요 없이, 핵심 로직에만 집중하면 됩니다.

class Warrior extends GameCharacter {
    @Override
    public void attack() {
        System.out.println("칼로 공격합니다!");
    }
    @Override
    public void move() {
        System.out.println("뛰어서 이동합니다.");
    }
}

class Wizard extends GameCharacter {
    @Override
    public void attack() {
        System.out.println("마법 불꽃 발사!");
    }
    @Override
    public void move() {
        System.out.println("텔레포트로 이동합니다.");
    }
}

7. 결론: 다형성(Polymorphism)의 중요성

우리가 인터페이스와 추상 클래스를 조합해서 복잡하게 설계한 진짜 이유는 바로 "다형성을 200% 활용하기 위해서"입니다.

이제 우리는 전사(Warrior)든 마법사(Wizard)든 상관없이, 모두 GameCharacter라는 하나의 타입으로 묶어서 관리할 수 있습니다.

다형성 활용 코드 예시

public class GameMain {
    public static void main(String[] args) {
        // 1. 다형성: 서로 다른 객체를 '부모 타입'으로 묶음
        List<GameCharacter> party = new ArrayList<>();
        party.add(new Warrior());
        party.add(new Wizard());

        // 2. 일괄 처리: 구체적인 타입(전사인지 마법사인지)을 몰라도 됨
        for (GameCharacter character : party) {
            character.move();   // 공통 기능 (추상 클래스에서 상속)
            character.attack(); // 개별 기능 (오버라이딩된 메서드 실행)
            // 전사는 "칼 공격", 마법사는 "마법 공격"이 자동으로 나감!
        }
    }
}

이 패턴(Interface + Abstract)의 장점 요약

- 설계의 표준화 (Interface): "모든 캐릭터는 반드시 공격해야 한다"는 규칙을 강제하여, 개발자가 실수로 기능을 누락하는 것을 방지합니다.
- 코드 중복 제거 (Abstract Class): 체력(HP), 레벨(Level) 처럼 모든 캐릭터가 갖는 공통 코드를 부모 클래스 한곳에서만 관리하면 되므로 유지보수가 매우 쉬워집니다.
- 확장성 (Polymorphism): 나중에 Archer(궁수) 클래스가 추가되어도, 기존의 GameMain 코드는 한 줄도 수정할 필요가 없습니다. 그냥 리스트에 추가만 하면 됩니다. (OCP 원칙 준수)

자바의 꽃은 객체지향이고, 객체지향의 완성은 다형성입니다.
인터페이스로 "큰 그림(설계)"을 그리고, 추상 클래스로 "공통 분모(구현)"를 묶어주는 이 패턴을 익혀두면, 좋을 것 같습니다.

Reference & Source

이 포스팅은 "요즘 공부 도와주는 갓 인파"님의 블로그 내용을 바탕으로 정리했습니다.
더 깊이 있는 내용과 예제는 아래 원문에서 확인하실 수 있습니다.

[Inpa Dev ‍ ] 자바 인터페이스 vs 추상클래스 차이점 완벽 이해하기

[JAVA] Stack 구현 & Stack Class의 문제점 (feat. Deque)

hlxecz — Fri, 19 Dec 2025 18:33:26 +0900

Java Collection: Stack & Deque
Problem Source: GitHub - Sw_Pilot_Java (Chapter 2 / Step 2 - 3)

LIFO 구조인 스택의 개념과 사용법, 그리고 현대적인 대체제인 Deque를 알아봅니다.

스택(Stack)은 '쌓다', '더미'라는 뜻을 가지고 있습니다. 식당에 쌓여 있는 접시 더미나, 총기의 탄창을 떠올리면 이해하기 쉽습니다.

가장 마지막에 들어간 데이터가 가장 먼저 나오는 LIFO(Last In First Out, 후입선출) 구조를 가지고 있으며, 이는 먼저 들어간 데이터가 먼저 나오는 Queue(FIFO)와 정반대되는 개념입니다.

1. 스택(Stack)의 구조와 특징

LIFO 구조: 나중에 넣은(Push) 데이터가 먼저 나옵니다(Pop).
활용 예시: 웹 브라우저 뒤로 가기, 편집기 실행 취소(Undo/Redo), 수식의 괄호 검사, JVM의 Stack 메모리 영역 등.
Java 특징: java.util.Stack 클래스는 Vector 클래스를 상속받아 구현되었으므로 Thread-Safe하다는 특징이 있습니다.

2. Stack 클래스 주요 메서드

자바에서 스택을 다룰 때 주로 사용하는 메서드들입니다.

메서드	설명	반환값
push(item)	스택의 맨 위에 객체를 저장합니다.	저장된 객체
pop()	맨 위의 객체를 꺼내서 반환합니다. (제거됨)	꺼낸 객체
peek()	맨 위의 객체를 확인만 합니다. (제거 안 됨)	맨 위 객체
empty()	스택이 비어있는지 확인합니다.	boolean
search(o)	객체의 위치를 반환합니다. (1부터 시작)	인덱스 (없으면 -1)

3. 실전 사용 예제

기본적인 Push와 Pop

데이터를 넣고(push) 꺼내는(pop) 가장 기초적인 동작입니다. 꺼내면 데이터는 스택에서 사라집니다.

Stack<Integer> stack = new Stack<>();

// 1. 요소 추가 (Push)
stack.push(1);
stack.push(2);
stack.push(3);
System.out.println(stack); // [1, 2, 3]

// 2. 요소 꺼내기 (Pop - LIFO)
System.out.println(stack.pop()); // 3 (가장 마지막에 넣은 것)
System.out.println(stack.pop()); // 2
System.out.println(stack); // [1] (꺼낸 값은 사라짐)

최상단 값 확인하기 (Peek)

peek()은 데이터를 꺼내지 않고 "다음에 나올 값이 뭔지 확인만" 하고 싶을 때 사용합니다. 데이터가 제거되지 않습니다.

Stack<String> stack = new Stack<>();
stack.push("Apple");
stack.push("Banana");
stack.push("Cherry");

// 맨 위 값 확인 (제거 X)
System.out.println("Top Element: " + stack.peek()); // Cherry
System.out.println("Stack Size: " + stack.size());  // 3 (사이즈 유지됨)

// 값을 꺼냄 (제거 O)
System.out.println("Pop Element: " + stack.pop());  // Cherry
System.out.println("Stack Size: " + stack.size());  // 2

위치 검색 (search) 주의사항

search() 메서드는 배열의 인덱스(0부터 시작)와 다르게, 맨 위에서부터 몇 번째에 있는지(1부터 시작)를 반환합니다.

Stack<String> stack = new Stack<>();
stack.push("HI");
stack.push("HELLO");
stack.push("EARTH");

// "EARTH"는 맨 위에 있으므로 1 반환
System.out.println(stack.search("EARTH")); // 1 

// "HI"는 세 번째로 꺼내지므로 3 반환
System.out.println(stack.search("HI"));    // 3

4. Stack 클래스는 Deprecated 되었습니다!

결론부터 말하자면, 실무에서 java.util.Stack 클래스는 사용을 지양해야 합니다.

Stack 클래스는 Vector 클래스를 상속하도록 설계 되어 있음

⚠️ 이유 1: Vector 상속의 문제점
Stack은 Vector를 상속받았습니다. Vector는 중간에 데이터를 삽입할 수 있는 add(index, val) 메서드를 가지고 있는데, 이를 Stack도 그대로 물려받았습니다.
"맨 위에서만 넣고 빼야 한다"는 스택의 원칙이 깨질 위험이 있습니다.

Stack<String> stack = new Stack<>();
stack.push("One");
stack.push("Two");

// 스택의 원칙 위배! (중간에 강제 삽입 가능)
stack.add(0, "Bug"); 

// pop() 결과가 예상과 달라질 수 있음
System.out.println(stack.pop()); // "Two" (Bug가 아님)

또한, Vector의 모든 메서드가 synchronized 처리되어 있어, 싱글 스레드 환경에서도 불필요한 성능 저하가 발생합니다.

5. 권장되는 해결책: Deque (ArrayDeque)

Java 공식 문서에서도 Stack 대신 Deque(덱) 인터페이스의 구현체인 ArrayDeque를 사용할 것을 권장합니다.

JAVA 공식 문서

Deque는 양쪽 끝에서 데이터를 넣고 뺄 수 있어, 스택(LIFO)과 큐(FIFO)의 기능을 모두 완벽하게 수행할 수 있습니다.

Stack 처럼 사용하기 (LIFO)

push()와 pop() 메서드를 사용하면 스택과 동일하게 동작합니다.

/* Stack 처럼 사용하기 */
Deque<String> stack = new ArrayDeque<>();

// 담기 (Push)
stack.push("a");
stack.push("b");
stack.push("c");
stack.push("d");
stack.push("e");

System.out.println(stack); // [e, d, c, b, a] (Last In First Out)

// 꺼내기 (Pop)
System.out.println(stack.pop()); // e
System.out.println(stack.pop()); // d
System.out.println(stack); // [c, b, a]

Queue 처럼 사용하기 (FIFO)

offer()와 poll() 메서드를 사용하면 큐와 동일하게 동작합니다.

/* Queue 처럼 사용하기 */
Deque<String> queue = new ArrayDeque<>();

// 담기 (Offer)
queue.offer("a");
queue.offer("b");
queue.offer("c");
queue.offer("d");
queue.offer("e");

System.out.println(queue); // [a, b, c, d, e] (First In First Out)

// 꺼내기 (Poll)
System.out.println(queue.poll()); // a
System.out.println(queue.poll()); // b
System.out.println(queue); // [c, d, e]

1. Stack은 LIFO(후입선출) 구조이다.
2. 기존 java.util.Stack은 낡은 Vector를 상속받아 설계 결함이 있다.
3. 따라서 스택이 필요할 때는 Deque<T> stack = new ArrayDeque<>();를 쓰자!

References & Sources

[JAVA] Collection Framework & Collections Class _ Part 1

hlxecz — Tue, 16 Dec 2025 14:23:27 +0900

️

Java Concept: Collection Framework & Collections Class _ Part 1

자바의 자료구조(Collection) 전체 구조와 인터페이스 종류에 대해 정리해 보겠습니다

자바를 공부하다 보면 Collection과 Collections라는 비슷하게 생긴 두 단어를 마주하게 됩니다. 's' 하나 차이인데 역할은 완전히 다릅니다.

Collection 는 데이터를 담는 그릇(Framework)이고, Collections 는 그 그릇을 요리하는 도구(Utility)입니다.

오늘은 자바의 자료구조 전체 지도인 컬렉션 프레임워크를 먼저 훑어보고, 다음 장에 이를 효율적으로 다루기 위한 Collections 클래스의 기능들을 정리해 보겠습니다.

1. 자바 컬렉션 프레임워크 (Collection Framework)

컬렉션 프레임워크란 "다수의 데이터를 쉽고 효과적으로 처리할 수 있는 표준화된 클래스의 집합"을 의미합니다.

즉, 자료구조(Data Structure)와 알고리즘을 자바 클래스로 구현해 놓은 것입니다.

https://commons.wikimedia.org

▲ Java Collections Framework 계층 구조

Collection Framework 주요 인터페이스 특징

인터페이스	특징	구현 클래스
List	순서가 있음, 중복 허용	ArrayList, LinkedList, Stack, Vector
Set	순서가 없음, 중복 불가	HashSet, TreeSet, LinkedHashSet
Map	Key-Value 쌍, Key 중복 불가, 순서 없음 (Collection 인터페이스 상속 아님)	HashMap, TreeMap, LinkedHashMap, Properties
Queue	선입선출(FIFO) 구조	LinkedList, PriorityQueue

2. List 인터페이스 (순서 O, 중복 O)

"줄 서기"와 같습니다. 데이터가 들어온 순서대로 저장되며, 똑같은 데이터가 또 들어와도 상관없습니다.

인덱스(방 번호)를 이용해 데이터를 관리합니다.

클래스	내부 구조	장점 (속도)	단점
ArrayList	동적 배열 (Object[])	조회(Get) 빠름	중간 삽입/삭제 느림
LinkedList	노드 연결 (Node<E>)	중간 삽입/삭제 빠름	조회(Get) 느림
Vector	동적 배열 + 동기화	멀티스레드 안전(Safe)	무겁고 느림 (Legacy)

- 상세 설명

ArrayList: 데이터를 순차적으로 추가/조회할 때 성능이 가장 좋습니다. 하지만 중간에 요소를 끼워 넣으려면 뒤에 있는 데이터들을 전부 한 칸씩 밀어야 해서 느립니다.
LinkedList: 앞뒤 요소의 주소만 알고 연결된 구조입니다. 중간에 데이터를 넣을 때 주소만 바꿔주면 되므로 빠릅니다. 하지만 5번째 데이터를 찾으려면 처음부터 하나씩 건너가야 해서 조회는 느립니다.
Vector: ArrayList의 옛날 버전입니다. synchronized가 걸려있어 성능이 떨어지므로, 동기화가 필요하면 Collections.synchronizedList()를 쓰는 게 낫습니다.

List<String> list = new ArrayList<>();
list.add("Java");
list.add("Java"); // 중복 가능
list.add(1, "Spring"); // 중간 삽입 (이 경우 LinkedList가 더 유리할 수 있음)

System.out.println(list); // [Java, Spring, Java]

3. Set 인터페이스 (순서 X, 중복 X)

"주머니"와 같습니다. 순서가 뒤죽박죽이며, 똑같은 구슬을 두 개 넣을 수 없습니다.

중복 제거가 필요할 때 핵심적으로 사용됩니다.

클래스	내부 구조	정렬/순서	특징
HashSet	Hash Table	순서 없음 (Random)	가장 빠름, 일반적인 Set
LinkedHashSet	Hash Table + LinkedList	입력 순서 보장	순서가 중요한 경우 사용
TreeSet	Red-Black Tree	오름차순 정렬	범위 검색, 정렬된 데이터 필요 시

- 상세 설명

HashSet: hashCode()와 equals()를 이용해 중복을 걸러냅니다. 순서를 보장하지 않으므로, "데이터가 들어있는지 확인(contains)"하는 용도로 가장 빠르고 좋습니다.
LinkedHashSet: HashSet에 순서 기억 기능을 추가한 것입니다. 데이터가 들어온 순서대로 출력하고 싶을 때 사용합니다.
TreeSet: 이진 탐색 트리 구조로 데이터를 저장하면서 자동으로 정렬(Sorting)합니다. HashSet보다는 느리지만, "가나다순 출력"이나 "특정 범위 검색"에 유리합니다.

Set<String> set = new HashSet<>();
set.add("Java");
set.add("Java"); // 중복 발생 -> 저장 안 됨 (false 반환)
set.add("Android");
set.add("Spring");

System.out.println(set); 
// 출력 결과 예시: [Spring, Java, Android] (순서 보장 안 됨)

4. Queue 인터페이스 (선입선출 대기열)

"놀이공원 줄 서기"와 같습니다. 먼저 들어온 데이터가 먼저 나가는 FIFO(First In First Out) 구조입니다. 순서가 있지만, 중간에 새치기(삽입)는 불가능합니다.

클래스	내부 구조	특징	활용
LinkedList	Node 연결	큐의 표준 구현체	일반적인 큐 작업
PriorityQueue	Heap (이진 트리)	우선순위 정렬	작업 스케줄링 (중요도 순)
ArrayDeque	가변 배열 (Circular)	양쪽 끝 접근 가능	스택/큐 대용 (성능 우수)

- 상세 설명

LinkedList: List 인터페이스도 구현하고 Queue 인터페이스도 구현했습니다. 큐로 사용할 때는 offer(넣기), poll(꺼내기) 메서드를 주로 사용합니다.
PriorityQueue: 들어온 순서와 상관없이 "우선순위가 높은 데이터"가 먼저 나갑니다. 기본적으로는 숫자가 낮은 것이 우선이며, 생성자에 기준을 설정할 수 있습니다.
ArrayDeque: 큐(Queue)와 스택(Stack)의 기능을 모두 합친 덱(Deque)의 구현체입니다. 성능이 매우 좋아 실무에서 Stack 대신 많이 쓰입니다.

Queue<String> queue = new LinkedList<>();
queue.offer("첫번째");
queue.offer("두번째");
queue.offer("세번째");

System.out.println(queue.poll()); // "첫번째" (가장 먼저 들어간 것)
System.out.println(queue); // ["두번째", "세번째"]

5. Map 인터페이스 (키와 값의 쌍)

Map은 엄밀히 말해 Collection 인터페이스의 자식은 아닙니다. 하지만 프레임워크의 중요한 한 축입니다. Key(키)와 Value(값)의 쌍으로 데이터를 관리합니다.

구현 클래스	Key 특징	정렬	Null 허용
HashMap	중복 불가	순서 없음	Key 1개, Value 다수 허용
LinkedHashMap	중복 불가	입력 순서 보장	허용
TreeMap	중복 불가	Key 기준 오름차순	Key Null 불가
Hashtable	중복 불가	순서 없음	Key/Value 둘 다 Null 불가

- 상세 설명

HashMap: 가장 널리 쓰입니다. Key의 중복은 허용하지 않고, Value의 중복은 허용합니다. 순서를 보장하지 않지만 검색 속도가 매우 빠릅니다.
TreeMap: Key를 기준으로 자동 정렬됩니다. 정렬된 순서대로 조회하거나 범위 검색이 필요할 때 사용합니다.
Hashtable: HashMap의 구버전(Legacy)입니다. 동기화(Synchronized)가 되어 있어 멀티스레드 환경에서 안전하지만 느립니다. 최근에는 ConcurrentHashMap을 더 권장합니다.

Map<String, Integer> map = new HashMap<>();
map.put("사과", 1000);
map.put("바나나", 2000);
map.put("사과", 1500); // Key 중복! -> 기존 값(1000)이 덮어씌워짐

System.out.println(map.get("사과")); // 1500

6. Collection Framework 핵심 요약

순서가 중요하고 중복 데이터도 저장해야 한다면?
List (ArrayList)
중복을 제거해야 하고, 존재 여부(Contains) 확인이 중요하다면?
Set (HashSet)
데이터를 순서대로(선입선출) 처리해야 한다면?
Queue (LinkedList)
ID, 사번처럼 고유한 키(Key)로 데이터를 빠르게 찾아야 한다면?
Map (HashMap)

Tip _ 인터페이스 기반 코딩

변수를 선언할 때는 구체적인 클래스(ArrayList)보다는 인터페이스(List)를 사용하는 습관을 들이는 것이 좋습니다.

❌ Bad: ArrayList<String> list = new ArrayList<>();
⭕ Good: List<String> list = new ArrayList<>();

이렇게 해야 나중에 new LinkedList<>()로 구현체를 바꿔도 나머지 코드를 수정할 필요가 없어집니다. (유연성 증가)

Collection Framework 에 대해 정리를 해보았고 !!

다음으로는 Collections 클래스 에 대해 어떤 메서드들과 기능들이 있는지 정리해 보겠습니다 ~!

[JAVA] Getter/Setter 이중성 & 문제점 Refactoring

hlxecz — Fri, 12 Dec 2025 19:37:43 +0900

☕

Java Study: Refactoring Getter/Setter

이 포스팅은 Getter/Setter의 남용을 막고, 객체지향적인 설계를 하는 방법을 정리한 글입니다.

자바를 처음 배울 때, 우리는 클래스를 만들고 습관적으로 모든 필드에 대해

Getter와 Setter를 생성하곤 합니다. IDE가 단축키 한 번이면 만들어주니 너무나 자연스럽죠.

하지만 "이게 정말 객체지향적인가?"라는 의문을 가져본 적 있으신가요?

단순히 값을 넣고 빼기만 한다면 그건 객체가 아니라 데이터 주머니에 불과할지도 모릅니다.

오늘은 무분별한 Getter/Setter 사용이 왜 문제인지, 그리고 이를 해결하기 위한 진짜 객체지향 설계 방법(Rich Domain Model, VO 등)에 대해 정리해보겠습니다.

1. Getter/Setter의 이중성과 문제점

빈약한 도메인 모델 (Anemic Domain Model)

우리는 '정보 은닉'을 위해 필드를 private으로 막습니다. 그런데 바로 public Getter/Setter를 열어버린다면? 사실상 정보 은닉은 깨진 것과 다름없습니다.

// ❌ 상태와 행위가 분리된 절차지향적 코드
public class Order {
    private int totalAmount;
    // 단순히 값만 꺼내주고 넣어주는 역할
    public int getTotalAmount() { return totalAmount; }
    public void setTotalAmount(int amount) { this.totalAmount = amount; }
}

// 서비스 로직 (객체의 데이터를 꺼내서 외부에서 처리함)
public void discount(Order order) {
    int amount = order.getTotalAmount();
    if (amount > 10000) {
        order.setTotalAmount(amount - 1000);
    }
}

이렇게 되면 객체는 자신의 데이터에 대한 통제권을 잃고, 단순히 데이터 보관소(주머니) 역할만 하게 됩니다.

이것을 빈약한 도메인 모델이라고 합니다.

2. 해결책 - 묻지 말고 시켜라 (Tell, Don't Ask)

객체지향의 핵심은 데이터와 그 데이터를 조작하는 행위(로직)를 한곳에 묶는 것입니다.

데이터를 달라고(Ask) 하지 말고, 원하는 작업을 하라고 시켜야(Tell) 합니다.

풍부한 도메인 모델 (Rich Domain Model)

// ✅ 스스로의 상태를 관리하는 객체
public class Order {
    private int totalAmount;

    // 객체가 스스로 판단하고 상태를 변경함
    public void applyDiscount() {
        if (this.totalAmount > 10000) {
            this.totalAmount -= 1000;
        }
    }
}

// 서비스 로직
public void process(Order order) {
    order.applyDiscount(); // "할인해!" 라고 명령만 하면 됨
}

이제 외부에서는 Order의 내부 구현을 몰라도 됩니다. 변경 사항이 생겨도 Order 객체 내부만 수정하면 되므로 유지보수성이 대폭 향상됩니다.

3. 더 나은 설계 1: Value Object (VO)

int, long 같은 원시 타입은 값이 무엇을 의미하는지, 유효한 값인지 스스로 증명하지 못합니다.

이를 해결하기 위해 값을 감싸는 객체(VO)를 사용합니다.

Value Object의 특징

불변성 (Immutable): 생성 후 값이 변하지 않음 (Setter 없음).
유효성 검증: 생성자에서 값의 유효성을 체크함 (예: 금액은 음수 불가).
동등성: 값이 같으면 같은 객체로 취급 (equals & hashCode 재정의).

public class Money {
    private final int amount; // 불변

    public Money(int amount) {
        if (amount < 0) {
            throw new IllegalArgumentException("돈은 음수가 될 수 없습니다.");
        }
        this.amount = amount;
    }

    public Money plus(Money other) {
        return new Money(this.amount + other.amount); // 새로운 객체 반환
    }
}

이제 int price = -1000; 같은 끔찍한 실수를 원천 차단할 수 있습니다.

4. 더 나은 설계 2: Aggregate Root와 캡슐화

객체들이 복잡하게 얽혀 있을 때, 외부에서 내부의 작은 객체들을 마음대로 조작하게 두면 안 됩니다.

Aggregate Root(대표 객체)를 통해서만 내부에 접근하도록 제약해야 합니다.

잘못된 설계 vs 올바른 설계

구분	방식	문제점/장점
Bad	`order.getItems().add(item);`	주문(Order) 몰래 아이템을 추가함. 총액 계산 누락 등 버그 발생 위험.
Good	`order.addItem(item);`	주문 객체가 아이템 추가와 동시에 총액 갱신 등 규칙을 수행함.

5. 결론: 객체를 객체답게 쓰는 법

Getter/Setter는 최소한으로: 무조건 만들지 말고, 꼭 필요한 경우(DTO, 조회용)에만 만들자.
상태 변경은 명확하게: setStatus("CANCEL") 대신 cancelOrder() 처럼 의도가 드러나는 메서드를 사용하자.
검증은 생성 시점에: 생성자에서 유효성을 검사하여, 태어날 때부터 온전한 객체(VO)만 존재하게 하자.

핵심 요약:
"값을 꺼내서(Get) 내가 계산하고 다시 넣지(Set) 말자."
"객체에게 계산하라고 시키고(Tell), 결과만 받아오자."
이것이 객체지향 프로그래밍의 시작입니다.

[JAVA] 접근제한자 & 캡슐화

hlxecz — Fri, 12 Dec 2025 18:21:33 +0900

Java Concept: Access Modifier & Encapsulation

접근제한자와 캡슐화, 그리고 더 나은 설계를 위한 메서드 활용법을 다룹니다.

자바 프로그래밍을 하다 보면 public, private 같은 단어들을 매일 마주하게 됩니다. 처음에는 "그냥 다 public으로 하면 편하지 않나?"라고 생각할 수 있습니다.

하지만 이 접근제한자(Access Modifier)야말로 객체 지향의 핵심인 보안과 무결성을 지키는 문지기 역할을 합니다.

오늘은 접근제한자의 종류와 범위부터, Getter/Setter의 장단점, 그리고 최근 실무에서 Getter/Setter 대신 선호하는 "의미 있는 메서드 설계"까지 완벽하게 정리해 보겠습니다.

1. 접근제한자 완벽 정리 (Scope)

접근 제한자는 "누구까지 들어오게 해줄 것인가?"를 결정하는 문지기입니다. 자바에는 4가지 등급의 보안 레벨이 있습니다.

접근제한자	내 클래스	같은 패키지	상속받은 자식	외부 전체
public	⭕	⭕	⭕	⭕
protected	⭕	⭕	⭕	❌
default (생략)	⭕	⭕	❌	❌
private	⭕	❌	❌	❌

Tip: 실무에서는 대부분 private(변수)과 public(메서드)을 주로 사용하며, 상속 관계 설계를 위해 protected를 종종 사용합니다.

2. 캡슐화와 Getter/Setter의 기본

캡슐화(Encapsulation)란?

객체의 중요한 데이터(필드)를 외부에서 마음대로 건드리지 못하게 꽁꽁 숨기는(private) 것입니다.

대신 안전하게 접근할 수 있는 통로(public 메서드)만 열어둡니다.

기본 사용법 (Java Beans 패턴)

public class Organism {
    // 1. 데이터는 private으로 숨김 (정보 은닉)
    private String name;
    private int age;

    // 2. Getter: 읽기 전용 통로
    public String getName() {
        return name;
    }

    // 3. Setter: 쓰기 전용 통로 (검증 로직 포함 가능)
    public void setAge(int age) {
        if (age < 0) {
            System.out.println("나이는 음수가 될 수 없습니다.");
            return;
        }
        this.age = age;
    }
}

3. Getter/Setter의 장단점 분석

"그냥 변수를 public으로 풀면 편한데 왜 귀찮게 Getter/Setter를 쓸까요?"

✅ 장점 (Pros)

무결성 보장: setAge(-5)처럼 말이 안 되는 데이터 입력을 if문으로 막을 수 있습니다.
접근 제어: Getter만 만들면 읽기 전용(Read-only) 필드로 만들 수 있습니다.
유지보수: 내부 변수명이 바뀌어도, 메서드 이름은 그대로 유지하여 외부 코드 수정을 막을 수 있습니다.

❌ 단점 (Cons)

캡슐화 위반 위험: 무분별한 Setter 남발은 사실상 public 변수와 다를 바 없습니다.
객체 수동성: 객체가 스스로 일을 처리하지 않고, 외부에서 값을 꺼내서(Get) 처리하고 다시 넣는(Set) 절차 지향적인 코드가 되기 쉽습니다.

4. 실무 트렌드: 의미 있는 메서드 설계

최근에는 "단순한 Setter 대신, 행위를 나타내는 메서드를 만들어라"라는 원칙이 강조되고 있습니다.

BAD - 단순 Setter 사용

Order order = new Order();
order.setStatus("SHIPPED"); // "상태를 바꾼다"는 단순한 데이터 변경

이 방식은 '왜' 상태가 바뀌는지, 배송이 시작되면 '무엇'을 더 해야 하는지(예: 알림 발송) 알기 어렵습니다.

GOOD - 비즈니스 용어 사용

public class Order {
    private String status;

    // 의미 있는 이름을 가진 메서드 (Setter 대체)
    public void startShipping() {
        if (this.status.equals("PAYMENT_COMPLETED")) {
            this.status = "SHIPPED";
            sendNotification(); // 관련된 로직도 함께 처리 가능!
        }
    }
}

// 사용처
order.startShipping(); // "배송을 시작해라!" (의도가 명확함)

이렇게 하면 코드만 읽어도 "아, 지금 배송 처리를 하는구나"라고 명확하게 의도를 파악할 수 있습니다.

5. 요약 및 결론

접근제한자: private(나만) < default < protected < public(모두)
캡슐화: 데이터는 private으로 숨기고, 필요한 경우에만 메서드로 열어주자.
Getter/Setter: 데이터 무결성을 위해 필요하지만, 무분별한 사용은 지양하자.
Tip: 단순히 값을 넣는 setXxx()보다는 cancelOrder(), updateUserInfo() 처럼 의도가 드러나는 이름을 짓자!

마무리:
좋은 객체는 자신의 데이터를 남에게 그냥 보여주지 않고(Getter), 외부에서 시키는 대로 그냥 값을 바꾸지 않습니다(Setter).
"스스로 데이터를 관리하고 행동하는 객체"를 만드는 것이 OOP의 핵심입니다.

[JAVA] 객체 지향 프로그래밍 4대 원칙

hlxecz — Fri, 12 Dec 2025 17:42:10 +0900

☕

Java Concept: OOP 4 Principles & Methods

이 포스팅은 객체 지향의 4대 원칙과 관련 문법, 사용 이유를 정리한 글입니다.

자바(Java)를 공부하다 보면 숨 쉬듯이 듣게 되는 단어가 있습니다. 바로 객체 지향 프로그래밍(OOP, Object-Oriented Programming)입니다.

"그냥 클래스 만들고 객체 생성하면 되는 거 아냐?"라고 생각하기 쉽지만, 실무에서 유지보수하기 좋은 코드를 짜기 위해서는 OOP의 4가지 핵심 원칙을 제대로 이해하고 있어야 합니다.

오늘은 캡슐화, 상속, 다형성, 추상화가 도대체 왜 필요하며, 자바에서 이를 구현하기 위해 어떤 키워드와 메서드를 사용하는지 완벽하게 파헤쳐 보겠습니다.

캡슐화 (Encapsulation)

캡슐화는 데이터(변수)와 그 데이터를 처리하는 코드(메서드)를 하나로 묶고, 외부로부터 보호하는 것입니다.

왜 사용하는가? (Why)

데이터 보호 (Data Integrity): 외부에서 변수에 직접 접근해 엉뚱한 값(예: 나이에 -5살)을 넣는 것을 방지합니다.
유지보수성: 내부 구현이 바뀌어도 외부에서는 메서드 이름만 알면 되므로 영향이 적습니다.

핵심 키워드 및 메서드

구분	설명
접근제어자	`private`(나만), `default(같은 패키지)`, `protected(상속)`, `public`(모두)
Getter / Setter	데이터를 읽고(Get), 검증 후 저장(Set)하는 메서드

public class BankAccount {
    private int balance; // 1. private으로 잠금

    // 2. Setter 메서드로 검증 로직 추가
    public void setBalance(int amount) {
        if (amount < 0) {
            System.out.println("유효하지 않은 금액입니다.");
            return;
        }
        this.balance = amount;
    }

    // 3. Getter 메서드로 읽기 권한 제공
    public int getBalance() {
        return this.balance;
    }
}

상속 (Inheritance)

상속은 부모 클래스의 속성과 기능을 자식 클래스가 물려받아 확장하는 것입니다.

왜 사용하는가? (Why)

코드 재사용 (Reusability): 똑같은 코드를 여러 번 짤 필요 없이 부모의 것을 가져다 씁니다.
계층 구조 형성: 사물 간의 관계(IS-A)를 명확하게 표현하여 체계적인 설계가 가능합니다.

핵심 키워드 및 메서드

구분	설명
extends	클래스를 상속받을 때 사용하는 키워드
super() / super.	부모의 생성자를 호출하거나, 부모의 변수/메서드에 접근할 때 사용

class Car { // 부모
    void drive() { System.out.println("운전합니다."); }
}

class SuperCar extends Car { // 자식 (extends 사용)
    void booster() {
        super.drive(); // 부모의 drive() 메서드 호출
        System.out.println("부스터 가동!");
    }
}

다형성 (Polymorphism)

다형성은 "하나의 객체나 메서드가 여러 가지 다른 형태를 가질 수 있는 성질"입니다. OOP의 꽃이라고 불립니다.

왜 사용하는가? (Why)

유연성 및 확장성: 새로운 클래스를 추가해도 기존 코드를 거의 수정하지 않고 그대로 사용할 수 있습니다.
일관된 인터페이스: 서로 다른 객체들을 하나의 타입(부모)으로 묶어서 관리할 수 있습니다. (예: `List list = new ArrayList()`)

핵심 키워드 및 메서드

구분	설명
Overriding	부모의 메서드를 자식 입맛에 맞게 재정의(덮어쓰기)
Overloading	같은 이름의 메서드를 매개변수만 다르게 하여 여러 개 정의
instanceof	객체가 특정 클래스의 인스턴스인지 확인하는 연산자

class Animal {
    void speak() { System.out.println("소리를 냅니다"); }
}

class Dog extends Animal {
    @Override // 오버라이딩
    void speak() { System.out.println("멍멍!"); }
    
    // 오버로딩 (같은 이름, 다른 매개변수)
    void speak(String mood) { System.out.println(mood + " 멍멍!"); }
}

추상화 (Abstraction)

추상화는 불필요한 세부 정보는 숨기고, 중요한 공통 기능(본질)만 추출하여 정의하는 것입니다.

왜 사용하는가? (Why)

설계의 표준화: 개발자들에게 "이 기능은 반드시 구현해야 해!"라고 강제성을 부여하여 일관된 설계를 유도합니다.
복잡도 감소: 구체적인 동작 방법(How)은 몰라도, 무슨 역할(What)을 하는지만 알면 사용할 수 있습니다.

핵심 키워드 및 메서드

구분	설명
abstract	추상 클래스나 추상 메서드를 선언할 때 사용 (미완성 설계도)
interface	구현체가 없는 100% 껍데기, 다중 상속 가능 (설계 표준)
implements	인터페이스를 구현할 때 사용하는 키워드

// 추상화: "그림을 그린다"는 기능만 정의 (껍데기)
interface Shape {
    void draw(); // abstract method
}

// 구체화: 실제 어떻게 그릴지는 구현 클래스가 담당
class Circle implements Shape {
    @Override
    public void draw() { System.out.println("원을 그립니다."); }
}

OOP를 사용하는 이유

마지막으로 객체 지향 프로그래밍의 4대 원칙을 한눈에 정리해 봅시다.

원칙	핵심 키워드	사용 이유 (Benefit)
캡슐화	private, Getter/Setter	데이터 보호 및 무결성 유지
상속	extends, super	코드 중복 제거, 재사용성 향상
다형성	Overriding, Overloading	유연한 확장, 변경 최소화
추상화	interface, abstract	복잡도 감소, 설계 표준 제시

객체 지향의 장점

객체 지향 프로그래밍(OOP)을 도입했을 때 얻을 수 있는 강력한 이점들을 정리해 보았습니다.

장점	설명
유지보수 용이	하나의 객체 또는 클래스 단위로 수정이 가능하여, 전체 시스템의 안정성을 유지하기 쉽습니다.
♻️ 재사용성 증가	잘 설계된 클래스와 객체는 다른 프로젝트나 다양한 상황에서 쉽게 재활용할 수 있습니다.
확장성 우수	기능 추가 시 기존 코드를 건드리지 않고, 새로운 객체만 추가하면 되어 확장이 유연합니다.
현실 세계 모델링	사람, 동물, 식물 등 실체를 코드로 자연스럽게 표현(매핑)할 수 있어 설계가 직관적입니다.
코드 가독성 향상	객체와 클래스 중심으로 역할이 명확하게 분리되어 있어, 코드를 읽고 이해하기가 쉬워집니다.

결론:
OOP는 단순히 코드를 짜는 문법이 아니라, "유지보수하기 쉽고 유연한 소프트웨어"를 만들기 위한 철학입니다.
이 핵심 원칙과 장점들을 마음속에 새기고 코딩한다면, 여러분의 코드는 훨씬 더 견고해질 것입니다.

Big-O, 왜 상수는 무시할까? (feat. Ω, Θ 표기법 정리)_Part 2

hlxecz — Mon, 8 Dec 2025 18:28:26 +0900

시리즈 알림: 이 글은 시간 복잡도 심화편(Part 2)입니다.
기초적인 O(n) vs O(n²) 실전 예제는 Part 1 (이전 글)을 참고해주세요.

지난 포스팅에서 우리는 시간 복잡도를 통해 코드의 효율성을 판단하는 법을 배웠습니다.

그런데 공부를 하다 보면 두 가지 의문이 생깁니다.

"왜 2n이나 100n이나 똑같이 O(n)이라고 퉁치는 걸까?"
"Big-O 말고 오메가(Ω), 세타(Θ)는 대체 뭘까?"

오늘은 개발자 면접이나 전공 수업에서 깊이 있게 다루는 시간 복잡도의 수학적 원리를 아주 쉽게 풀어서 정리해 보겠습니다.

1. 왜 상수(Constant)는 생략하는가?

우리는 흔히 O(2n)을 O(n)으로, O(n² + 100)을 O(n²)으로 표기합니다. 2배나 차이가 나는데 왜 무시하는 걸까요?

핵심: "정확한 시간"이 아니라 "성장 패턴"이 중요하다

Big-O는 "몇 초가 걸리냐"를 재는 것이 아니라, "입력 크기(n)가 무한대로 커질 때, 연산량이 어떤 그래프 모양으로 증가하는가"

를 보는 지표이기 때문입니다.

예시 비교:

O(n): n=1,000일 때 → 1,000번 연산
O(2n): n=1,000일 때 → 2,000번 연산

물론 2배 차이가 나지만, n이 커질수록 "정비례해서 늘어난다(선형 증가)"는 패턴은 동일합니다. 그래프의 기울기만 다를 뿐, 모양은 직선으로 똑같죠.

생략 규칙 정리

가장 영향력이 큰 항(Dominant Term)만 남기고 나머지는 과감히 버립니다.

규칙	예시	결과 (Big-O)	이유
상수 곱 무시	2n, 100n	O(n)	단순히 기울기 차이일 뿐, 패턴 동일
낮은 차수 무시	n² + n + 1	O(n²)	n이 커지면 n²이 압도적으로 주도함
로그보다 n 우선	n + log n	O(n)	log n의 증가 속도는 매우 느림
상수만 존재	100번 수행	O(1)	입력 크기와 무관하게 고정됨

2. Big-O (O): 상한선

우리가 가장 흔하게 쓰는 표기법입니다. 알고리즘 성능의 "최악의 상황" 혹은 "아무리 느려도 이것보단 안 느리다(상한)"는 것을 보장합니다.

수학적 정의

f(n) ≤ C · g(n)
(for sufficiently large n)

의미: f(n)의 증가 속도가 g(n)보다 빨라지지 않는다. (위에서 눌러주는 상한선)

예를 들어 f(n) = n² + n + 1 이라는 알고리즘이 있을 때, n이 충분히 크다면 C · n²보다 항상 작거나 같습니다.
따라서 이 알고리즘은 f(n) ∈ O(n²) 이라고 할 수 있습니다.

3. Big-Ω, Big-Θ: 다른 형제들

Big-O만 있는 게 아닙니다. 상황에 따라 하한선이나 정확한 구간을 표현해야 할 때도 있습니다.

Big-Ω (오메가): 하한선 (최소 성장 속도)

"아무리 빨라도 이것보단 빠를 수 없다"는 최소한의 연산량을 의미합니다.

f(n) ≥ c · g(n)

의미: f(n)의 증가 속도가 g(n)보다 느리지 않다. (아래에서 받쳐주는 하한)

예: n² + n + 1은 아무리 작아도 n² 보다는 큽니다. → f(n) ∈ Ω(n²)

Big-Θ (세타): 딱 맞는 성장 속도

상한(O)과 하한(Ω)이 같을 때, 즉 "딱 이 정도 속도로 성장한다"고 정확하게 말할 때 사용합니다.

f(n) ∈ O(g(n)) AND f(n) ∈ Ω(g(n))

의미: f(n)과 g(n)이 같은 차수로 성장한다. (샌드위치처럼 딱 맞음)

예: n² + n + 1은 n²의 상한도 만족하고 하한도 만족하므로 → f(n) ∈ Θ(n²)

4. 요약

보통 알고리즘 문제 풀이(코딩 테스트)에서는 Big-O(최악의 경우)만 고려하면 됩니다. 내가 짠 코드가 최악의 상황에서도 제한 시간 내에 통과하는지가 중요하기 때문입니다.

O(2n) → O(n): 성장 패턴(기울기)이 선형으로 같기 때문에 상수는 무시한다.
Big-O (O): "최악의 경우엔 이 정도야" (상한선)
Big-Ω (Ω): "최소한 이만큼은 걸려" (하한선)
Big-Θ (Θ): "정확히 이 정도 차수야" (평균/정확)

이제 누군가 "왜 상수를 떼고 말하나요?"라고 묻는다면, "입력 데이터가 무한대로 커질 때의 성장 패턴을 보기 위함입니다!"라고 멋지게 대답해 보세요.

내 코드가 느린 이유? 시간 복잡도(Time Complexity)와 Big-O 정리_Part 1

hlxecz — Mon, 8 Dec 2025 17:30:51 +0900

Problem Source: GitHub - Sw_Pilot_Java (Chapter 2 / Step 2 - 3)

이 포스팅은 해당 리포지토리의 문제에 대한 분석 및 풀이 과정을 담고 있습니다.

알고리즘 문제를 풀거나 실무에서 대용량 데이터를 다루다 보면, 기능은 완벽한데 "시간 초과"가 뜨거나 시스템이 버벅이는 경우를 마주합니다.

이때 우리가 가장 먼저 점검해야 할 것이 바로 시간 복잡도(Time Complexity)입니다. 오늘은 제가 공부한 내용을 바탕으로, O(n²)의 늪에서 빠져나와 O(n)으로 최적화하는 과정을 정리해보려 합니다.

1. 시간 복잡도란?

시간 복잡도는 알고리즘이 입력 크기(Input Size)에 따라 얼마나 많은 연산을 수행하는지를 나타내는 지표입니다.

단순히 "몇 초 걸린다"가 아니라, 수학적으로 실행 시간의 변화 추이를 표현하는 것이죠.

최악의 시간(Worst Case): 빅오(Big-O) 표기법의 기준이 되며, 가장 오래 걸릴 때를 가정합니다.
필요성: 효율적인 알고리즘 선택, 성능 개선 포인트 파악, 대규모 데이터 처리 가능 여부 판단

2. Big-O 표기법 총정리

Big-O 표기법은 데이터 입력 크기(n)가 무한대로 커질 때, 연산 횟수가 어떻게 증가하는지 상한선을 나타냅니다.

아래 표는 빠른 순서(위)에서 느린 순서(아래)로 정렬되어 있습니다.

표현	속도 / 이름	대표 예시
O(1)	상수 시간 (Fastest)	Stack의 Push/Pop, 배열 인덱스 접근
O(log n)	로그 시간	이진 탐색 (Binary Search)
O(n)	선형 시간	for문 1번 순회
O(n log n)	선형 로그 시간	퀵 정렬(Quick), 병합 정렬(Merge)
O(n^2)	이차 시간	이중 for문, 삽입/거품 정렬
O(2^n)	지수 시간 (Exponential)	피보나치 수열(재귀), 부분집합 구하기
O(n!)	팩토리얼 시간 (Slowest)	외판원 순회 문제(TSP), 모든 순열 구하기

성능 순서 요약:
O(1) < O(log n) < O(n) < O(n log n) < O(n²) < O(2^n) < O(n!)

오른쪽으로 갈수록(아래로 갈수록) 실행 시간이 기하급수적으로 늘어나므로,
데이터가 많을 때는 O(n²) 이상의 알고리즘은 피하는 것이 좋습니다.

▲ Big-O Complexity Chart (입력 크기에 따른 시간 증가량)

3. Case Study 01: 중복 없는 숫자 찾기

첫 번째 케이스는 "리스트에서 딱 한 번만 등장하는 숫자를 찾는 상황"입니다. 여기서 초보자들이 가장 많이 하는 실수가 발생합니다.

내가 작성한 문제의 코드 (O(n²))

for (int val : list) {
    // 리스트 전체를 돌면서 val의 개수를 센다
    if (Collections.frequency(list, val) == 1) { 
        System.out.println(val);
    }
}

병목 분석

Collections.frequency(list, val) 메서드는 마법처럼 숫자를 세주는 게 아닙니다.

내부적으로 리스트 전체를 처음부터 끝까지 순회(O(n))합니다.

바깥쪽 for문: n회 반복
안쪽 frequency: n회 탐색
총 시간 복잡도: n × n = O(n²)

데이터가 10만 개라면, 100억 번의 연산을 하게 되어 프로그램이 멈출 수 있습니다.

최적화: HashMap 사용 (O(n))

이 문제를 해결하기 위해 HashMap을 사용하여 데이터를 미리 세어둡니다(Preprocessing).

// 1. O(n): 리스트를 한 번만 돌면서 개수를 맵에 저장
Map<Integer, Integer> countMap = new HashMap<>();
for (int val : list) {
    countMap.put(val, countMap.getOrDefault(val, 0) + 1);
}

// 2. O(n): 맵을 확인하며 1번만 등장한 값 찾기
// (Map의 조회는 평균적으로 O(1)입니다)

이렇게 하면 루프가 중첩되지 않고 분리되어 O(n) + O(n) = O(2n), 즉 O(n)으로 획기적인 성능 향상이 일어납니다.

4. Case Study 02: 회문(Palindrome) 판별기

두 번째 케이스는 "문장을 단어별로 쪼개고, 회문이면 출력, 아니면 뒤집어서 출력"하는 로직입니다.

내가 작성한 코드 (O(n))

// 문장을 단어별로 쪼갬
for (int i = sens.length - 1; i >= 0; i--) {
    // 각 단어(word)의 앞뒤를 비교 (회문 검사)
    for (int e = 0; e < word.length() / 2; e++) {
        if (word.charAt(e) != word.charAt(word.length() - 1 - e)) {
            // ...
        }
    }
}

복잡도 분석 (이건 병목이 아님)

얼핏 보면 for문 안에 for문이 있어 O(n²)처럼 보일 수 있습니다. 하지만 자세히 들여다보면 다릅니다.

n: 단어의 개수
k: 각 단어의 평균 길이
N: 전체 문자열의 길이 (n × k)

우리는 모든 단어의 모든 글자를 한 번씩만 확인합니다. 즉, 전체 연산 횟수는 전체 글자 수(N)와 비례합니다.

결론: O(nk) = O(N) (전체 문자 수 기준 선형 시간)
입력 길이가 최대 10⁶이라도, O(N)은 충분히 효율적이므로 굳이 최적화할 필요가 없습니다.

5. 병목 현상 및 최적화 방안 요약

오늘 분석한 내용을 표로 정리해 보았습니다.

구분	병목 원인	기존 시간 복잡도	개선 후
Case 01 (숫자 찾기)	Collections.frequency에 의한 중복 순회 발생	O(n²) (매우 느림)	O(n) (HashMap 사용)
Case 02 (회문 판별)	없음 (구조적으로 효율적)	O(N) (전체 문자 수)	변경 불필요

시간 복잡도 분석은 "내 코드가 왜 느린지"를 찾아내는 가장 중요한 핵심 이론입니다.

Case 01처럼 숨겨진 루프(frequency)를 찾아내 O(n)으로 만드는 것이 최적화의 핵심이고, Case 02처럼 구조적으로 이미 최적화된 코드를 구별해내는 안목 또한 중요한 것 같습니다.

참고 자료
- Big-O Cheat Sheet
- VisuAlgo
- GeeksforGeeks (Collections.frequency)