개발블로그

[객체지향] PHP readonly 속성과 클래스

devmel — Sun, 6 Sep 2026 15:22:25 +0900

개념

의미

속성을 초기화한 뒤 값을 다시 대입하거나 수정하지 못하도록 제한하는 키워드

객체를 만들 때 설정한 식별자나 생성 시각처럼, 이후 유지해야 하는 값에 사용할 수 있음.

읽기 전용 속성은 PHP8.1부터 지원함

비교 : final vs readonly

구분	final	readonly
클래스에 적용	클래스 상속 금지	모든 인스턴스 속성에 읽기 전용 규칙 적용
속성에 적용	자식 클래스에서 속성 재선언 금지	초기화 이후 속성 변경 제한
메서드에 적용	오버라이딩 금지	적용 불가

- 동시 적용 가능

문법

class ClassName
{
	// 속성 선언, 아직 값은 없음
    public readonly string $propertyName;

	// 첫 값 대입으로 초기화
    public function __construct(string $value)
    {
        $this->propertyName = $value;
    }
}

ex)

class UserProfile
{
    public readonly int $id;

    public function __construct(int $id)
    {
        $this->id = $id;
    }
}

$user = new UserProfile(1001);

echo $user->id; // 1001

$user->id = 2002; // 오류: 초기화된 readonly 속성 변경

선언과 초기화

선언만으로 값이 생기는 것이 아니라, 허용된 범위에서 처음 값을 대입해야 사용할 수 있음.

class UserProfile
{
    public readonly int $id;
}

$user = new UserProfile();

echo $user->id; // 오류: 초기화 전 접근

[ 허용된 범위 ]

위치	PHP 8.1~8.3	PHP 8.4 이상
선언한 클래스 내부	가능	가능
자식 클래스 내부	불가능	가능
클래스 외부	불가능	불가능

기본값 선언 제한

일반적인 속성 선언 위치에서는 기본값을 지정할 수 없음

- 대신 생성자 매개변수에 기본값을 두고, 그 값을 속성에 대입할 수 있다.

ex)

class UserProfile
{
    public readonly int $id = 1001; // 오류
}

// 아래는 가능
class UserProfile
{
    public readonly int $id;

    public function __construct(int $id = 1001)
    {
        $this->id = $id;
    }
}

$user = new UserProfile();
echo $user->id; // 1001

적용타입

readonly 속성에는 타입을 반드시 선언해야 함.

(여러 종류의 값 허용시, mixed사용 가능)

변경 제한

단순한 재대입뿐 아니라, 증가 연산이나 배열 요소 수정처럼 속성값을 변경하는 동작도 제한

ex)

class UserProfile
{
    public readonly int $id;
    public readonly array $roles;

    public function __construct(int $id, array $roles)
    {
        $this->id = $id;
        $this->roles = $roles;
    }
}

$user = new UserProfile(1001, ["user"]);

echo $user->id;       // 1001
echo $user->roles[0]; // user

$user->id = 2002;          // 재대입 불가
$user->id = 1001;          // 같은 값을 다시 대입해도 불가
$user->id++;              // 증가 연산 불가

$user->roles[] = "admin";  // 배열 요소 추가 불가
$user->roles[0] = "guest"; // 배열 요소 변경 불가
unset($user->roles[0]);    // 배열 요소 삭제 불가

값의 조회와 활용

저장된 값을 읽어 다른 계산이나 처리에 사용하는 것은 가능

ex)

$nextId = $user->id + 1;

$roles = $user->roles;
$roles[] = "admin";

echo $nextId;          // 1002
echo count($roles);    // 2
echo count($user->roles); // 1

객체 속성과 내부 상태 변경

readonly 속성에 객체를 저장하면, 그 속성이 가리키는 객체를 교체할 수 없음

단, 저장된 객체 내부의 속성까지 자동으로 읽기 전용이 되는 것은 아님.

ex)

class Address
{
    public string $city;

    public function __construct(string $city)
    {
        $this->city = $city;
    }
}

class UserProfile
{
    public readonly Address $address;

    public function __construct(Address $address)
    {
        $this->address = $address;
    }
}

$user = new UserProfile(new Address("Seoul"));

// 내부 값은 변경 가능
$user->address->city = "Busan";
echo $user->address->city; // Busan

// 객체 교체는 불가
$user->address = new Address("Jeju");
// 오류: 초기화된 readonly 속성에 다른 객체 대입

읽기 전용 클래스

개념

클래스에 readonly를 붙이면, 해당 클래스의 모든 인스턴스 속성에 읽기 전용 규칙이 적용됨

속성마다 readonly를 반복해서 작성할 필요가 없음

(8.2 부터 가능)

문법

readonly class ClassName // 읽기 전용 클래스 선언
{
    public string $propertyName; // 자동으로 readonly 규칙이 적용되는 속성
    
    // static propery는 만들 수 없음

    public function __construct(string $value)
    {
        $this->propertyName = $value;
    }
}

ex)

readonly class UserProfile
{
    public int $id;
    public string $name;

    public function __construct(int $id, string $name)
    {
        $this->id = $id;
        $this->name = $name;
    }
}

$user = new UserProfile(1001, "Kim");

echo $user->id;   // 1001
echo $user->name; // Kim

$user->name = "Lee"; // 오류: 초기화된 readonly 속성 변경

// 선언되지 않은 $email을 추가하면 오류 발생
$user->email = "kim@example.com"; // 오류: 동적 속성 추가

상속 규칙

readonly 클래스를 상속하는 자식 클래스도 readonly로 선언해야 함

ex)

readonly class BaseProfile
{
}

readonly class UserProfile extends BaseProfile
{
}

주의점

초기화 누락

값을 읽기 전에 초기화되어야 한다.

- null을 허용하는 타입이라고 해서 자동으로 null이 저장되지는 않음

내부 상태의 변경 가능성

readonly 속성에 객체를 저장하면 그 객체를 교체하는 것은 제한되지만, 내부 상태는 변경될 수 있음.

객체 전체의 불변성이 필요하다면 내부 객체가 제공하는 속성과 메서드까지 확인해야 함

객체 복제 시 재초기화

php 8.3부터는 __clone()에서 복제본의 readonly 속성을 한 번 재초기화할 수 있음

=> 복제 과정에서 적용되는 예외이며, 일반 메서드에서 이미 초기화된 속성을 다시 대입할 수 있다는 뜻은 아님

ex)

class UserProfile
{
    public readonly Address $address;

    public function __construct(Address $address)
    {
        $this->address = $address;
    }

    public function __clone(): void
    {
        $this->address = clone $this->address;
    }
}

// 앞서 정의만 Address 클래스를 사용하는데, 복제 시 주소 객체도 복제하여 원본과 복제본이 
// 같은 주소 객체를 공유하지 않도록 함

[객체지향] PHP final 키워드

devmel — Sat, 5 Sep 2026 21:30:25 +0900

개념

의미

상속을 통한 확장이나 재정의를 제한하는 키워드

적용 대상	제한 내용
클래스	해당 클래스를 상속할 수 없음
메서드	자식 클래스에서 해당 메서드를 오버라이딩할 수 없음
상수와 속성	클래스 상수 (PHP 8.1 이상) - 자식 클래스에서 상수 재정의 금지 속성 (PHP 8.4 이상) - 자식 클래스에서 속성 재정의 금지

일반 문법

/**
 * 클래스에 적용
 * => 해당 클래스를 상속하는 자식 클래스를 만들 수 없음
 */
final class FinalClass
{
    // 클래스 정의
}

/**
 * 메서드에 적용
 * => 자식 클래스에서 해당 메서드를 재정의할 수 없음
 */
class MethodExample
{
    final public function methodName(): void
    {
        // 메서드 구현
    }
}

/**
 * 상수에 적용 (PHP 8.1 이상)
 * => 자식 클래스에서 해당 상수를 재정의할 수 없음
 */
class ConstantExample
{
    final public const CONSTANT_NAME = "값";
}

/**
 * 속성에 적용 (PHP 8.4 이상)
 * => 자식 클래스에서 해당 속성을 재정의할 수 없음
 * => 객체의 속성값 변경은 가능
 */
class PropertyExample
{
    final public string $propertyName = "초기값";
}

ex]

/**
클래스 적용
*/
final class Calculator
{
    public function add(int $a, int $b): int
    {
        return $a + $b;
    }
}

$calculator = new Calculator();
echo $calculator->add(10, 20); // 30

