Dev

DI를 해야 클라이언트 코드 변경없이 기능을 확장할 수 있다. 인터페이스를 다 설계하고 구현체를 구현할때 장점 - 개발환경 설정 안하고 인터페이스 먼저 구현해도 개발 가능! - 인터페이스를 먼저 만들어놓으면 하부 구현기술 선택을 최대한 미룰수 있는 장점이있다 - 구체적으로 정해지지 않아도 간단한 인터페이스만들고 간단한 구현체 만들고 개발 가능 - 이런식으로 인터페이스를 먼저 설계하면 가능함 - 구현 기술이 바뀌더라도 나머지 코드를 바꿀 필요없어서 변경의 범위가 작고 유연함 인터페이스를 무분별하게 남발하면 추상화라는 비용 발생 - 추상화가 되버리면 개발 코드를 한번더 열어봐야함 이런 단점도 있음... - 그래서 장점이 단점을 넘어설때 채택해야함. - 이런걸 잘 고민하고 설계하는게 경험 많고 좋은 아키텍처들..

하나의 클래스는 하나의 책임만 가져야한다. 책임이라는게 모호함 실무에서 써보면 책임이 문맥과 상황에따라 좀 달라짐 중요한 판단 기준은 변경 - 변경했을때 파급이 적으면 단일 책임 원칙을 잘 설계한것 - 계층이 잘 나눠져있는건 단일 책임 원칙을 잘 지키려 하는것 - 범위도 잘 적절하게 조절해야함 이게 객체지향설계의 묘미 변경점이있을떄 하나의 클래스는 하나의 지점만 고치면 단일 책임 원칙을 잘 지키는것 인터페이스를 구현할 새로운 코드를 하나 더 만드는것은 기존 코드를 수정하는게 아니다. OCP = 다형성 그럼 어떻게 해결하나? - 객체 생성, 연관관계 맺어주는 별도의 조립, 설정자가 필요하다 그건 바로 스프링 리스코프 치환 원칙은 컴파일 단계를 말하는게 아니다. 기능적으로 보장을 해줘야하는것. 앞으로 가는 ..

객체 지향 프로그래밍 핵심은 객체들의 모임, 객체는 메시지를 주고받고 데이터를 처리할수있다. 유연하고 변경이 용이하다. 이게 바로 유연하고 변경이 용이한 객체지향의 가장 큰 방법 궁극의 유연함과 궁극의 변경이 용이한게 바로 = 다형성 진짜 다형성이란? 왜 다형성이 중요하냐면 역할 - 인터페이스 구현 - 실제 인터페이스 구현한 객체 자동차가 바껴도 운전자에게 영향을 안준다. 이게 중요하다. 유연하고 변경이 용이하단건 내가 자동차 역할을 K3에서 테슬라로 바꿔도 운전자는 운전 할 수 있다. 내가 테슬라를 산다해서 다른 운전면허를 따는게 아닌것처럼 자동차 끼리 바뀔땐 나에게 영향이없다 왜냐면 자동차 역할의 인터페이스를 따서 구현했기때문에 운전자는 자동차 역할에만 의존하고 있기 때문에 왜 이렇게 분리했을까? 진..

스프링이 왜 탄생했는지 시대적 배경을 알아보자 2000년 초반에 자바 진영의 표준 기술 중 최고가 EJB(Enterprise Java Beans)라는 기술이였다. 지금으로 따지면 스프링이랑 JPA 다 합쳐논 종합선물세트 같은거였다. 자바 진영 표준 기술이였기 때문에 도입이 많이 되어 있었다. 지옥불에 타고있는 사람 = 선배 개발자 EJB 는 어렵고 복잡하고 느렸다. 이론만 좋았다. EJB가 제공하는 인터페이스 다 구현하고 EJB에 의존적이게 개발해야 하는점 그러다보면 코드도 더럽고 어떻게 라이프사이클로 돌아가는지도 모르겠고, 그당시에 네트워크 가지고 통신해야하고 그래야되다보니 지옥이였다. 개발자는 단순하고 편해야 되는데 이건 복잡하고 어려운데 느렸다. 컨테이너 하나 띄우는데 시간 엄청 오래걸리고 오죽하면..

