lingi04

앞서 봤던 것 처럼 Bean은 BeanDefinition 형태로 map에 저장된다. 그렇다면 Bean이 언제 객체화 되고 초기화가 이루어질까? public class AnnotationConfigApplicationContext extends GenericApplicationContext implements AnnotationConfigRegistry { private final AnnotatedBeanDefinitionReader reader; private final ClassPathBeanDefinitionScanner scanner; public AnnotationConfigApplicationContext() { this.reader = new AnnotatedBeanDefinitionReade..

ApplicationContext 부터 천천히 따라가며 Bean이 어떤 과정을 통해 등록 되는 지 알아보자. ApplicationContext BeanFactory를 상속 받은 HierarchicalBeanFatory, ListaableBeanFactory를 상속 받고 있고, 또한 다른 여러 인터페이스도 상속받고 있다. ApplicationContext는 Bean을 등록하고 가져오는데 쓰이는 것으로만 생각하고 있었으나, 소스를 열어보니 그렇지 않았다. 실제로 ApplicationContext의 설명을 보면 Application의 Component에 접근할 수 있는 BeanFactory 메서드 제공 - ListableBeanFactory 인터페이스 포괄적인 방식(Generic Fashion)으로 file ..

Bean @Bean 빈 객체를 참조할 때 사용 객체를 생성하고 알맞게 생성해야 한다. 개발자가 컨트롤 하기 불가능한 외부 라이브러리 들을 Bean 으로 등록하고 싶은 경우에 사용 예를 들어 ObjectMapper 의 경우 ObjectMapper 클래스에 @Component를 선언할 순 없으니 ObjectMapper의 인스턴스를 생성하는 매서드를 만들고, 해당 메소드에 @Bean을 선언하여 Bean으로 등록한다. bean? 스프링 IOC 컨테이너가 관리하는 객체. Controller, RestController @Controller 스프링 MVC 에서 컨트롤러로 사용한다. @RestController @Controller, @ResponseBody 을 합쳐놓은 어노테이션. @RestController pu..

앞서 적은 GroupA 하위에 ItemB, ItemC 말고도 ItemD라는 개념이 있는데 이번에 ItemD에 deploy 기능을 구현하게 됐다. ItemDClass에 deploy 기능을 위한 로직을 개발해야 하고 GroupAService 클래스 deployGroupA()메서드 안에 deploy item D 로직을 추가해야 했다. 앞선 시도가 성공적이진 않았지만 그 경험을 바탕으로 아쉬웠던 점을 보완해서 이번 개발에 적용해 보려 한다. 우선 앞선 시도에서 아쉬웠던 점을 먼저 짚고 넘어가보자 아쉬웠던점 코드 재사용 부분에서 기대했던 것 만큼 효과를 보기 어려웠다. GroupAService 안에 deploy item B, deploy item C 관련 메서드를 만들고 ItemBService, ItemCServ..

800줄 짜리 메서드가 있었다. 그래서 앞선 글에서 적은 내용들을 적용하기 딱 좋은 케이스라고 생각했다. 깨끗한 코드를 짜기 위한 연습이라 생각하며 리팩토링을 해보았다. 사전 설명 코드를 공개할 수가 없어서 말로 설명을 최대한 이해하기 쉽게 해봐야겠다. 회사에서 사용하는 개념인데 GroupA, ItemB, ItemC가 있고 GroupA는 ItemB, ItemC를 포함한다. 각 GroupAService, ItemBService, ItemCService엔 GroupA, ItemB, ItemC에 관한 동작들이 구현되어 있다. deployGroupA라는 메서드가 있다. 이 메서드에는 세부 기능 a, itemB, itemC, e를 위한 로직이 있었고 이 로직들은 if문과 for문 그리고 이유를 설명해주는 주석들이..

앞서 intro에서 refactoring 시 달성할 목표를 몇가지 적어보았다. 한 메서드는 인덴트를 하나만 else 예약어 사용을 자제하자 한 가지 메소드는 한 가지 일만 지역변수를 없애보자 말로만 하면 이해하기 어려우니 예시를 들어 알아보자. 예시는 유튜브에 박재성님의 우아한테크세미나 190425 TDD 리팩토링을 참고했다. 아래와 같은 코드를 가지고 목표를 어떻게 달성할지 알아보겠다. public class StringCalculator{ public static int splitAndSum(String text){ int result = 0; if(text == null || text.isEmpty()){ result == 0; }else{ String[] values == text.split(",..

1000줄이 넘는 메소드 그리고 복사 붙여넣기가 난무한 코드를 보며 나는 똥을 안싸는줄 착각하고 남탓만 하며 한숨 쉬던 지난날을 반성하며 '나 부터 달라지자' 라는 다짐과 함께 조금씩 리팩토링을 하며 경험한 것, 공부한 것들을 정리해가려 한다 리팩토링을 업무 로 한다? 리팩토링을 업무 로 한다는 것은 굉장히 힘든 일 인것 같다. 코드 상태에 대해, 테스트와 코드 리뷰에 대해 내 문제 제기를 몇번 해 보았다. 현재 상태를 모르는 사람은 없었다. 하지만 리팩토링을 할 시간을 얻어낼 수는 없었다. 우리 팀엔 하루가 멀다 하고 이슈가 들어왔으며, 수많은 고객사로 부터 갖가지 요구사항이 들어오고 있다. 이런 상황에서 인력을 빼서 겉으로는 티가 나지 않는 리팩토링 업무를 시킨다는 것은 내가 생각해도 굉장히 하기 어..

예전에 Immutable / Mutable 클래스에 대해서 들었을 땐 그냥 '아 그렇구나' 하고 넘어갔다. 둘 사이의 차이에 대해 깊게 생각해 본 적 없기 때문에 클래스를 만들 때 기본적으로 @Gettet, @Setter 어노테이션을 붙이고 시작을 했었다. 그러다 스터디 에서 리뷰 중 DTO 클래스는 Immutable한게 좋다는 피드백을 받았고, 최근 제출한 과제에서도 과도한 Setter는 좋지 않다는 피드백을 받아 Effective Java와 인터넷 에서 Immutable 클래스에 대해 좀 찾아보았다. Immutable 클래스란? Immutable 클래스는 객체를 생성 후 수정할 수 없는 클래스다. Immutable 클래스는 어떤 특징을 가지고 있고 어떻게 하면 만들 수 있는 지, 어디에..