// 아래 클래스 선언은 오류 발생
// class CustomCalculator extends Calculator {}


/*
메서드 적용
*/
class Calculator
{
    final public function add(int $a, int $b): int
    {
        return $a + $b;
    }
}

class CustomCalculator extends Calculator
{
    // 아래 메서드를 선언하면 오류 발생
    // public function add(int $a, int $b): int
    // {
    //     return $a + $b + 100;
    // }
}

$calculator = new CustomCalculator();
echo $calculator->add(10, 20); // 30


/**
상수 적용
*/
class Response
{
    final public const SUCCESS = 200;
}

class CustomResponse extends Response
{
    // 아래 상수를 선언하면 오류 발생
    // public const SUCCESS = 201;
}

echo CustomResponse::SUCCESS; // 200


/**
속성 적용
*/
class UserProfile
{
    final public string $name = "Kim";
}

class CustomProfile extends UserProfile
{
    // 아래 속성을 선언하면 오류 발생
    // public string $name = "Lee";
}

$user = new CustomProfile();
$user->name = "Lee";

echo $user->name; // Lee

[객체지향] PHP Trait

devmel — Sat, 5 Sep 2026 20:51:54 +0900

개념

필요성

서로 다른 클래스에서 같은 기능이 필요한 경우가 있음.

ex) 사용자 관리 클래스와 파일 처리 클래스가 모두 로그를 기록한다고 할 때,

각 클래스에 같은 메서드를 작성하면 중복이 생기고, 기능이 바뀔 때 여러 곳을 수정해야 함

개념

여러 클래스에 포함하여 재사용할 수 있는 메서드와 속성의 묶음

- Trait을 포함한 클래스에서는 해당 메서드를 자신의 메서드처럼 사용할 수 있음.

문법

기본 문법

trait TraitName
{
    // 속성 정의
    private string $propertyName = "초기값";

    // 메서드 정의
    public function methodName(): string
    {
        return $this->propertyName;
    }
}

class ClassName
{
    use TraitName;
}

$object = new ClassName();
echo $object->methodName(); // 초기값

ex)

trait LoggerTrait
{
    private string $prefix = "[LOG]";

    public function log(string $message): void
    {
        echo "{$this->prefix} {$message}\n";
    }
}

class UserService
{
    use LoggerTrait;
}

class FileService
{
    use LoggerTrait;
}

$userService = new UserService();
$fileService = new FileService();

$userService->log("사용자 생성");
$fileService->log("파일 저장");
/*
[LOG] 사용자 생성
[LOG] 파일 저장
*/

여러 클래스에서 여러 Trait을 함께 사용할 수 있음

trait FirstTrait
{
    public function firstMethod(): void
    {
        // 첫 번째 기능
    }
}

trait SecondTrait
{
    public function secondMethod(): void
    {
        // 두 번째 기능
    }
}

class ClassName
{
    use FirstTrait, SecondTrait;
}

ex)

trait LoggerTrait
{
    public function log(string $message): void
    {
        echo "[LOG] {$message}\n";
    }
}

trait NotifierTrait
{
    public function notify(string $message): void
    {
        echo "[알림] {$message}\n";
    }
}

class UserService
{
    use LoggerTrait, NotifierTrait;

    public function register(): void
    {
        $this->log("사용자 등록");
        $this->notify("가입 완료");
    }
}

$service = new UserService();
$service->register();

메소드 충돌 해결

여러 Trait에 같은 이름의 메서드가 있으면, 어떤 구현을 사용할지 명시해야 함.

키워드	역할
insteadof	충돌하는 메서드 중 사용할 구현 선택
as	메서드에 별칭 추가

class ClassName
{
    use FirstTrait, SecondTrait {
        FirstTrait::methodName insteadof SecondTrait;
        	// methodName을 호출하면, SecondTrait대신 FirstTrait의 구현을 사용하도록 지정
        SecondTrait::methodName as anotherMethod;
        	// SecondTrait의 methodName를 anotherMethod의 이름으로 사용할 수 있도록 별칭 추가
    }
}

ex)

trait ConsoleLoggerTrait
{
    public function log(string $message): void
    {
        echo "[일반] {$message}\n";
    }
}

trait JsonLoggerTrait
{
    public function log(string $message): void
    {
        echo json_encode(["message" => $message]) . "\n";
    }
}

class UserService
{
    use ConsoleLoggerTrait, JsonLoggerTrait {
        ConsoleLoggerTrait::log insteadof JsonLoggerTrait;
        JsonLoggerTrait::log as logJson;
    }
}

$service = new UserService();

$service->log("created");
$service->logJson("created");
/*
[일반] created
{"message":"created"}
*/

접근 제어자와 별칭 지정

Trait을 클래스에 포함할 때 as를 사용하면 메서드의 접근 범위를 변경하거나, 호출할 이름을 추가할 수 있음

use TraitName {
    methodName as private;
    // 기존 메서드의 접근 범위 변경
}

use TraitName {
    methodName as aliasName;
    // 기존 메서드에 별칭 추가
}

use TraitName {
    methodName as private aliasName;
    // private 접근 범위를 가진 별칭 추가
}

ex)

trait LoggerTrait
{
    public function log(string $message): void
    {
        echo "[LOG] {$message}\n";
    }
}

/*
접근 범위만 변경
*/
class UserService
{
	// 기존 log()가 private가 됨. 이름은 그대로이며 외부 호출은 제한 됨
    use LoggerTrait {
        log as private;
    }
}

/*
별칭만 추가
*/
class UserService
{
	//기존 log()를 유지하면서 writeLog()라는 호출 이름을 추가한다. 둘 다 public이며 같은 구현을 실행한다.
    use LoggerTrait {
        log as writeLog;
    }
}

/*
별칭의 접근 범위까지 지정
*/
class UserService
{
    use LoggerTrait {
        log as private writeLog;
    }
}

Trait의 추상메서드

Trait에 추상 메서드를 선언하면, Trait을 사용하는 클래스가 제공해야 할 메서드를 지정할 수 있다.

=> Trait은 해당 메서드를 호출하는 공통 흐름을 구현하고, 구체적인 동작은 사용하는 클래스에 맡긴다

trait TraitName
{
	// abstract = 메서드 구현이 필요함을 선언하는 키워드
    abstract protected function requiredMethod(): string;

}

class ClassName
{
    use TraitName;

    protected function requiredMethod(): string
    {
        return "구현 결과";
    }
}

ex) 로그 출력 방식은 공통으로 사용하고, 로그에 표시할 서비스 이름은 각 클래스에서 정의하도록 함

trait LoggerTrait
{
    abstract protected function getLogName(): string;

    public function log(string $message): void
    {
        echo "[{$this->getLogName()}] {$message}\n";
    }
}

class UserService
{
    use LoggerTrait;

    protected function getLogName(): string
    {
        return "USER";
    }
}

class FileService
{
    use LoggerTrait;

    protected function getLogName(): string
    {
        return "FILE";
    }
}

$userService = new UserService();
$fileService = new FileService();

$userService->log("사용자 생성");
$fileService->log("파일 저장");
/*
[USER] 사용자 생성
[FILE] 파일 저장
*/

메서드 우선순위

클래스에 직접 정의한 메서드
↓ 우선
Trait에서 포함한 메서드
↓ 우선
부모 클래스에서 상속받은 메서드

※ 위 순서는 정상적으로 재정의할 수 있는 메서드를 기준으로 함.

부모 메서드가 final이거나 선언이 호환되지 않는 경우에는 우선순위로 해결되지 않고 오류가 발생할 수 있음

주의점

이름충돌

여러 Trait을 포함하면 같은 이름의 메서드나 속성이 겹칠 수 있음

=> Trait을 추가할 때는 현재 클래스와 다른 Trait에 이미 같은 이름이 있는지 확인해야 함

숨겨진 의존 관계

Trait이 사용하는 클래스의 특정 속성이나 메서드를 당연히 존재한다고 가정하면,

필요한 조건을 파악하기 어려워짐

=> 필요한 속성을 Trait에 선언하거나, 클래스별 값이 필요하다면 추상 메서드로 요구사항을 명시할 수 있음

과도한 기능 포함

클래스에 Trait을 많이 넣으면 실제로 어떤 속성과 메서드를 가지는지 확인하기 어려워질 수 있음

