[Unity] SOLID 원칙

SOLID 원칙

 

SOLID 원칙은 객체 지향 프로그래밍 및 설계에서 소프트웨어의 유지보수성과 확장성을 향상시키기 위해 제안된 다섯 가지 설계 원칙의 약어이다.

1. 단일 책임 원칙 (Single Responsibility Principle, SRP):
   • 정의: 클래스는 하나의 책임만 가져야 한다. 다시 말해, 클래스는 단 하나의 기능만 가져야 하며, 그 기능에 대해 완전히 책임져야 한다.
   • 예시: 사용자 정보를 처리하는 클래스는 사용자 데이터베이스와 관련된 기능만 포함해야 하며, 이메일 전송과 같은 기능은 별도의 클래스에 구현해야 한다.
2. 개방-폐쇄 원칙 (Open-Closed Principle, OCP):
   • 정의: 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하지만, 수정에는 닫혀 있어야 한다.
   • 예시: 새로운 기능을 추가할 때 기존 코드를 수정하지 않고 새로운 클래스를 추가하여 기존 시스템을 확장할 수 있어야 한다.
3. 리스코프 치환 원칙 (Liskov Substitution Principle, LSP):
   • 정의: 서브타입(자식 클래스)은 언제나 자신의 기반 타입(부모 클래스)으로 교체할 수 있어야 한다. 즉, 자식 클래스는 부모 클래스에서 정의한 기능을 모두 수행할 수 있어야 한다.
   • 예시: 부모 클래스 Bird가 fly 메소드를 가지고 있다면, 자식 클래스 Sparrow도 fly 메소드를 가져야 하며, 부모 클래스의 객체를 자식 클래스의 객체로 대체해도 프로그램이 정상적으로 작동해야 한다.
4. 인터페이스 분리 원칙 (Interface Segregation Principle, ISP):
   • 정의: 클라이언트는 자신이 사용하지 않는 메소드에 의존하지 않아야 한다. 즉, 하나의 일반적인 인터페이스보다는 여러 개의 구체적인 인터페이스를 사용하는 것이 좋다.
   • 예시: 큰 인터페이스 하나 대신에 여러 개의 작은 인터페이스를 만들어서 클라이언트가 필요한 기능만 사용할 수 있도록 해야 한다.
5. 의존성 역전 원칙 (Dependency Inversion Principle, DIP):
   • 정의: 고수준 모듈은 저수준 모듈에 의존해서는 안 된다. 둘 다 추상화에 의존해야 한다. 또한, 추상화는 구체적인 사항에 의존하지 않아야 한다.
   • 예시: 구체적인 클래스가 아닌 인터페이스나 추상 클래스를 사용하여 의존성을 설정함으로써, 구체적인 구현체를 변경하더라도 고수준 모듈에 영향을 미치지 않도록 한다.

 

SOLID 원칙을 적용하는 이유

• 유지보수성 향상: 코드의 가독성을 높이고, 버그를 수정하거나 새로운 기능을 추가하는 작업을 더 쉽게 만들어준다.
• 확장성 향상: 새로운 요구사항에 대응하여 시스템을 확장하는 작업이 더 쉬워진다.
• 재사용성 향상: 모듈화된 설계를 통해 코드를 재사용할 수 있는 기회를 증가시킨다.
• 테스트 용이성 증가: 각각의 모듈이 독립적으로 동작하도록 설계되어 있어 단위 테스트가 용이해진다.

 

오늘의 회고

튜터님이 강의를 해주시면서 나쁜 코드와 좋은 코드를 나누어서 보여주었다. 근데 아무리봐도 나쁜코드는 진짜 내가하는 코딩방식이랑 닮아서 저격을 당한 느낌이였다..

나쁜 코드만 말하고 끝났으면 어떤 방향으로 코드를 개선해야할지 몰랐겠지만 튜터님께서 좋은 코드 방법도 알려주셔서 객체지향적인 코드 작성법에 대해 감을 조금.. 잡은 것 같다.

내가 어제 사운드 부분에서 직접 드래그앤드롭해서 연결한 어떤 파일 자체가 유지가 안되고 Missing이 뜨고 None이 되어 다음에 조절하려고 할때는 안된다고 했는데 아마 직접 드래그앤드롭해서 설정한것 자체가 문제였던 것 같다. 오늘 배운 내용을 토대로 스크립트상에서 연결하는법으로 리팩토링 해봐야겠다.