장선생의 개발학과

C# 기초부터 고급까지 Chapter 2.1.5. DIP (Dependency Inversion Principle) – 의존성 역전 원칙

📚 Chapter 2.1.5. DIP (Dependency Inversion Principle) – 의존성 역전 원칙✅ DIP란?"고수준 모듈은 저수준 모듈에 의존하면 안 된다.둘 다 추상(인터페이스, 추상 클래스)에 의존해야 한다."쉽게 말하면,구체적인 구현체에 직접 매달리지 말고인터페이스(추상)에 의존하라는 거다!📚 왜 DIP가 중요한가?문제 상황결과코드가 구체 구현에 묶여 있음기능 교체/확장 시 코드 수정 폭발테스트 힘듦Mock 객체로 대체 불가능확장성 제로새로운 기능 추가 때마다 대공사✅ DIP를 지키면 →기능 변경 자유로워지고테스트 더 쉬워지고코드 재사용성 쭉 올라간다!🛠️ 기본 나쁜 예제: DIP 위반public class EmailSender{ public void Send(str..

C# 기초부터 고급까지 Chapter 2.1.4. ISP (Interface Segregation Principle) – 인터페이스 분리 원칙

📚 Chapter 2.1.4. ISP (Interface Segregation Principle) – 인터페이스 분리 원칙✅ ISP란?"하나의 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않게 해야 한다."쉽게 말하면,"인터페이스는 작게 작게 쪼개라!""필요한 기능만 가진 인터페이스만 제공해라!"📚 왜 ISP가 중요한가?문제 상황결과거대한 인터페이스필요 없는 메서드도 강제로 구현해야 함코드 복잡성 증가무쓸모 코드들이 시스템을 오염시킴유지보수 난이도 상승하나 바꾸면 연쇄 수정 지옥✅ ISP를 지키면 →필요한 기능만 깔끔하게 다루고,코드 수정 범위 최소화된다!🛠️ 기본 나쁜 예제: ISP 위반덩치 큰 인터페이스public interface IWorker{ void Work(); voi..

C# 기초부터 고급까지 Chapter 2.1.3. LSP (Liskov Substitution Principle) – 리스코프 치환 원칙

📚 Chapter 2.1.3. LSP (Liskov Substitution Principle) – 리스코프 치환 원칙✅ LSP란?"자식 클래스는 부모 클래스를 대체할 수 있어야 한다." (Subtypes must be substitutable for their base types)부모 클래스를 사용하는 코드가자식 클래스로 바꿔 끼웠을 때도아무 문제 없이 동작해야 한다!📚 왜 LSP가 중요한가?문제 상황결과자식 클래스가 부모 규칙을 깨뜨림프로그램이 비정상 동작함예상치 못한 에러 발생다형성(polymorphism)이 깨짐유지보수 지옥코드 수정할 때 어디 터질지 모름✅ LSP를 지키면 → 다형성이 제대로 작동하고, 시스템 안정성 쭉 상승!🛠️ 나쁜 예제: LSP 위반부모 클래스public class Bi..

C# 기초부터 고급까지 Chapter 2.1.2. OCP (Open-Closed Principle) – 개방-폐쇄 원칙

📚 Chapter 2.1.2: OCP (Open-Closed Principle) – 개방-폐쇄 원칙✅ OCP란?확장에는 열려 있고, 수정에는 닫혀야 한다.즉,새로운 기능 추가할 때는 기존 코드를 수정하지 말고코드를 확장해서 기능을 늘려라!📚 왜 OCP가 중요한가?문제 상황결과기존 코드 수정다른 기능에 영향 줄 가능성 있음 (Side Effect 발생)버그 발생옛날 기능까지 깨질 위험테스트 실패기존 테스트까지 다 망가질 수 있음✅ OCP를 지키면새로운 요구사항이 와도옛날 코드는 건드리지 않고확장만 하면 되니까 안전하다!🛠️ 나쁜 예제: OCP 위반public class PaymentService{ public void ProcessPayment(string method) { i..

C# 기초부터 고급까지 Chapter 2.1.1. SRP (Single Responsibility Principle) – 단일 책임 원칙

📚 Chapter 2.1.1: SRP (Single Responsibility Principle) – 단일 책임 원칙✅ SRP란?"하나의 클래스(또는 모듈)는 하나의 책임만 가져야 한다."👉 변경 이유(Reason to change)가 단 하나여야 한다는 거다!🔥 쉽게 풀자"A 클래스는 ~도 하고 ~도 하고 ~도 한다" → ❌"A 클래스는 단 하나의 일만!" → ⭕ (깔끔하고 유지보수 쉽다)📚 왜 SRP가 중요한가?문제 상황결과여러 책임을 가지면한 책임 변경 시, 다른 책임도 영향을 받음클래스 크기 폭발읽기, 수정, 테스트가 어려워짐코드 중복, 버그 증가한 번에 여러 기능이 꼬임✅ 단일 책임 원칙을 지키면 →수정 시 영향 최소화테스트 쉽고 빠름코드 읽기가 쉬움🛠️ 기본 예제: 나쁜 설계publi..