확인 항목	판단 기준
기능의 관련성	Trait 내부 기능들이 같은 역할에 속하는가?
사용 범위	포함한 클래스에서 실제로 필요한 기능인가?
코드 추적	메서드의 정의 위치를 쉽게 찾을 수 있는가?
변경 영향	Trait 수정이 사용하는 클래스들에 어떤 영향을 주는가?

객체 조합과의 구분

Trait은 클래스 정의에 구현을 포함하는 방식이다.

실행 중에 Trait을 다른 Trait으로 교체하는 방식으로 사용하지 않음.

=> 실행 시점에 구현을 선택하거나 교체해야 한다면, 별도의 객체를 전달받아 사용하는 구조가 더 합할 수 있음

PHP 변수 대입과 객체 복제

devmel — Sat, 5 Sep 2026 19:40:09 +0900

기본값 대입

개념

대입 연산자(=) = 오른쪽 값을 왼쪽 변수에 저장하는 연산자

=> 숫자나 문자열을 다른 변수에 대입하면, 각 변수의 값은 독립적으로 사용할 수 있음.

이후 한 변수의 값을 변경해도 다른 변수에는 영향을 주지 않음

$variableA = 값;
$variableB = $variableA;

// $variableB에는 대입 시점의 $variableA 값이 전달된다. 이후 $variableA의 변경을 자동으로 따라가지는 않는다.

ex)

// 숫자 대입
$number = 10;
$otherNumber = $number;

$otherNumber = 20;

echo $number;      // 10
echo $otherNumber; // 20


// 문자열 대입
$name = "Kim";
$otherName = $name;

$name = "Lee";

echo $name;      // Lee
echo $otherName; // Kim

객체 대입

개념

객체를 다른 변수에 대입하면, 객체가 복제되는 대신 두 변수가 같은 객체를 가리킴

=> PHP의 객체 변수에는 특정 객체에 접근하는 객체 식별자가 담긴다. = 로 대입하면 이 식별자가 복사됨

=> 같은 객체를 가리키므로 한 변수를 통해 속성을 변경하면 다른 변수에서도 변경된 값을 확인할 수 있음

$objectA = new ClassName();
$objectB = $objectA;

/*
$objectA ──┐
           ├──→ 하나의 객체
$objectB ──┘

=>변수는 두 개지만, 객체는 하나
*/

ex)

class UserProfile
{
    public string $name;

    public function __construct(string $name)
    {
        $this->name = $name;
    }
}

$user = new UserProfile("Kim");
$other = $user;

$other->name = "Lee";
/*
$other->name = "Lee"
→ 두 변수가 가리키는 객체의 name 변경

$user  ──┐
         ├──→ UserProfile
$other ──┘      name: "Lee"
*/

echo $user->name;  // Lee
echo $other->name; // Lee

객체 재대입

한 변수에 새로운 객체를 대입하면 그 변수가 가리키는 대상만 바뀜

ex)

$user = new UserProfile("Kim");
$other = $user;

$other = new UserProfile("Lee");

echo $user->name;  // Kim
echo $other->name; // Lee

/*
$user  ───→ 기존 객체
              name: "Kim"

$other ───→ 새로운 객체
              name: "Lee"
*/

참조 대입

개념

두 변수 이름이 같은 변수 내용을 공유하도록 연결하는 방식

- 연결된 이후에는 어느 쪽에 값을 대입하든 다른 변수에서도 변경된 값이 나타남

문법

$variableA = 값;
$variableB =& $variableA;
/*
$variableA ──┐
             ├──→ 공유하는 값
$variableB ──┘

=> $variableB를 $variableA의 또 다른 이름처럼 사용할 수 있다.
*/

예시

/*
기본값의 참조 대입
*/
$number = 10;
$otherNumber =& $number;

$otherNumber = 20;

echo $number;      // 20
echo $otherNumber; // 20

$number = 30;

echo $number;      // 30
echo $otherNumber; // 30


/*
객체의 참조 대입
=> 객체 속성 변경뿐 아니라 새로운 객체를 대입한 결과도 공유함
*/
$user = new UserProfile("Kim");
$other =& $user;

$other = new UserProfile("Lee");

echo $user->name;  // Lee
echo $other->name; // Lee

주의점

객체 공유와 참조 재입의 구분

객체를 함께 수정하기 위해 반드시 &가 필요한 것은 아님

=> 일반 대입만으로도 같은 객체를 가리키므로 속성 변경을 함께 확인할 수 있다.

참조 대입은 변수에 다른 값을 재대입한 결과까지 공유해야 하는지 따져보고 사용함.

객체 복제

개념

기존 객체의 속성값을 바탕으로 새로운 객체를 만드는 동작.

일반 대입(=)은 같은 객체를 가리키지만, clone은 별도의 객체를 생성함

문법

$original = new ClassName();
$copy = clone $original;

/*
$original ───→ 원본 객체
$copy     ───→ 복제된 객체
=> 복제 직후에는 속성값이 같더라도 서로 다른 객체
*/

예시

ex)

$user = new UserProfile("Kim");
$copy = clone $user;

$copy->name = "Lee";

echo $user->name; // Kim
echo $copy->name; // Lee

/* 
[실행과정]
① 원본 생성

$user ───→ UserProfile
             name: "Kim"

② 복제

$user ───→ UserProfile
             name: "Kim"

$copy ───→ UserProfile
             name: "Kim"

③ 복제본의 이름 변경

$user ───→ UserProfile
             name: "Kim"

$copy ───→ UserProfile
             name: "Lee"
*/

얕은 복사와 깊은 복사

개념

객체의 속성에는 문자열이나 숫자뿐 아니라 다른 객체도 들어갈 수 있다.

이때 복제 범위에 따라 얕은 복사와 깊은 복사를 구분함.

구분	복제 범위	내부 객체
얕은 복사	바깥 객체를 복제	원본과 복제본이 공유
깊은 복사	내부 객체까지 복제	원본과 복제본이 별도로 사용

예시

/**
[얕은 복사]
*/
class Address
{
    public string $city = "Seoul";
}

class UserProfile
{
    public string $name = "Kim";
    public Address $address;

    public function __construct()
    {
        $this->address = new Address();
    }
}

$user = new UserProfile();
$copy = clone $user;
/*
$user → 원본 UserProfile
          address ──┐
                    ├──→ 하나의 Address
$copy → 복제 UserProfile   city: "Seoul"
          address ──┘
*/

// 복제본의 이름과 주소를 변경해 보기
$copy->name = "Lee";
$copy->address->city = "Busan";

echo $user->name;          // Kim
echo $copy->name;          // Lee

echo $user->address->city; // Busan
echo $copy->address->city; // Busan


/**
[깊은 복사]

주소까지 독립적으로 변경하려면 내부의 Address도 별도로 복제해야 함
=> 별도의 deep clone 연산자가 없기 때문에, 필요한 내부 객체를 직접 복제해야 함
*/

깊은 복사 방법

__clone() 안에서 내부 객체를 추가로 복제하면, 원본과 복제본이 서로 다른 내부 객체를 사용하도록 만들 수 있음.

public function __clone(): void
{
    $this->property = clone $this->property;
}

EX]

class Address
{
    public string $city = "Seoul";
}

class UserProfile
{
    public string $name = "Kim";
    public Address $address;

    public function __construct()
    {
        $this->address = new Address();
    }

    public function __clone(): void
    {
        $this->address = clone $this->address;
    }
}

$user = new UserProfile();
$copy = clone $user;

$copy->address->city = "Busan";

echo $user->address->city; // Seoul
echo $copy->address->city; // Busan

주의점

복제 범위 설정

내부 객체를 무조건 모두 복제하기보다, 복제본에서 독립적으로 변경해야 하는 데이터인지 먼저 판단

[객체지향] PHP 매직 메서드

devmel — Sat, 5 Sep 2026 18:55:13 +0900

개념

특정 상황이 발생했을 때 PHP가 자동으로 호출하는 특수 메서드

ex) 존재하지 않거나 접근할 수 없는 속성을 읽으려고 하면 => __get()이 호출될 수 있음

이름이 __로 시작함

사용목적

객체의 기본 동작을 원하는 방식으로 제어할 때 사용

종류

종류	메서드	호출 시점
생성	__construct()	new로 객체 생성 시
소멸	__destruct()	객체 소멸 시
속성 읽기	__get()	존재하지 않거나 접근할 수 없는 속성 읽기
속성 쓰기	__set()	존재하지 않거나 접근할 수 없는 속성에 대입
객체 메서드 호출	__call()	존재하지 않거나 접근할 수 없는 객체 메서드 호출
정적 메서드 호출	__callStatic()	존재하지 않거나 접근할 수 없는 정적 메서드 호출
문자열 변환	__toString()	객체를 문자열로 사용
함수형 호출	__invoke()	객체를 함수처럼 호출
복제	__clone()	clone으로 복제한 후 복제본에서 실행

