kth990303의 코딩 블로그

우리는 객체지향을 배우면서 추상화의 장점을 배운다. Java, Spring에서는 이 장점들을 적극적으로 활용할 수 있도록 굉장히 많은 지원을 해준다. 참고: https://kth990303.tistory.com/359 [JAVA] IoC, DI, DIP 친구와 얘기하던 중, Spring IoC, DIP 개념에 대한 얘기가 나왔다. 이 개념들은 구글링하면 워낙 잘 정리된 글들이 많아 별도로 작성하지 말까 고민도 했다. 하지만 해당 개념들은 객체지향에서 매우 kth990303.tistory.com 인터페이스, 추상클래스, DI 등의 장점에는 의존성이 적어진다는 점이 존재한다. 이러한 점 덕분에 구현을 하다가 if문이 굉장히 많이 나오거나, 추상화할 수 있게 리팩터링할만한 부분이 나온다면 우리는 추상화를 이용..

호호 스터디에서 Chapter 6: DI와 서비스 로케이터를 듣기 전에, 미리 책을 읽고 공부한 내용을 기록한 포스팅이다. DI와 서비스 로케이터 각 객체들을 사용하기 위해선 어떤 방법이 좋을까? 아무 생각없이 객체를 생성하고 의존하게 될 경우, Chapter 5에서 배웠던 DIP(의존 역전 원칙), OCP(개방 폐쇄 원칙), SRP(단일 책임 원칙) 등 SOLID 원칙을 어기게 되고, 변경에 유연하지 못한 코드가 만들어질 확률이 높다. 특히, 순환 의존이 발생할 경우, 요구사항이 수정되거나 변경될 경우 모든 객체의 코드를 수정해야 될 수도 있다. 이번 시간에는 DI(Dependency Injection), 서비스 로케이터를 이용한 객체 사용 방법에 대해 알아보도록 하겠다. Service Locator ..

호호 스터디에서 Chapter 5: 설계 원칙: SOLID를 듣기 전에, 미리 책을 읽고 공부한 내용을 기록한 포스팅이다. SOLID 원칙 어떻게 보면 귀에 딱지가 앉을 정도로 많이 들어서 너무 뻔하게 느껴질 수 있다. 하지만 막상 코드를 짤 때는 자신도 모르는 사이에 잘 지켜지지 않는 경우가 많다. 애초에, 객체의 값을 꺼내지 말고 메시지를 던지라는 것조차도 코드를 짜다보면 잘 안지켜지는 경우가 많은 것처럼 말이다. 이번 포스팅에서 SOLID 원칙을 살펴보긴 하겠지만, 제일 좋은 건 실전을 통한 많은 경험을 해보는 것인 듯하다 :) 단일 책임 원칙 (Single Responsibility Principle : SRP) 클래스는 단 한 개의 책임을 가져야 한다. 객체지향적인 코드를 짜기 위해 최대한 책임..