경직된 설계의 문제점
간단한 라우팅 로직 작성해보기
- 웹 애플리케이션에서 사용자의 요청 경로(Path)에 따라서 적절한 컨트롤러의 특정 메서드를 호출하는 라우팅 기능을 단순화 해서 구현해보자.
package ex02;
public class UserController {
public void login() {
System.out.println("login() 메서드 호출 됨");
}
public void join() {
System.out.println("join() 메서드 호출 됨");
}
}
package ex02;
import java.util.Scanner;
public class App {
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
// 사용자는 "/login", "/join" 문자열을 직접 입력 가능
String path = scanner.nextLine();
// 1. 개발자가 컨트롤러 객체를 직접 생성(new) 해야 한다.
UserController uc = new UserController();
// 2. 입력된 path 문자열 기준으로 분기 처리 수행을 해야한다.
if(path.equals("/login")) {
uc.login();
} else if(path.equals("/join")) {
uc.join();
}
}
}
현행 설계의 문제점 분석
코드는 입력값에 따라 정상적으로 동작한다. 하지만 이는 유지보수성과 확장성 측면에서 심각한 구조적 결함을 내포하고 있다.
가령, '로그아웃' 기능이 신규로 추가되는 상황을 가정해 보자.
개발자는 UserController.java에 logout() 메서드를 추가할 것이다.
그리고 App.java 파일에 분기 처리를 계속 추가 해야 된다.
높은 결합도 (High Coupling)
App.java는 UserController.java의 존재뿐만 아니라, login(), join() 등 구체적인 메서드의 이름까지 알아야 하는
강한 의존성을 가진다.
개방-폐쇄 원칙 (OCP) 위배 좋은 설계는 "확장에는 열려있고(Open), 수정에는 닫혀있어야(Closed)" 한다.
하지만 이 코드는 logout이라는 신규 기능 확장을 위해, App.java라는 기존 핵심 로직의 수정을 강제한다.
유지보수성 저하 애플리케이션의 기능이 100개로 늘어난다면, App.java의 if-else 구문은 100개가 되어야 한다.
이는 코드의 복잡도를 급격히 증가시키고 유지보수를 어렵게 만든다.
'JAVA' 카테고리의 다른 글
| 우당탕탕 소셜로그인 구현(for kakao) -- 진행중 (0) | 2025.11.11 |
|---|---|
| 리플렉션(동적 분석 도구 API) (0) | 2025.10.27 |
| 리플렉션 (어노테이션) (0) | 2025.10.27 |
| OCP (개방-폐쇄 원칙) (0) | 2025.10.15 |
| SRP (Single Responsibility Principle) - 단일 책임 원칙 (0) | 2025.10.15 |