생성과 소멸

생성자 __construnct()

객체를 생성할 때 자동으로 실행되는 메서드

=> 객체가 처음부터 필요한 데이터를 가진 상태로 사용할 수 있도록 초기 상태를 설정함

용도	설명
초기값 설정	객체가 사용할 속성값 설정
필수 데이터 전달	객체 생성에 필요한 정보 전달
초기 데이터 검증	전달받은 값이 올바른지 확인

[ 문법 ]

class ClassName
{
    public function __construct($value)
    {
        // 객체 생성 시 수행할 초기화
    }
}

$object = new ClassName($value);
// new ClassName($value)에 전달한 값은 __construct($value)의 매개변수로 전달된다.

[ 예시 ]

class UserProfile
{
    private string $name;

    public function __construct(string $name)
    {
        $this->name = $name;
        echo "프로필 생성: {$this->name}\n";
    }

    public function getName(): string
    {
        return $this->name;
    }
}

$user = new UserProfile("Kim");
echo $user->getName();
/* [결과]
프로필 생성: Kim
Kim
*/

소멸자 __destruct()

객체가 소멸할 때 자동으로 실행되는 메서드

=> 객체가 사용하던 자원을 정리하는 등의 마무리 작업에 사용.

[ 문법 ]

public function __destruct()
{
    // 객체 소멸 시 수행할 처리
}

[ 관련 메서드 : unset($변수) ]

변수를 해제하는 동작.

※ 다른 변수가 같은 객체를 참조하고 있다면 바로 소멸하지 않음.

[ 예시 ]

public function __destruct()
{
    echo "프로필 소멸: {$this->name}\n";
}

$user = new UserProfile("Kim");

echo "프로필 사용 중\n";

unset($user);

/*
프로필 생성: Kim
프로필 사용 중
프로필 소멸: Kim
*/

속성 접근

속성 읽기 __get()

존재하지 않거나 현재 위치에서 접근할 수 없는 속성을 읽을 때 자동으로 실행되는 메서드

- 읽으려는 속성의 이름을 전달받고, 어떤 값을 반환할지 직접 정의함

[ 문법 ]

public function __get(string $name): mixed 
{
    // 속성을 읽을 때 반환할 값
}
// $name = 읽으려는 속성 이름
// $mixed = 여러 타입의 값을 반환할 수 있다는 의미

[ 예시 ]

class UserProfile
{
    private array $data = [
        "name" => "Kim"
    ];

    public function __get(string $name): mixed
    {
        return $this->data[$name] ?? null;
        	// 해당 키가 없거나 값이 null이면 null을 반환함
    }
}

$user = new UserProfile();

echo $user->name; // Kim
	// UserProfile에는 $data 속성만 있고, $name 속성은 선언되어 있지 않음. 
    // 따라서 $user->name을 읽으면 __get("name")을 호출함 
    // $this->data["name"] 을 조회
    // "Kim" 반환

속성 쓰기 __set()

존재하지 않거나 현재 위치에서 접근할 수 없는 속성에 값을 대입할 때 자동으로 실행되는 메서드

- 속성 이름과 대입할 값을 전달받고, 그 값을 어떻게 처리할지 정의 함

[ 문법 ]

public function __set(string $name, mixed $value): void
	// $name = 대입하려는 속성 이름
    // $value = 대입할 값
    // void = 반환값 없음
{
    // 전달받은 값을 저장하거나 검증
}

[ 예시 ]

class UserProfile
{
    private array $data = [
        "name" => "Kim"
    ];

    public function __get(string $name): mixed
    {
        return $this->data[$name] ?? null;
    }
    
    // 이와 같은 메서드를 추가하면 => 외부에서 값을 대입하고 다시 읽을 수 있음
    public function __set(string $name, mixed $value): void
    {
        $this->data[$name] = $value;
    }
}

$user = new UserProfile();

$user->name = "Lee"; // __set("name", "Lee")
echo $user->name;    // __get("name") → Lee
/*
$user->name = "Lee"
→ __set("name", "Lee")
→ 내부 배열의 "name" 값을 "Lee"로 변경

echo $user->name
→ __get("name")
→ 변경된 값 "Lee" 반환
*/

메서드 호출

객체 메서드 호출 __call()

존재하지 않거나 현재 위치에서 접근할 수 없는 메서드를 호출할 때 자동으로 실행되는 메서드

[ 문법 ]

class ClassName
{
    public function __call(string $name, array $arguments): mixed
    {
        // $name과 $arguments를 사용해 호출 처리
    }
}
// $name = 호출하려던 메서드 이름
// $arguments = 전달할 인수를 담은 배열, 인수가 없으면 []
// mixed = 처리 결과로 여러 타입의 값을 반환할 수 있음

$object = new ClassName();
$object->methodName($argument1, $argument2);

/*
$object->methodName($argument1, $argument2)
→ 접근 가능한 methodName()이 없는 경우
→ __call("methodName", [$argument1, $argument2])
*/

[ 예시 ]

class UserProfile
{
    private array $data = ["name" => "Kim"];

    public function __call(string $name, array $arguments): mixed
    {
        if ($name === "getName" && $arguments === []) {
            return $this->data["name"];
        }

        throw new BadMethodCallException("지원하지 않는 호출: $name");
    }
}

$user = new UserProfile();
echo $user->getName(); // Kim
	// getName()은 정의되어 있지 않음 => PHP가 대신 __call()을 호출함
    // __call("getName", [])
    // 작성해 둔 조건에 따라 "Kim" 반환

정적 메서드 호출 __callStatic()

존재하지 않거나 현재 위치에서 접근할 수 없는 정적 메서드를 호출할 때 자동으로 실행되는 메서드

- 클래스명::메서드() 형태의 호출을 처리하며, 메서드 선언에 static을 붙임

[ 문법 ]

class ClassName
{
    public static function __callStatic(
        string $name,
        array $arguments
    ): mixed {
        // $name과 $arguments를 사용해 호출 처리
    }
}

ClassName::methodName($argument1, $argument2);
/*
ClassName::methodName($argument1, $argument2)
→ 접근 가능한 정적 methodName()이 없는 경우
→ __callStatic("methodName", [$argument1, $argument2])
*/

[예시]

public static function __callStatic(string $name, array $arguments): mixed
{
    if ($name === "create" && $arguments === []) {
        return new self();
    }

    throw new BadMethodCallException("지원하지 않는 호출: $name");
}

$user = UserProfile::create();
echo $user->getName(); // Kim
/*
UserProfile::create()
→ 접근 가능한 정적 create() 메서드가 없음
→ __callStatic("create", [])
→ new self()로 UserProfile 객체 생성 후 반환
*/

문자열 반환

__toString()

객체를 문자열로 사용할 때 실행되는 메서드.

- 객체를 어떤 문자열로 표현할지 개발자가 정의함
- echo로 객체를 출력하거나 (string)으로 변환할 때 호출 됨

[ 문법 ]

class ClassName
{
    public function __toString(): string
    	// public => 외부에서 접근 가능한 메서드로 선언
        // 매개변수 없음 => 문자열 변환 시 별도 인수를 받지 않음
        // : string => 문자열을 반환하도록 선언 
    {
        return "객체를 표현할 문자열";
    }
}

$object = new ClassName();

echo $object;
$text = (string) $object;

[ 예시 ]

class UserProfile
{
    private string $name;

    public function __construct(string $name)
    {
        $this->name = $name;
    }

    public function __toString(): string
    {
        return "사용자: {$this->name}";
    }
}

$user = new UserProfile("Kim");

echo $user; // 사용자: Kim
/*
echo $user
→ 객체를 문자열로 표현해야 함
→ PHP가 __toString() 호출
→ "사용자: Kim" 반환
→ echo가 반환된 문자열 출력
*/

함수형 호출

__invoke()

객체를 함수처럼 호출할 때 실행되는 메서드.

- 객체 변수 뒤에 ()를 붙여 호출할 수 있음

[ 문법 ]

class ClassName
{
    public function __invoke($parameter)
    	// $parameter = 호출 시 전달받을 값
    {
        // 객체를 함수처럼 호출했을 때 수행할 처리
        return $parameter;
    }
}

