SOLID 원칙 실전
다섯 가지 SOLID 원칙을 실제 PHP 클래스에 적용합니다.
SOLID 원칙 실전은(는) CoddyKit의 무료 PHP Academy 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 PHP Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. PHP Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
SOLID를 사용하는 이유
SOLID는 객체 지향 PHP를 유연하고 테스트 가능하며 노후화에 강하게 유지하는 다섯 가지 설계 원칙입니다. 맹목적으로 따라야 하는 규칙이 아니라 결합도를 낮추고 책임을 명확히 하는 경험적 지침입니다. 이 lesson에서는 실제로 배포할 PHP 클래스에 각 원칙을 적용합니다.
- S단일 책임
- O개방/폐쇄
- L리스코프 치환
- I인터페이스 분리
- D의존성 역전
단일 책임
클래스는 변경되어야 할 이유가 하나여야 합니다. 보고서를 만들고 HTML로 서식을 지정하며 이메일로 보내는 클래스에는 변경 이유가 세 가지 있습니다. 영속성, 서식 지정 및 전송을 분리하십시오.
아래에서 Invoice는 데이터만 모델링하고, 렌더링과 저장은 다른 곳에서 담당합니다.
<?php
final class Invoice {
public function __construct(
public readonly string $number,
public readonly int $cents
) {}
public function total(): float { return $this->cents / 100; }
}
final class InvoiceRenderer {
public function toText(Invoice $i): string {
return sprintf('Invoice %s: $%.2f', $i->number, $i->total());
}
}
$i = new Invoice('INV-1', 12500);
echo (new InvoiceRenderer())->toText($i), PHP_EOL;
SRP: 문제 징후 찾기
대표적인 SRP 위반은 이름에 및이 들어간 클래스나 모든 일을 처리하는 Manager입니다. 서로 관련 없는 비즈니스 이유로 변경되는 메서드를 주의하십시오. 세금 규칙 변경과 PDF 레이아웃 변경이 모두 같은 클래스를 수정하게 된다면 그 클래스는 책임이 너무 많다는 뜻입니다.
개방/폐쇄 원칙
소프트웨어 요소는 확장에는 열려 있고 수정에는 닫혀 있어야 합니다. 새로운 Discount 유형을 추가한다고 해서 거대한 switch를 수정해야 해서는 안 됩니다. 다형성을 사용하십시오. 각 규칙을 공통 인터페이스를 구현하는 독립적인 클래스로 만드십시오.
<?php
interface Discount { public function apply(float $total): float; }
final class PercentOff implements Discount {
public function __construct(private float $pct) {}
public function apply(float $t): float { return $t * (1 - $this->pct / 100); }
}
final class FlatOff implements Discount {
public function __construct(private float $amount) {}
public function apply(float $t): float { return max(0, $t - $this->amount); }
}
function checkout(float $total, Discount ...$discounts): float {
foreach ($discounts as $d) { $total = $d->apply($total); }
return $total;
}
echo checkout(100, new PercentOff(10), new FlatOff(5)), PHP_EOL; // 85
리스코프 치환
하위 유형은 호출자에게 예상 밖의 동작을 일으키지 않으면서 기본 유형이 필요한 모든 곳에서 사용할 수 있어야 합니다. 잘 알려진 예로 Square extends Rectangle은 너비를 설정할 때 높이가 조용히 변경되어서는 안 되므로 LSP를 위반합니다. 공통 Shape 인터페이스 뒤에서 이들을 별도의 유형으로 모델링하는 편이 좋습니다.
<?php
interface Shape { public function area(): float; }
final class Rectangle implements Shape {
public function __construct(private float $w, private float $h) {}
public function area(): float { return $this->w * $this->h; }
}
final class Square implements Shape {
public function __construct(private float $side) {}
public function area(): float { return $this->side ** 2; }
}
$shapes = [new Rectangle(2, 3), new Square(4)];
foreach ($shapes as $s) { echo $s->area(), PHP_EOL; }
LSP와 계약
LSP는 메서드 계약도 제한합니다. 하위 유형은 사전 조건을 완화하고 사후 조건을 강화할 수 있지만, 그 반대는 허용되지 않습니다. 기본 유형이 선언한 적 없는 새로운 예외 유형을 던지거나, 기본 유형이 객체를 보장하는 곳에서 null을 반환하면 치환 가능성을 위반합니다. PHP의 공변 반환 유형과 반공변 매개변수 유형은 이 규칙의 일부를 유형 수준에서 강제합니다.
인터페이스 분리
클라이언트는 사용하지 않는 메서드에 의존해서는 안 됩니다. work()와 eat()이 있는 비대한 Worker 인터페이스는 RobotWorker가 eat()을 스텁으로 구현하도록 강제합니다. 역할별 인터페이스로 나누어 각 구현체가 실제로 수행하는 일만 약속하도록 하십시오.
<?php
interface Workable { public function work(): string; }
interface Feedable { public function eat(): string; }
final class Human implements Workable, Feedable {
public function work(): string { return 'coding'; }
public function eat(): string { return 'lunch'; }
}
final class Robot implements Workable {
public function work(): string { return 'welding'; }
}
foreach ([new Human(), new Robot()] as $w) { echo $w->work(), PHP_EOL; }
의존성 역전
높은 수준의 정책은 구체적인 세부 사항이 아니라 추상화에 의존해야 합니다. 하드코딩된 클래스를 주입하지 말고 인터페이스를 주입하십시오. 이렇게 하면 소비자 코드를 수정하지 않고도 테스트에서는 실제 메일러를 가짜 메일러로, 운영 환경에서는 다른 공급업체의 메일러로 바꿀 수 있습니다.
<?php
interface Mailer { public function send(string $to, string $body): void; }
final class SmtpMailer implements Mailer {
public function send(string $to, string $body): void {
echo "SMTP -> $to: $body" . PHP_EOL;
}
}
final class SignupService {
public function __construct(private Mailer $mailer) {}
public function register(string $email): void {
$this->mailer->send($email, 'Welcome!');
}
}
(new SignupService(new SmtpMailer()))->register('a@b.com');
DIP와 컨테이너
의존성 역전은 원칙이고, 의존성 주입은 이를 충족하는 한 가지 기법입니다. DI 컨테이너(PSR-11)는 구성 루트에서 구체적인 SmtpMailer를 Mailer 추상화에 연결합니다. 소비자는 절대 new SmtpMailer()라고 작성하지 않으므로 소스 코드의 의존성 방향은 세부 사항이 아니라 추상화를 향합니다.
<?php
// Composition root wiring (pseudo-container)
$bindings = [
Mailer::class => fn() => new SmtpMailer(),
];
$resolve = fn(string $id) => $bindings[$id]();
$service = new SignupService($resolve(Mailer::class));
$service->register('user@example.com');
SOLID 함께 적용하기
원칙들은 서로를 강화합니다. ISP는 인터페이스를 작게 유지하여 DIP 주입을 집중적으로 만들고, OCP는 LSP가 안전하게 유지하는 다형성에 의존하며, SRP는 이 모든 것을 가능하게 하는 작은 클래스를 제공합니다. 내부 응집도는 높게, 상호 결합도는 느슨하게 유지하는 것을 목표로 하십시오.
- 한 번만 사용하는 클래스를 과도하게 추상화하지 마십시오.
- 두 번째 구현이나 테스트 대역이 등장할 때 인터페이스를 도입하십시오.
실용주의
SOLID는 목적이 아니라 수단입니다. 구현이 하나뿐인 인터페이스를 너무 일찍 만들면 얻는 이점 없이 간접 참조만 추가됩니다(‘추측성 일반화’). 실제 변경이 발생했거나 곧 발생할 것이 분명할 때 원칙을 적용하십시오. 테스트가 있으면 SOLID를 향한 리팩터링은 저렴하지만, 첫날부터 맹목적으로 SOLID를 적용하는 리팩터링은 낭비입니다.
빠른 확인
Square/Rectangle 상속 문제는 어떤 원칙을 위반합니까?
복습
실제 PHP에 SOLID의 다섯 가지 원칙을 모두 적용했습니다.
- SRP: 클래스마다 변경 이유는 하나입니다.
- OCP: 분기문을 수정하지 말고 새로운 다형성 클래스로 확장합니다.
- LSP: 하위 유형은 기본 유형의 계약을 준수합니다.
- ISP: 비대한 인터페이스 대신 작은 역할별 인터페이스를 사용합니다.
- DIP: 추상화에 의존하고 구성 루트에서 세부 사항을 주입합니다.
형식적인 절차가 아니라 리팩터링의 방향을 잡는 지침으로 사용하십시오.
자주 묻는 질문
“SOLID 원칙 실전” 강의는 무료인가요?
네 — “SOLID 원칙 실전” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 PHP Academy 강의 전체를 잠금 해제할 수 있습니다. PHP Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
“SOLID 원칙 실전”에서 뭘 배우나요?
다섯 가지 SOLID 원칙을 실제 PHP 클래스에 적용합니다. 브라우저에서 직접 실행하는 실습 코드로 PHP Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
PHP Academy을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 PHP Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.
“SOLID 원칙 실전” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 PHP Academy 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 PHP Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.