일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- open-in-view
- Batch
- @componentScan
- open session in view
- Request flow
- 생성자 주입
- 불변 객체
- mavenCentral
- Dispatcher Servlet
- 메서드 주입
- 빈
- 스프링 빈
- 참조 타입
- Spring Batch
- Open EntityManager In View
- @Configuration
- @Bean
- @FunctionalInterface
- OSIV
- 일괄처리
- 가변 객체
- spring boot
- 컴포넌트스캔
- 익명 함수
- 싱글 스레드
- 이펙티브 자바
- Handler Adepter
- Spring Framework
- 필드 주입
- View Resolver
- Today
- Total
보다 더 나은 내일의 나를 위해
제약있는 설계가 좋을까 나쁠까 본문
개요
코딩하고, 프로그램을 만들다 보면 어떤 기능을 만들 때 제약이 많은 것을 느낄 수 있습니다. 또한 왜 이 제약이 필요한지도 궁금한 상황이 나오곤 합니다. 이때 Spring Boot에서 제약은 다음과 같이 예를 들 수 있습니다.
- 컴포넌트들은 스프링 빈에 등록시켜 싱글톤으로 관리합니다.
- @Controller를 사용해서 url을 매핑합니다.
- @RestController에서는 기본적으로 json을 반환합니다.
- 외부 라이브러리 등은 gradle, maven 등을 통해 관리합니다.
이러한 제약은 왜 있는 걸까요? 이 외에도 @Before 어노테이션처럼 특정 기능 지원을 목적으로 로직에 제약을 거는 어노테이션들도 있습니다.
장점? 단점?
프로그래밍은 언어 자체에도 여러 가지 제약이 있습니다. 자바에서 '객체를 extends로 상속받으면 반드시 부모에 포함된 메서드를 구현해야 한다' 나 record 같은 클래스들이 이런 제약조건에 해당하죠. 하지만 프레임워크와 같은 자체적으로 지원하는 기능이 많은 것 보단 덜합니다. 만약 처음 자바를 배우거나 프레임워크의 사용법을 익힌다면 이러한 제약조건 때문에 어려웠던 적이 있었을 것입니다. 실제로 파이썬은 자바보다 제약조건이 비교적 적습니다. 그만큼 자유도가 높고, 프로그래밍을 처음 시작할 때 배우기도 쉽습니다. 이러한 점을 미루어 봤을 때 제약조건이 많다는 것은 단점으로 볼 수 있습니다.
하지만 Lombok의 @NotBlank와 같은 어노테이션을 따로 지원하는 이유가 무엇일까요? 분명 제약조건을 통해 얻을 수 있는 장점이 단점보다 더 크게 다가오기 때문일 것입니다. 그렇다면 제약조건으로 인한 장점은 어떤 것이 있을까요?
장점
프로그래밍 중 제약조건을 주는 것으로 얻을수있는 장점은 무엇이 있을까요?
우선 제약조건이 많다는 것은 이 제약조건을 통해서 해 주는 편리한 기능이 있다는 것입니다. 선풍기를 예로 들어봅시다. 저희가 더워 바람을 불게 하려면 어떻게 할 수 있을까요? 우선 손으로 바람을 일으킬 수 있을 것입니다. 아니면 주변에 잡히는 것을 통해 바람을 일으킬 수도 있죠. 하지만 힘들어 선풍기를 사용합니다. 선풍기는 반드시 프로펠러를 모터에 고정해 사용해야 합니다. 여기서 프로펠러를 모터에 고정해야 한다는 것은 제약조건으로 볼 수 있습니다. 선풍기를 손에 들고 직접 바람을 부치기는 매우 힘만 들고, 바람도 제대로 일으켜지지 않습니다. 반면에 모터에 프로펠러를 고정해 전기를 공급함으로 인해 저희는 힘을 들이지 않고도 시원한 바람을 맞을 수 있습니다. 이처럼 제약조건을 건다는 것은 사용자를 굳이 힘들게 하기 위함이 아닌 편리한 기능을 제공하기 위함입니다.
또한 제약조건을 명시해 줌으로써 여러 사람이 코드를 봤을 때 어떤 동작을 하는지 쉽게 알 수 있습니다. 아까 나왔던 Lombok의 @NotBlank어노테이션은 어떤 기능을 할 것 같나요? 모두 예상할 수 있듯 데이터에 null과 공백을 포함하지 않는 어노테이션입니다. 분명 비지니스 로직을 통해 코드로 검사할 수도 있었을 것입니다. 하지만 이 어노테이션을 적용함으로써 코드를 줄였습니다. 그뿐이 아니라 비지니스 로직까지 보지 않고 변수만 봐도 누구나 이 변수의 제약조건이 뭔지 이 어노테이션을 통해 바로 알 수 있을 것입니다.
그리고 개발자의 실수를 방지해 줄 수도 있습니다. 개발자도 사람이죠. 당연히 실수할 수 있습니다. 예를 들면 null과 공백 모두 포함하지 안 되지만 null인지만 검사한 경우 등이 있을 수 있죠. 하지만 @NotBlank를 통해 이러한 실수를 하지 않도록 할 수 있습니다.
결국 @NotBlank 하나 썼을 뿐인데 null과 공백을 포함하지 않는다는 제약조건을 쉽게 적용했고, 다른 사람에게 쉽게 이해시켰으며, 실수도 방지했습니다. 또한 이러한 제약조건을 줬으므로 다른 개발자가 이 변수를 사용할 때 변수에 대한 제약조건 검사를 굳이 안 해도 자동으로 될 것입니다.
결론
제약조건을 건다는 것은 이유가 있을 것입니다. 또한 그 제약조건을 주는 것으로 인해 얻는 장점이 단점보다 많을 것이란 거죠. 따라서 제약을 주며 설계한다는 것은 좋은 프로그래밍 방법이라 생각합니다.
'개발' 카테고리의 다른 글
클래스를 래핑 한다는 것 (0) | 2022.08.24 |
---|---|
오버라이딩, 오버로딩 그 차이 (2) | 2022.08.16 |
dependency 찾기 (0) | 2022.07.30 |