$object = new ClassName();
$result = $object($argument); // $object($argument) = 객체를 함수처럼 호출하는 문법
/*
$object($argument)
→ PHP가 __invoke($argument) 호출
→ 메서드 내부 코드 실행
→ 반환값을 $result에 저장
*/

[ 예시 ]

class UserProfile
{
    private array $data = [
        "name" => "Kim",
        "role" => "admin"
    ];

    public function __invoke(string $key): mixed
    {
        return $this->data[$key] ?? null;
    }
}

$user = new UserProfile();

echo $user("name") . "\n";
echo $user("role");
/*
Kim
admin
*/

객체 복제

__clone()

clone으로 객체를 복제한 뒤, 복제본에서 실행되는 메서드

복제된 객체의 일부 값을 변경하거나, 내부에 포함된 객체를 추가로 복제하는 데 사용함.

[ 문법 ]

class ClassName
{
    public function __clone(): void
    {
        // 복제본에 필요한 추가 처리
    }
}

$original = new ClassName();
$copy = clone $original; // 기존 객체를 복제하여 새 객체 생성

[특징]

- __clone() 안의 $this는 복제본이므로 원본 이름은 변경되지 않음

=> clone이 먼저 새로운 객체를 만든다음, __clone()을 그 새 객체에서 실행함
(새로운 객체가 아닌, 같은 객체를 두 변수가 가리킴)

- 복제할 때 __construnct()가 다시 실행되지 않음.

- 기본적으로 얕은 복사를 수행함.

속성에 다른 객체가 들어 있다면 그 내부 객체까지 자동으로 복제되지는 않는다.

내부 객체도 분리해야 한다면 __clone()안에서 해당 객체를 다시 clone해야 함.

class Address
{
    public string $city;

    public function __construct(string $city)
    {
        $this->city = $city;
    }
}

class User
{
    public string $name;
    // User 객체 안에 Address 객체 있음.
    public Address $address;

    public function __construct(string $name, Address $address)
    {
        $this->name = $name;
        $this->address = $address;
    }
}

$address = new Address("Seoul");

$user = new User("Kim", $address);

$copy = clone $user;
/*
$user -> User 객체 A
$copy -> User 객체 B
*/

// 단순한 속성인 name을 변경하면 서로 영향을 주지 않음
$copy->name = "Lee";
echo $user->name; // Kim
echo $copy->name; // Lee

// address의 경우
/*
$user
└─ User 객체 A
   ├─ name = "Kim"
   └─ address ──────┐
                    ↓
               Address 객체 C
               city = "Seoul"

$copy
└─ User 객체 B
   ├─ name = "Kim"
   └─ address ──────┘
   
=> 두 속성이 같은 Address 객체를 바라보고 있음.
*/

// 복제본에서 주소를 변경하면
$copy->address->city = "Busan";

// 결과는 => 둘 다 바뀜 
// why) Address 객체 자체는 복제되지 않음 
echo $user->address->city; // Busan
echo $copy->address->city; // Busan

[ 예시 ]

class UserProfile
{
    public string $name;

    public function __construct(string $name)
    {
        $this->name = $name;
    }

    public function __clone(): void
    {
        $this->name .= " (복사본)";
    }
}

$user = new UserProfile("Kim");
$copy = clone $user;

echo $user->name . "\n";
echo $copy->name;
/*
Kim
Kim (복사본)
*/

주의점

호출 흐름의 명확성

매직 메서드는 코드에 메서드 이름이 직접 나타나지 않아, 실제로 어떤 코드가 실행되는지 파악하기 어려울 수 있음

=> 일반 속성이나 메서드로 충분히 표현할 수 있다면 직접 선언하는 편이 명확함

ex]

$user->name;       // __get()으로 연결될 수 있음
$user->getRole();  // __call()로 연결될 수 있음
$user("role");     // __invoke() 실행

오타와 잘못된 호출

존재하지 않는 속성이나 메서드를 처리할 때, 모든 요청을 받아 주면 오타를 발견하기 어려워질 수 있음

상태 변경 규칙

__set()을 정의했다고 해서 데이터가 자동으로 보호되는 것은 아님

=> 허용할 항목, 값의 타입, 수정 가능 여부가 중요하다면 메서드 내부에 검증 규칙을 직접 작성해야 함

동작의 예측 가능성

매직 메서드의 동작은 해당 문법에서 자연스럽게 예상할 수 있는 범위로 유지하는 것이 좋음.

메서드	설계 시 고려사항
__get()	단순 조회에 예상치 못한 상태 변경이 포함되지 않는지
__set()	저장할 값과 수정 가능한 항목을 검증하는지
__call()	지원하는 호출과 잘못된 호출을 구분하는지
__toString()	객체를 표현하는 문자열을 일관되게 반환하는지
__invoke()	객체를 함수처럼 호출하는 의미가 명확한지
__clone()	내부 객체도 별도로 복제해야 하는지

소멸 시점의 의존성

객체는 다른 곳에서 참조하는 동안 유지될 수 있으므로, 원하는 업무 시점과 소멸 시점이 일치한다고 가정하면 안 된다.

파일 저장이나 작업완료처럼 실행 시점이 중요한 처리는 일반 메서드로 명시적으로 호출하고, 소멸자에는 적절한 정리 자겅븡ㄹ 두는 편이 좋음.

[객체지향] PHP static과 스코프 해석 연산자

devmel — Sat, 5 Sep 2026 16:13:21 +0900

개념

static

객체가 아니라 클래스 자체에 속한 속성이나 메서드를 정의할 때 사용하는 키워드

static으로 정의한 속성이나 메서드는 객체를 만들지 않고 클래스 이름으로 접근 가능

클래스 멤버]

구분	의미	예시
객체 멤버	객체마다 따로 가지는 속성이나 메서드	자동차의 색상, 무게
클래스 멤버	클래스 자체에 속하는 속성이나 메서드	생성된 자동차 수, 공통 설정값
클래스 상수	클래스 안에 정의한 변하지 않는 값	상태 코드, 타입 값

스코프 해석 연산자

=> 클래스, 부모 클래스, 현재 클래스의 정적 멤버나 상수에 접근할 때 사용

비교]

연산자	사용 대상	예시
->	객체	$car->startEngine()
::	클래스, 정적 멤버, 상수	Car::getCount()

정적 속성

객체가 아니라 클래스 자체에 속하는 속성

속성 앞에 static을 붙여 정의

class Car
{
    public static $count = 0;
    public $color = "";
    
    public function __construct()
    {
        self::$count++;
    }
}

// 접근 : 객체를 생성하지 않고, 클래스 이름으로 접근
echo Car::$count;

// 일반속성은 객체마다 따로 존재함
$car1 = new Car();
$car2 = new Car();

$car1->color = "black";
$car2->color = "white";

// 정적속성은 모든 객체가 공유함
echo Car::$count; // 2

정적 메서드

개념/문법

객체를 만들지 않고 클래스 이름으로 호출할 수 있는 메서드

class Calculator
{
    public static function add($a, $b)
    {
        return $a + $b;
    }
}

echo Calculator::add(10, 20); // 30

정적 메서드 안에서든 $this 사용 불가

why) $this는 현재 객체를 의미하는데, 정적 메서드는 객체 없이 이름으로 호출될 수 있기 때문에 객체가 존재하지 않음

=> 정적메서드에서 정적 속성에 접근하려면 self:: 사용

class Car
{
    public static $count = 0;

    public static function getCount()
    {
        return self::$count;
    }
}

객체 멤버와 차이

구분	객체 멤버	정적 멤버
소속	객체	클래스
접근 방식	$object->method()	ClassName::method()
상태	객체마다 다를 수 있음	클래스 단위로 공유됨
$this 사용	가능	불가능

늦은 정적 바인딩

개념

상속 관계에서 static:: 이 실제로 호출한 클래스 기준으로 동작하게 하는 PHP의 기능

=> 어떤 클래스를 기준으로 할지 코드 작성 시점에 고정하지 않고 실행 시점에 결정 함

비교

키워드	기준
self::	코드가 작성된 클래스
static::	실제로 호출한 클래스

필요성

상속 구조에서는 부모 클래스에 공통 정적 메서드를 두고, 자식 클래스마다 일부 정적 동작만 다르게 만들고 싶을 때가 있음.

