목록코딩/다이어리 (7)
라라리라
생성자를 사용하는 방법 생성자 사용 | 가장 권장되는 방법이고, @Autowired 어노테이션을 생략할 수 있다. setter와 @Autowired 사용하는 방법 setter 사용 | 누군가 setter를 사용하면 오작동할 수 있다. 필드에 바로 사용 필드 직접 주입 | 나중에 테스트를 어렵게 만드는 요인이다. @Qualifier 어노테이션이란? - Bean을 사용하는 쪽과 등록하는 쪽 모두 @Qualifier 어노테이션을 사용할 수 있다. - Bean을 사용하는 쪽에서만 @Qualifier 어노테이션을 사용하면 , 연결할 Bean의 이름을 적어주어야 한다. - 양쪽 모두 사용하면, @Qualifier 끼리 연결된다. @Qualifier 끼리 직접 매칭할 경우, @Primary 어노테이션보다 우선권이 높다.
@Configuration과 @Bean 어노테이션 @Configuration - 클래스에 붙이는 어노테이션 -@Bean과 함께 사용 해주어야 한다. @Bean - 메소드에 붙이는 어노테이션 - 메소드에서 반환되는 객체를 Spring Bean에 등록한다. @Repository 어노테이션이 없으니 UserRepository 클래스는 더이상 스프링 빈이 아니고, 스프링 컨테이너는 UserService에게 더이상 필요한 의존성 주입을 할 수 없게된다. @Configuration과 @Bean을 통해 Repository를 스프링 Bean으로 등록해보자. 스프링 컨테이너가 작동할때, @Configuration 클래스들을 스캔하고 @Bean이 붙은 메서드의 반환값을 Spring Bean으로 등록하였기 때문에, @Rep..
스프링Bean을 사용하지 않고, 간단한 도서관리 API의 구조를 만든다고 생각해보자. 추가 요구사항을 구현하는 상상을 해보자.. 이제 Memory가 아닌, MySql과 같은 DB를 사용해야한다. 문제 | Repository의 역할에 관련된 것만 바꾸고 싶은데, BookService까지 바꿔야한다. MemoryRepository를 사용하는 Service가 5000개라고 생각해보자 .. Repository 변경을 위해서 5천번의 new MySqlRepository 선언을 해줘야한다! Java Interface를 활용하면?? 문제 | 발전 했지만 여전히 아쉽다.. 변경해야할 부분이 반으로 줄었지만, 여전히 Repository 변경을 위해서 Service를 수정해야한다. 스프링 컨테이너를 사용해보자 스프링 컨테..
클린코드, 어째서 중요할까? 옛날에 매우 인기 있는 앱을 개발한 회사가 있었다. 이 회사의 제품은 커다란 인기를 끌었고, 수많은 전문가들이 구매해 사용했다. 그런데 제품의 출시 주기가 점차 늘어지기 시작했다. 이전 버전에 있었던 버그가 다음 버전에 그대로 남아 있고, 프로그램이 느려졌으며, 동작하지 않는 일도 생기기 시작했다. 그렇게 점차 사용자들이 앱을 사용하지 않기 시작했고, 회사는 얼마 못가 망하게 되었다. 후일담으로 전해진 내부 사정은 이렇다. 다음 버전 출시가 바빠 코드를 마구 작성하였으며, 기능을 추가할수록 코드는 엉망이 되어갔고, 결국 감당이 불가한 수준에 이르렀다. 나쁜 코드 때문에 회사가 망한것이다.. 로버트 마틴의 저서 . 좋지 않은 코드들이 쌓이면 어떠한 일이 일어나는지 간단하지만 오..
Ctrl + Alt + O 사용하지 않는 Import 문을 삭제한다. Ctrl + W 적당한 영역을 알아서 선택해준다. Alt + Insert 패키지/클래스/getter/setter/생성자 등등을 새로만든다 Ctrl + Alt + L 필드를 정리한다 Ctrl + Shift + N 클래스/패키지를 검색해서 한번에 이동한다 Ctrl + E 최근 작업했던 클래스를 빠르게 이동한다. Ctrl + F11 부대지정 + (1,2,3,4,5...) Ctrl + (지정한 키) 즉시 매핑한곳으로 이동한다. Ctrl + Shift + 위아래 화살표 메소드 안에서 실행 -> 위아래 한줄이동 메소드 밖에서 실행 -> 메소드 단위로 위아래 이동
제약 조건(constraint) 데이터의 무결정을 지키기 위해, 데이터를 입력받을 때 실행되는 검사 규칙 종류 NOT NULL UNIQUE PRIMARY KEY FOREIGN KEY DEFAULT FORIEGN KEY 외래 키. 하나의 테이블을 다른 테이블에 의존하게 만든다. 참조되는 테이블의 필드는 반드시 UNIQUE 나 PRIMARY KEY 제약 조건이 설정되어 있어야 한다. CREATE 문으로 FOREIGN KEY 생성 CREATE TABLE ChildTable( ID INT, ParentID INT, FOREIGN KEY(ParentID) REFERENCES ParentTable(ID) ON UPDATE CASCADE ) // ChildTable의 ParentID는 ParentTable의 ID 필..
제약 조건(constraint) 데이터의 무결정을 지키기 위해, 데이터를 입력받을 때 실행되는 검사 규칙 종류 NOT NULL UNIQUE PRIMARY KEY FOREIGN KEY DEFAULT NOT NULL 해당 필드는 NULL값을 저장할 수 없게된다. CREATE 문으로 NOT NULL 생성 CREATE TABLE Test( ID INT NOT NULL, Name VARCHAR(30), inDate DATE, readCount INT ) //ID 는 NULL 값을 가질 수 없다. //다만, NULL 값을 저장하지 못하게 할 뿐이고, 생략하게 하지 못하는것은 아니다. ex) INSERT INTO Test (Name, inDate, readCount) VALUES ('홍길동', '2012-02-06'..