이번주에는 이전 과정에서 나왔던 자동차 경주 문제가 나왔습니다.
이 문제도 스터디에서 한 번 풀어봤던 적이 있었기 때문에 문제에 대한 두려움은 없었지만 단순 구현이 어려운게 아님을 알기에 힘들었던 문제였습니다.
이번주차에서는 1주차 스터디에서 스터디원분들의 피드백을 적용시켜보자는 목표도 있었기때문에 더 신경써서 작업했던 것 같습니다 (그래도 갈길은 멉니다)

이번 포스트에서도 제가 학습한 내용에 대해서 적어보려고 합니다.
다만, 이번주차에 학습한 내용을 이번주 문제에 모두 적용하지는 못했습니다. 아직 적용하기에는 학습이 부족한 것 같아서요 🥲🥲

SOLID 원칙이란, 객체 지향 프로그래밍의 5가지 핵심 원칙을 말합니다.

• 단일 책임의 원칙 (SRP - Single Responsibility Principle)
• 개방폐쇄의 원칙 (OCP - Open Close Principle)
• 리스코브 치환의 원칙 (LSP - The Liskov Substitution Principle)
• 인터페이스 분리의 법칙 (ISP - Interface Segregation Principle)
• 의존성역전의 법칙 (DIP - Dependency Inversion Principle)

이렇게만 두고보면 어떤 내용을 설명하는지 정확히 알기 힘드니 하나하나 살펴봅시다.

단일 책임의 원칙 (SRP)

하나의 모듈이 하나의 책임을 가져야 한다.

단일 책임의 원칙은 가장 많이 알고 있을 내용이라고 생각합니다. 하지만 그만큼 잘못 알고 있는 사람의 비율도 높다고 생각합니다.
단일 책임의 원칙은 단순히 하나의 모듈이 하나의 책임을 가져야 한다 라고 적혀있지만 사실 본질적인 내용은 모듈이 변경되는 이유가 한 가지여야 한다로 받아들여야 합니다.

어떤 모듈이 여러가지 책임이 있다면 해당 모듈이 변경되는 이유도 여러가지 이유일 것 입니다. 이렇게된다면 변경되는 이유를 파악하기 힘들 것 입니다.
하지만, 모듈이 한 가지 책임만 있다면 특정 원인으로부터 변경을 특정할 수 있으므로 클래스를 변경해야하는 이유와 시점이 명확해집니다.

개방 폐쇄의 원칙 (OCP)

확장에는 열려있고 수정에 대해서는 닫혀있어야 한다.

확장에는 열려있고 수정에 대해서는 닫혀있어야 한다는 내용은 다음과 같이 해석할 수 있습니다.

• 요구사항이 변경될 때 새로운 동작을 추가하여 애플리케이션의 기능을 확장할 수 있다 (확장에 열려있다)
• 기존의 코드를 수정하지 않고 애플리케이션의 동작을 추가하거나 변경할 수 있다 (수정에 닫혀있다)

그리고 이러한 조건을 만족하면서 로직을 작성하기 위해서는 필연적으로 추상화 단계 가 필요합니다.
추상화란 핵심적인 부분만 남기고 불필요한 부분을 제거함으로써 변하지 않는 부분만 남기는 일련의 과정을 말합니다.

OCP의 본질은 결국 추상화이며, 이는 런타임 의존성과 컴파일타임 의존성에 대한 이야기입니다.

런타임 의존성과 컴파일타임 의존성이란?

• 런타임 의존성 : 애플리케이션 실행 시점에서의 객체들의 관계
• 컴파일타임 의존성 : 코드에 표현된 클래스간의 관계

객체가 알아야하는 지식이 많으면 결합도가 높아지며, 결합도가 높아질수록 OCP를 따르는 구조를 설계하기 어려워집니다.
이를 위해 추상화를 사용하여 변하는 것들은 숨기고 변하지 않는 것들에만 의존함으로써 기존의 코드를 수정하지 않고 기능을 확장해나갈 수 있습니다.

인터페이스 분리의 원칙 (ISP)

목적과 관심이 다른 클라이언트가 있다면 인터페이스를 분리한다.

이 말은, 결국 클라이언트의 목적과 용도에 적합한 인터페이스만을 제공해야함을 의미합니다. ISP를 준수함으로써 모든 클라이언트가 자신의 역할에 맞는 인터페이스만을 접근하여 불필요한 간섭을 최소화 할 수 있습니다.
이는 OCP와 마찬가지로 기존 클라이언트에 영향을 주지 않고 유연하게 객체의 기능을 확장 / 수정할 수 있도록 합니다.

리스코브 치환의 원칙 (LSP)

하위 타입은 상위 타입을 대체할 수 있어야 한다.

한 객체를 사용하는 클라이언트는 상위 타입이 하위 타입으로 바뀌어도, 상위 클래스의 퍼블릭 인터페이스를 통해 서브 클래스를 사용할 수 있어야 한다는 것 입니다.
리스코브 치환의 원칙은 자식 클래스가 부모 클래스를 대체하기 위해서는 부모 클래스에 대한 클라이언트의 가정을 준수해야함을 강조합니다.

의존성 역전의 법칙 (DIP)

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안되며, 저수준 모듈이 고수준 모듈에 의존해야한다.

객체 지향 프로그래밍에서는 객체들 사이에 메시지를 주고받기위해 다양한 의존관계가 생기는데, 의존성 역전의 법칙은 올바를 의존 관계를 위한 원칙입니다.
여기에서 말하는 고수준 모듈과 저수준 모듈의 정의는 다음과 같습니다.

• 고수준 모듈 : 입력과 출력으로부터 먼 비즈니스와 관련된 추상화된 모듈
• 저수준 모듈 : 입력과 출력으로부터 가까운 구현 모듈

결국 의존성 역전의 법칙이 말하고자 하는건 비즈니스와 관련된 부분이 세부 사항에는 의존하지 않는 설계원칙을 의미합니다.

이번 미션부터는 기존에 사용하던 단순 MVC 디자인 패턴에서 더 나아가 서비스 레이어를 추가해보았습니다.
서비스 레이어란 비즈니스 도메인에 대한 model의 기능을 처리하는 레이어입니다.

더 디테일하게 기능을 살펴보면 다음과 같습니다.

• 클래스간의 관계를 정리합니다.
• 트랜젝션이 일어나는 시작점에 해당합니다.
• model의 기능을 처리하고 영속성을 소유한 repository의 기능을 트리거한다.
• controller와 persistence 레이어를 연결한다.
• 컨트롤러는 서비스 레이어를 호출한다.

왜 서비스 레이어의 적용을 고민했는가..? 에 대해서 말해보자면, 로직을 작성하면서 해당 기능을 어디에 부여해야하는지 고민을 많이 했었습니다.
그러던 도중 스터디원분들의 서비스 레이어 소개로 인해 찾아보았는데 지금까지 고민하던 역할 배분 문제의 실마리를 얻을 수 있었습니다.

• [OOP] 객체지향 프로그래밍의 5가지 설계 원칙, 실무 코드로 살펴보는 SOLID
• Domain Model에 대해서]
• [개발상식] MVC 패턴이란? (Model-View-Controller)
• 완벽하게 이해하는 SRP (단일 책임 원칙)

• 자동차 경주 게임 PR