스프링 핵심 원리를 제대로 학습하려면 단순히 스프링이 제공하는 기능을 배우는게 아니라 객체지향의 원리와 그 원리를 스프링이 어떻게 지원하는지 객체지향과 스프링을 함께 풀어서 이해해야한다. 이 과정을 이해하고 나면 애플리케이션을 개발하고 설계하는 시야가 달라지고 애플리케이션 개발이 정말 즐거워진다. 단순히 스프링이 제공하는 기능을 사용하는건 어렵지않다. 스프링이 제공하는 핵심 가치와 원리를 제대로 이해하고 사용할때 큰 난관에 부딪힌다. IoC(제어의 역전), DI(의존관계 주입) 같은 알듯말듯한 용어부터 시작해서 소휘 SOLID, SRP 같은 좋은 객체지향 설계의 원칙들도 함께 이해를 해야 비로소 스프링의 핵심가치를 제대로 파악할수 있기 때문에 그렇다. 스프링의 진정한 핵심가치는 바로 객체 지향 프로그래밍..

AOP 적용 AOP: Aspect Oriented Programming 공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern) 분리 1. 시간 측정 AOP 등록 aop 패키지 생성, TimeTraceApp.java 파일 생성 package hello.hellospring.aop; import org.aspectj.lang.ProceedingJoinPoint; import org.aspectj.lang.annotation.Around; import org.aspectj.lang.annotation.Aspect; import org.springframework.stereotype.Component; @Aspect @Component public class Ti..

AOP가 필요한 상황 모든 메소드의 호출 시간을 측정하고 싶다면? 공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern) 회원 가입 시간, 회원 조회 시간을 측정하고 싶다면? 1. MemberService 회원 조회 시간 측정 추가 문제 - 회원가입, 회원 조회에 시간을 측정하는 기능은 핵심 관심 사항이 아니다. - 시간을 측정하는 로직은 공통 관심 사항이다. - 시간을 측정하는 로직과 핵심 비즈니스의 로직이 섞여서 유지보수가 어렵다. - 시간을 측정하는 로직을 별도의 공통 로직으로 만들기 매우 어렵다. - 시간을 측정하는 로직을 변경할 때 모든 로직을 찾아가면서 변경해야 한다. 해결방법 : https://icandoitprogramming.tistory...

스프링 데이터 JPA 스프링 부트와 JPA만 사용해도 개발 생산성이 정말 많이 증가하고, 개발해야할 코드도 확연히 줄어듭니다. 여기에 스프링 데이터 JPA를 사용하면, 기존의 한계를 넘어 마치 마법처럼, 리포지토리에 구현 클래스 없이 인터페이스 만으로 개발을 완료할 수 있습니다. 그리고 반복 개발해온 기본 CRUD 기능도 스프링 데이터 JPA가 모두 제공합니다. 스프링 부트와 JPA라는 기반 위에, 스프링 데이터 JPA라는 환상적인 프레임워크를 더하면 개발이 정말 즐거워집니다. 지금까지 조금이라도 단순하고 반복이라 생각했던 개발 코드들이 확연하게 줄어듭니다. 따라서 개발자는 핵심 비즈니스 로직을 개발하는데, 집중할 수 있습니다. 실무에서 관계형 데이터베이스를 사용한다면 스프링 데이터 JPA는 이제 선택이..

JPA JPA는 기존의 반복 코드는 물론이고,기본적인 SQL도 JPA가 직접 만들어서 실행해준다. JPA를 사용하면, SQL과 데이터 중심의 설계에서 객체 중심의 설계로 패러다임을 전환을 할 수 있다. JPA를 사용하면 개발 생산성을 크게 높일 수 있다. 1. build.gradle 파일에 JPA, h2 데이터베이스 관련 라이브러리 추가 build.gradle plugins { id 'org.springframework.boot' version '2.7.0' // 스타터 사이트에서 선택한 버전 id 'io.spring.dependency-management' version '1.0.11.RELEASE' id 'java' } group = 'hello' version = '0.0.1-SNAPSHOT' so..

스프링 JdbcTemplate 순수 Jdbc와 동일한 환경설정을 하면 된다. 스프링 JdbcTemplate과 MyBatis 같은 라이브러리는 JDBC API에서 본 반복 코드를 대부분 제거해준다. 하지만 SQL은 직접 작성해야 한다. 순수 Jdbc를 줄이고 줄이고 줄인 라이브러리라고 이해하면 된다. JdbcTemplateMemberRepository.java package hello.hellospring.repository; import hello.hellospring.domain.Member; import org.springframework.jdbc.core.JdbcTemplate; import org.springframework.jdbc.core.RowMapper; import org.springfr..