[2025_11_06]객제지향 프로그래밍(OOP)와 SOLID원칙

TIL: 객체지향 프로그래밍(OOP)과 SOLID 원칙

OOP(Object-Oriented Programming)란?

데이터와 기능을 하나로 묶어서, 프로그램을 객체들의 상호작용으로 구성하는 프로그래밍 방식

왜 필요한가?

• 유닛(기능)이 많아질수록 중복 코드가 생기고 유지보수가 어려워짐
• 공통 기능을 재사용하고, 다양한 행동을 유연하게 확장하기 위해
• 게임의 각 요소(유닛, 스킬, UI 등)를 현실처럼 구조화해서 관리 가능

핵심 개념 4가지

1. 캡슐화: 객체 내부 상태는 숨기고, 기능만 노출
2. 상속: 공통 기능을 재사용
3. 다형성: 같은 이름을 다양한 행동으로 정의 (동일한 방식으로 호출)
4. 추상화: 복잡한 구조를 간단하게 표현

---

🎯 SOLID 원칙

목표: 객체지향 코드를 보기 쉽고, 유연하고, 유지보수하기 쉽게 만들자

S - 단일 책임 원칙 (Single Responsibility Principle)

• 모든 클래스는 하나의 책임만 가짐
• "하나"의 정의는 주관적...

O - 개방-폐쇄 원칙 (Open-Closed Principle)

• 확장에 대해 열려 있어야 함 (추가 기능 수정/확장 가능)
• 수정에 대해 닫혀 있어야 함 (기존 코드 수정 없이 기능 추가 가능)
• 즉, 기존 코드의 변경/삭제 없이 새로운 기능 추가 가능하도록

L - 리스코프 치환 원칙 (Liskov Substitution Principle)

• 자식 클래스를 만들 때 부모 기능을 제거하면 LSP 위배
• 추상화를 단순하게 유지
• 자식 클래스는 부모의 public 멤버 존재
• 상속보단 구성(Composition) 권장

I - 인터페이스 분리 원칙 (Interface Segregation Principle)

• 큰 덩어리의 인터페이스를 구체적이고 작은 단위로 분리
• 시스템의 내부 의존성을 약화하고 유연성 강화

D - 의존 역전 원칙 (Dependency Inversion Principle)

• 소프트웨어 모듈을 분리하는 특정 형식
• 상위 모듈은 하위 모듈의 것을 직접 가져오면 안 됨
• 둘 다 추상화에 의존해야 함

---

 실전 적용 가이드

좋은 소프트웨어란?

소프트웨어 품질의 시작은 개발자의 실수를 줄이는 환경 구축. 모두가 이해하기 쉬운 코드를 작성할 것.

언제 디커플링을 고려해야 하나?

• 협업 환경에서 잦은 변경으로 서로 작업을 못하는 상황이 발생할 때
• 바로 이때부터 SOLID 정신이 도움이 될 수 있음

핵심 포인트

• 모든 것에 SOLID를 적용하자는 사람은 조심
• SOLID 원칙을 "지키려고" 하지 말고, 느낌과 체감으로 적용
• 어차피 SOLID 원칙은 주관적이니까!

---

 오늘의 한 줄 정리

SOLID는 강제 규칙이 아니라 상황에 따라 유연하게 적용하는 가이드라인이다. 무리하게 모든 곳에 적용하려 하지 말고, 실제로 문제가 발생할 때 필요한 만큼만 적용하자.

또한 개인프로젝트가 시작되었는데 오늘은 하루종일 에셋 찾고 유니티 프로젝트 만들어서 폴더 정리하는데 다 써버렸다.
본격적인 구현은 아마 내일부터 시작하지 않을까 싶다.