SPRING 프레임워크를 통해 객체지향 설계의 원칙 중 SOLID 원칙이 무엇이며, 어떻게 적용되는지 알아보겠습니다. 1. SRP (Single Responsibility Principle) - 단일 책임 원칙 각 클래스는 하나의 단일한 책임만 가져야 한다. Spring에서는 Controller, Service, Repository 등으로 역할을 명확히 나누어 각각의 클래스가 특정 기능 또는 관심사에만 집중하도록 합니다. SRP를 잘 준수했는지 알 수 있는 기준은 변경입니다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따랐다고 할 수 있습니다. // UserController 클래스는 사용자 관리와 관련된 HTTP 요청을 처리하는 책임만을 가져야 합니다. @Controller public ..
스프링을 이용해 파일 업로드하는 방법에 대해 정리하고자 합니다. 스프링 코드와 html 코드를 작성하면서 설명하겠습니다. Spring Code - 파일 업로드 처리 @Value("${file.path}") private String fileRealPath; public void imageUpload(ImageRequestDTO.ImageUploadDTO request, Long userId) throws IOException{ UUID uuid = UUID.randomUUID(); MultipartFile file = request.getFile(); String uuidFilename = uuid + "_" + file.getOriginalFilename(); Path filePath = Paths.g..
스프링 빈을 조회할 때 메서드 이름 없이 타입으로만 조회하게 되면 스프링 빈이 2개 이상 조회될 수 있는 문제가 있습니다. @Autowired는 객체의 타입(Type)으로 조회합니다. @Autowired private DiscountPolicy discountPolicy // 위의 코드는 // ac.getBean(DiscountPolicy)와 유사하게 동작합니다 @Component public class FixDiscountPolicy implements DiscountPolicy {} // 두 스프링 빈 모두 타입이 DiscountPolicy @Component public class RateDiscountPolicy implements DiscountPolicy {} ✔ 타입으로만 조회하게 되면 스프..
스프링 없는 순수한 DI Container ✔ 스프링을 사용하지 않는 DI 컨테이너인 AppConfig는 사용자가 요청을 할 때마다 객체를 계속해서 새로 생성합니다. -> 요청할 때마다 객체를 계속해서 생성하므로 메모리 낭비가 심합니다. 해결방안 ✔ 해당 객체가 딱 1개만 생성되고 (Singleton), 공유하도록 설계하여 반복 생성되는 구조를 피하는 것입니다. public class SingletonTest { @Test @DisplayName("스프링 없는 순수한 DI 컨테이너") void pureContainer(){ AppConfig appConfig = new AppConfig(); // 1. 조회: 호출할 때 마다 객체를 생성 MemberService memberService1 = appCon..