EX) 부모 클래스에는 공통 조회 메서드가 있고, 자식 클래스마다 다른 테이블 이름을 반환해야 함

Model
→ User
→ Post

<?php

class ParentClass
{
    public static function identify()
    {
        return "부모";
    }

    public static function test()
    {
        echo "self 결과: " . self::identify() . PHP_EOL;
        echo "static 결과: " . static::identify() . PHP_EOL;
    }
}

class ChildClass extends ParentClass
{
    public static function identify()
    {
        return "자식";
    }
}

ChildClass::test();
/*
[결과]
self 결과: 부모
static 결과: 자식

[실행흐름]
ChildClass::test()
        ↓
ParentClass에 작성된 test() 실행
        ↓
self::identify()
        ↓
ParentClass::identify()
        ↓
"부모"

static::identify()
        ↓
ChildClass::identify()
        ↓
"자식"
*/

주의점

static과 스코프 해석 연산자는 클래스 단위의 값이나 기능을 다룰 때 유용하다.

하지만 정적 멤버를 무분별하게 사용하면 객체지향적인 구조가 흐려질 수 있음

static 남용

정적 메서드는 객체를 만들지 않고 바로 호출할 수 있어 편리하다.

객체 상태와 무관한 유틸리성 기능이라면 정적 메서드가 잘 맞을 수 있다.

하지만 객체가 가져야 할 상태나 책임까지 정적 메서드로 처리하며 코드가 절차적인 함수 모음처럼 변할 수 있다

EX]

class UserService
{
    public static function createUser($name)
    {
        // 사용자 생성
    }

    public static function updateUser($id, $name)
    {
        // 사용자 수정
    }

    public static function deleteUser($id)
    {
        // 사용자 삭제
    }
}

전역 상태

정적 속성은 클래스 전체에서 공유되는 값이기 때문에 여러 곳에서 같은 값을 쉽게 사용할 수 있다.

하지만 정적 속성은 전역 상태처럼 사용될 수 있어서, 어디서든 접근하고 변경할 수 있으면, 값이 언제 어디서 바뀌었는지 추적하기 어려워진다.

테스트 어려움

정적 메서드나 정적 속성에 강하게 의존하면 테스트가어려워질 수 있음.

ex]

class OrderService
{
    public function createOrder($name)
    {
        Logger::log("주문 생성: " . $name);
    }
}

Logger에 직접 의존함.

테스트할 때 가짜 로거로 교체하거나, 로그 호출 여부만 따로 확인하기 어려울 수 있음.

반면 필요한 객체를 외부에서 전달받으면 더 유연해짐

ex)

class OrderService
{
    private $logger;

    public function __construct($logger)
    {
        $this->logger = $logger;
    }

    public function createOrder($name)
    {
        $this->logger->log("주문 생성: " . $name);
    }
}

테스트 시 원하는 로거 객체를 넣을 수 있음.

고려사항

질문	의미
객체 상태와 무관한 기능인가?	정적 메서드가 적합한지 판단한다.
여러 객체가 공유해야 하는 값인가?	정적 속성이 필요한지 확인한다.
어디서든 값이 바뀌어도 괜찮은가?	전역 상태 문제가 없는지 본다.
테스트에서 쉽게 대체할 수 있는가?	정적 의존성이 테스트를 어렵게 만들지 않는지 확인한다.
객체의 책임을 정적 메서드로 빼앗고 있지는 않은가?	객체지향 구조가 흐려지는지 점검한다.

PHP 네임스페이스와 use

devmel — Sat, 5 Sep 2026 14:59:20 +0900

네임스페이스

개념

클래스 이름의 충돌을 막기 위한 이름 공간 (이름 앞에 소속 공간)

네임스페이스를 두면 같은 클래스 이름이라도 서로 다른 공간에 둘 수 있다.

문법

namespace 키워드로 클래스가 속할 이름 공간을 선언

- 보통 파일 경로와 비슷하게 맞춰 사용함 => 클래스가 어느 영역에 속하는지 파악하기 쉽고, 자동 로딩 설정과도 잘 어울림.

다, 네임스페이스와 파일 경로가 자동으로 연결되는 것은 아님. 파일 안에 직접 선언해야 함.

as로 별칭을 지정 가능

- 너무 추상적이거나 일관성이 없으면, 오히려 읽기 어려워 질 수 있음.

- 과한 별칭은 원래 클래스의 소속을 파악하기 어려울 수 있음.

EX]

<?php

namespace App\Service;

class Logger
{
}

=> Logger 클래스의 전체 이름 = App\Service\Logger

use

개념

다른 네임스페이스에 있는 클래스를 현재 파일에서 짧게 사용하기 위한 문법

$logger = new App\Service\Logger();
 // 매번 전체 이름으로 쓰면 코드가 길어짐
 
use App\Service\Logger;
// 별칭
use External\Library\Logger as ExternalLogger;

$logger = new Logger(); // 짧은 파일 이름으로 사용 가능
$externalLogger = new ExternalLogger();

[디자인패턴] 싱글톤 패턴

devmel — Fri, 4 Sep 2026 19:06:48 +0900

개념

필요성

프로그램을 만들다 보면 어떤 객체는 여러 개 만들어질 필요가 없거나, 여러 개 만들어지면 문제가 되는 경우가 있다.

EX] 애플리케이션 설정 정보를 관리하는 객체

config1 = AppConfig()
config2 = AppConfig()

만약 설정 객체가 여러 개 만들어지고, 각각 다른 상태를 가지게 된다면 프로그램 안에서 사용하는 설정값이 달라질 수 있음

=> 이런 상황에서는 어느 설정값이 실제 기준인지 헷갈릴 수 있음

또 데이터베이스 연결 관리자, 로거, 캐시 관리자처럼 애플리케이션 전체에서 하나의 기준으로 관리하는 객체도 있다.

이런 객체가 불필요하게 여러 개 만들어지면 상태 관리가 어려워지거나 자원이 낭비될 수 있음

의미

특정 클래스의 인스턴스를 하나만 생성하고, 그 인스턴스에 접근할 수 있는 방법을 제공하는 패턴

구분	의미
하나의 인스턴스	특정 클래스의 객체가 프로그램 안에서 하나만 존재한다.
접근 지점 제공	그 하나의 객체를 사용할 수 있는 방법을 제공한다.
생성 제어	외부에서 객체를 마음대로 여러 개 만들지 못하게 한다.

핵심 구조

구성 요소	역할
Singleton Class	하나의 인스턴스만 생성되도록 관리하는 클래스
Instance 저장 공간	생성된 하나의 인스턴스를 저장하는 변수
접근 메서드	저장된 인스턴스를 반환하는 메서드

흐름]

인스턴스 요청
→ 이미 만들어진 인스턴스가 있는지 확인
→ 없으면 새로 생성
→ 있으면 기존 인스턴스 반환

예시

EX]

애플리케이션 설정을 관리하는 AppConfig

class AppConfig:
    def __init__(self):
        self.database_url = None

이 클래스를 여러 곳에서 각각 생성하면 서로 다른 설정 객체가 만들어짐

config1 = AppConfig()
config2 = AppConfig()

config1.database_url = "db-main"
config2.database_url = "db-test"

이제 config1과 config2는 서로 다른 상태를 가짐

객체	database_url
config1	db-main
config2	db-test

문제는 애플리케이션 안에서 어떤 설정 객체를 기준으로 봐야 하는지 모호해질 수 있음

def connect_database(config):
    return f"{config.database_url}에 연결"

connect_database(config1)  # db-main에 연결
connect_database(config2)  # db-test에 연결

어떤 곳에서는 config1을 넘기고, 다른 곳에서는 config2를 넘기면 실행 위치에 따라 다른 설정값을 사용할 수 있음

설정값처럼 애플리케이션 전체에서 하나의 기준으로 관리되어야 하는 객체라면,

여러 인스턴스가 만들어지는 구조가 문제가 될 수 있음

문제	설명
상태 불일치	같은 설정 객체라고 생각했지만 서로 다른 값을 가질 수 있다.
기준 모호	어떤 인스턴스가 실제 기준인지 알기 어렵다.
자원 낭비	데이터베이스 연결 관리자처럼 무거운 객체가 여러 번 생성될 수 있다.
변경 추적 어려움	어느 객체의 상태가 언제 바뀌었는지 추적하기 어렵다.

이런 경우는 하나의 인스턴스만 생성되도록 관리할 필요가 있음.

싱글톤으로 인스턴스 하나만 관리할 필요가 있음.

class AppConfig:
	# _instance = 생성된 객체를 저장하는 변수
    _instance = None

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
            cls._instance.database_url = None
        return cls._instance

여러 변 생성하더라도 같은 객체가 반환됨

config1 = AppConfig()
config2 = AppConfig()

config1.database_url = "db-main"

print(config2.database_url)  # db-main
print(config1 is config2)    # True

장점

장점	설명
인스턴스 중복 생성 방지	같은 객체가 여러 번 생성되는 것을 막을 수 있다.
일관된 상태 관리	여러 곳에서 같은 인스턴스를 사용하므로 기준 상태를 통일할 수 있다.
공통 자원 접근 관리	설정, 로거, 연결 관리자 같은 공용 자원을 한곳에서 관리할 수 있다.
접근 지점 단순화	필요한 곳에서 같은 인스턴스에 접근하는 방식을 제공할 수 있다.

효과적인 상황

상황	이유
설정 정보를 한곳에서 관리해야 하는 경우	여러 객체가 서로 다른 설정값을 가지는 문제를 줄일 수 있다.
로거처럼 공통으로 사용하는 객체가 필요한 경우	프로그램 전체에서 같은 로깅 기준을 사용할 수 있다.
데이터베이스 연결 관리자처럼 생성 비용이 큰 객체가 있는 경우	불필요한 중복 생성을 줄일 수 있다.
하나의 상태를 기준으로 여러 곳에서 접근해야 하는 경우	같은 인스턴스를 공유해 일관성을 유지할 수 있다.

주의점

주의점	설명
전역 상태 문제	여러 곳에서 같은 상태를 공유하면 변경 영향이 넓게 퍼질 수 있다.
테스트 어려움	테스트마다 독립적인 상태를 만들기 어렵고, 이전 테스트의 상태가 남을 수 있다.
의존 관계 숨김	코드 안에서 싱글톤을 직접 호출하면 어떤 의존성이 필요한지 겉으로 드러나지 않는다.
동시성 문제	여러 흐름에서 동시에 같은 객체를 수정하면 상태 충돌이 생길 수 있다.
생명주기 관리 어려움	언제 생성되고 언제 초기화되는지 명확하지 않으면 관리가 어려워질 수 있다.

고려사항

질문	의미
정말 하나만 존재해야 하는 객체인가?	단순히 편해서 싱글톤을 쓰는 것은 아닌지 확인한다.
상태 변경이 여러 곳에 영향을 줘도 괜찮은가?	공유 상태의 변경 범위를 고려한다.
테스트마다 상태를 분리할 수 있는가?	테스트 독립성을 해치지 않는지 확인한다.
의존성이 코드 밖으로 드러나는가?	숨겨진 의존성이 생기지 않도록 한다.
동시 접근 상황에서 안전한가?	여러 흐름이 동시에 사용할 때 문제가 없는지 확인한다.

[디자인패턴] 데코레이터 패턴

devmel — Fri, 4 Sep 2026 14:56:52 +0900

개념

필요성

프로그램을 만들다 보면 기존 기능은 유지하면서, 그 앞뒤로 부가 기능을 추가해야 하는 경우가 있다.

EX]

결제 기능

payment.pay(10000)

처음에는 결제만 처리하면 충분할 수 있다.

하지만 시간이 지나면 결제 전후로 여러 기능이 추가될 수 있다.

ex) 로깅, 권한 확인, 캐싱, 알림

기능들이 기존 결제 클래스 안에 계속 추가되면, 클래스의 책임이 점점 커짐.

class PaymentService:
    def pay(self, amount):
        check_permission()
        write_log("결제 시작")

        result = process_payment(amount)

        send_notification()
        write_log("결제 완료")

        return result

문제는 결제 기능 자체와 부가 기능이 강하게 묶인다.

나중에 로깅만 제거하거나, 알림만 다른 상황에서 추가하고 싶을 때 유연하게 조합하기 어려움.

" 기존 객체를 직접 수정하지 않고, 기능을 덧붙일 수 없을까?"

의미

기존 객체를 감싸는 방식으로 부가 기능을 추가하는 패턴

기존 객체의 코드는 그대로 두고, 그 객체를 감싸는 데코레이터 객체가 앞뒤로 추가 동작을 수행

구분	역할	예시
Component	공통으로 사용할 기능의 형태	Payment
Concrete Component	기본 기능을 수행하는 실제 객체	BasicPayment
Decorator	기존 객체를 감싸고 부가 기능을 추가하는 객체	LoggingPayment, PermissionPayment, NotificationPayment

핵심은 기존 객체와 데코레이터가 같은 형태의 메서드를 제공함

그래서 사용하는 쪽에서는 기본 객체인지, 데코레이터로 감싼 객체인지 같은 방식으로 사용할 수 있다.

기존 객체를 내부에 가지고 있다가, 필요할 때 기존 객체의 기능을 호출함.

그리고 호출 전후에 자신의 부가 기능을 추가함.

예시

EX]

결제 기능을 담당하는 BasicPayment

class BasicPayment:
    def pay(self, amount):
        return f"{amount}원 결제 완료"

여러 기능이 추가될 때, 가장 간단한 방법은 기존 클래스 안에 부가 기능을 직접 넣는 것

class BasicPayment:
    def pay(self, amount):
        check_permission()
        write_log("결제 시작")

        result = f"{amount}원 결제 완료"

        send_notification()
        write_log("결제 완료")

        return result

문제	설명
책임 혼합	결제 처리, 권한 확인, 로깅, 알림이 한곳에 섞인다.
조합 어려움	어떤 상황에서는 로깅만, 다른 상황에서는 알림만 적용하기 어렵다.
수정 범위 증가	부가 기능이 바뀔 때 결제 클래스도 함께 수정된다.
클래스 증가 가능성	상속으로 조합하면 경우의 수만큼 클래스가 늘어날 수 있다.

기본 기능과 부가 기능을 분리하고, 필요한 기능만 조합할 수 있는 구조가 필요함.

=> 데코레이터로 기능 감싸기

결제 객체가 공통으로 제공할 동작을 정한다

class Payment:
    def pay(self, amount):
        pass

기본 결제 기능은 BasicPayment가 담당

class BasicPayment(Payment):
    def pay(self, amount):
        return f"{amount}원 결제 완료"

부가 기능은 데코레이터로 분리

class LoggingPayment(Payment):
    def __init__(self, payment):
        self.payment = payment

    def pay(self, amount):
        print("결제 시작 로그")
        result = self.payment.pay(amount)
        print("결제 완료 로그")
        return result

내부에 다른 Payment 객체를 가지고 있음.

그리고 pay()를 호출할 때 기존 객체의 pay()를 실행하면서 앞뒤로 로그를 추가

권한 확인도 별도의 데커레이터로 만들 수 있음

class PermissionPayment(Payment):
    def __init__(self, payment):
        self.payment = payment

    def pay(self, amount):
        print("권한 확인")
        return self.payment.pay(amount)

필요한 기능을 감싸서 조합할 수 있다.

payment = BasicPayment()
payment = LoggingPayment(payment)
payment = PermissionPayment(payment)

payment.pay(10000)

실행흐름)

PermissionPayment.pay()
→ 권한 확인
→ 내부에 감싼 LoggingPayment.pay() 호출
→ 결제 시작 로그
→ 내부에 감싼 BasicPayment.pay() 호출
→ 실제 결제 실행
→ 결제 완료 로그

데코레이터들의 pay()는 같은 결제를 여러 번 실행하는 것이 아니라, 요청을 안쪽 객체로 전달하면서 앞뒤에 부가 기능을 추가하는 역할을 한다.

장점

장점	설명
기존 코드 변경 최소화	기본 기능을 담당하는 클래스를 직접 수정하지 않고 기능을 추가할 수 있다.
기능 조합 유연성	필요한 부가 기능을 원하는 순서로 조합할 수 있다.
책임 분리	기본 기능과 부가 기능을 각각 다른 객체로 나눌 수 있다.
상속보다 유연한 확장	기능 조합마다 새로운 자식 클래스를 만들 필요가 줄어든다.
실행 시점 조합 가능	어떤 데코레이터를 적용할지 실행 중에 선택할 수 있다.

효과적인 상황

상황	이유
기존 코드를 직접 수정하기 어려운 경우	기본 객체를 감싸서 기능을 추가할 수 있다.
부가 기능 조합이 여러 가지인 경우	상속보다 유연하게 조합할 수 있다.
기능을 실행 시점에 선택해야 하는 경우	필요한 데코레이터를 조건에 따라 적용할 수 있다.
기본 기능과 부가 기능을 분리하고 싶은 경우	각 기능의 책임을 나눌 수 있다.

주의점

단점

주의점	설명
흐름 추적 어려움	여러 객체가 겹쳐 있으면 실제 실행 순서를 파악하기 어려울 수 있다.
순서 의존성	권한 확인, 로깅, 알림처럼 실행 순서가 중요한 기능은 조합 순서를 신경 써야 한다.
디버깅 어려움	문제가 발생했을 때 어느 데코레이터에서 발생했는지 추적해야 한다.
과한 구조 가능성	단순한 기능 추가에는 데코레이터보다 직접 구현이 더 명확할 수 있다.
책임 혼합 위험	데코레이터가 부가 기능을 넘어 핵심 비즈니스 로직까지 담당하면 구조가 흐려진다.

주의점

질문	의미
기존 객체를 직접 수정하지 않아야 하는 이유가 있는가?	데코레이터를 둘 필요가 있는지 확인한다.
부가 기능을 여러 방식으로 조합해야 하는가?	조합의 이점이 있는지 판단한다.
실행 순서가 중요한가?	데코레이터를 감싸는 순서를 명확히 해야 한다.
데코레이터가 너무 많이 겹치지 않는가?	구조가 과하게 복잡해지는지 확인한다.
부가 기능과 핵심 기능의 책임이 분리되어 있는가?	데코레이터가 핵심 로직을 침범하지 않게 한다.

[디자인패턴] 어댑터 패턴

devmel — Fri, 4 Sep 2026 14:12:53 +0900

개념

필요성

프로그램을 만들다 보면 이미 존재하는 코드와 새로 사용해야 하는 코드의 형식이 맞지 않는 경우가 있음.

=> 기존 코드가 기대하는 방식과 새로 연결할 객체의 방식이 다를 때, 중간에서 맞춰줄 수 없을까?

ex)

결제 객체가 pay(amount)라는 메서드를 제공

payment.pay(10000)

그런데 새로 연동해야 하는 외부 결제 API는 다른 이름과 다른 형식의 메서드를 제공 할 수 있음

external_payment.request_payment(price=10000)

기능은 비슷함 (둘 다 결제를 처리)

BUT 사용하는 방식이 다르기 때문에 기존 코드에서는 바로 사용할 수 없음.

해결방법 => 외부 API를 기존 코드 형식에 맞게 감싸기

의미

어댑터 패턴은 서로 맞지 않는 인터페이스를 중간에서 변환해 연결하는 패턴

=> 기존 코드는 익숙한 방식 그대로 사용할 수 있음.

핵심 구조

구성 요소	역할	예시
Client	기존 인터페이스를 사용하는 코드	주문 서비스
Target Interface	Client가 기대하는 인터페이스	pay(amount)
Adaptee	실제 연결해야 하는 기존 객체 또는 외부 API	외부 결제 API
Adapter	Target Interface에 맞게 Adaptee를 감싸는 객체	결제 어댑터

=> 외부 API나 기존 코드 자체를 억지로 바꾸는 것이 아니라,

중간에 어댑터를 두어, 서로 다른 사용 방식을 맞춰주는 것.

예시

EX]

주문로직 : 결제 객체가 apy(amount) 메서드를 제공한다고 가정

class OrderService:
    def __init__(self, payment):
        self.payment = payment

    def order(self, amount):
        return self.payment.pay(amount)

이 구조에서 OrderService는 구체적인 결제 방식이 무엇인지 알 필요가 없음.

그저 pay(amount)를 호출할 수 있으면 됨

class CardPayment:
    def pay(self, amount):
        return "카드 결제"

그런데 새로 연동해야 하는 외부 결제 API는 다른 형식을 사용한다고 할 때

class ExternalPaymentAPI:
    def request_payment(self, price):
        return f"{price}원 외부 결제 요청"

기능은 결제지만, 메서드 이름이 pay()가 아니라 request_payment()다.

파라미터 이름도 amount가 아니라 price

=> 이 상태에서는 OrderService에 바로 넣을 수 없음

external_payment = ExternalPaymentAPI()
order_service = OrderService(external_payment)

order_service.order(10000)

OrderService는 내부에서 self.payment.pay(amount)를 호출한다.
하지만 ExternalPaymentAPI에는 pay()가 없기 때문에 오류가 발생

이 문제를 해결하기 위해 어댑터로 인터페이스 변환

class ExternalPaymentAdapter:
    def __init__(self, external_payment):
        self.external_payment = external_payment

    def pay(self, amount):
        return self.external_payment.request_payment(price=amount)

=> 외부 API를 내부 코드가 기대하는 pay(amount) 형태로 바꿔줌

이제 OrderService는 수정하지 않아도 됨

external_payment = ExternalPaymentAPI()
payment = ExternalPaymentAdapter(external_payment)

order_service = OrderService(payment)
print(order_service.order(10000))

실행흐름)

OrderService.order(10000)
→ payment.pay(10000)
→ ExternalPaymentAdapter.pay(10000)
→ ExternalPaymentAPI.request_payment(price=10000)

구분	역할
OrderService	pay(amount)를 기대하는 기존 코드
ExternalPaymentAPI	request_payment(price)를 제공하는 외부 API
ExternalPaymentAdapter	pay(amount) 호출을 request_payment(price) 호출로 변환

장점

장점	설명
기존 코드 변경 최소화	기존 코드가 기대하는 인터페이스를 유지한 채 새로운 객체를 연결할 수 있다.
외부 구현과 내부 코드 분리	외부 API의 메서드 이름이나 응답 구조를 내부 코드가 직접 알 필요가 줄어든다.
호환성 확보	서로 다른 인터페이스를 가진 객체들을 같은 방식으로 사용할 수 있다.
변경 영향 축소	외부 API 형식이 바뀌어도 어댑터만 수정하면 되는 구조를 만들 수 있다.
일관된 사용 방식 제공	내부 코드에서는 여러 외부 객체를 동일한 인터페이스로 다룰 수 있다.

효과적인 상황

상황	이유
외부 API를 연동해야 하는 경우	외부 API 형식을 내부 코드에 맞게 감쌀 수 있다.
기존 코드를 크게 바꾸기 어려운 경우	기존 인터페이스를 유지하면서 새 구현을 연결할 수 있다.
서로 다른 라이브러리를 같은 방식으로 사용하고 싶은 경우	어댑터를 통해 일관된 사용 방식을 제공할 수 있다.
외부 변경 영향을 줄이고 싶은 경우	변경 지점을 어댑터로 제한할 수 있다.

주의점

어댑터는 기존 코드와 외부 코드 사이의 형식 차이를 흡수한다.

하지만 두 코드의 개념이나 책임이 근본적으로 다르다면 단순히 메서드 이름만 맞춘다고 좋은 구조가 되지는 않음.

ex)

외부 API의 request_payment()가 실제로는 결제 요청뿐 아니라 포인트 적립, 알림 발송, 정산 요청까지 함께 처리한다고 할 때

class ExternalPaymentAPI:
    def request_payment(self, price):
        process_payment(price)
        add_point(price)
        send_notification(price)
        create_settlement(price)

이 API를 단순히 pay(amount)로 감싸면 겉으로는 결제 인터페이스처럼 보임

class ExternalPaymentAdapter:
    def pay(self, amount):
        return self.external_payment.request_payment(price=amount)

하지만 내부적으로는 결제 외의 여러 작업까지 함께 실행된다.

이 경우 pay()라는 이름만 보고 사용하는 코드는 실제로 어떤 부작용이 발생하는지 알기 어려움.

주의점	설명
의미 차이를 숨기지 않기	메서드 이름만 맞추고 실제 동작 의미가 다르면 오해가 생길 수 있다.
어댑터 비대화	변환 로직이 너무 많아지면 어댑터가 복잡해질 수 있다.
오류 처리 방식 차이	외부 API의 예외, 실패 응답, 재시도 정책을 내부 기준에 맞게 정리해야 한다.
성능 비용	변환 과정이 많아지면 불필요한 처리 비용이 생길 수 있다.
책임 범위 확인	어댑터가 단순 변환을 넘어 비즈니스 로직까지 담당하지 않도록 주의해야 한다.

키워드	기준
self	코드가 작성된 클래스
static	실제 호출한 클래스