본문 바로가기

전체 글

[Spring] xml Spring IOC XML을 사용하는 이유 : DI구성이 자바코드를 수정하고 클래스를 다시 컴파일 하는 과정이 귀찮은 과정이므로. 컴파일과 같은 별도의 빌드작업이 없고 빠르게 변경사항을 반영할 수 있다. 2. Beans의 네임스페이스 : 스프링은 DI를 위한 태그들 , 을 사용할 수 있는 법을 제공하기 때문에 스키마 파일에 정의되어 있고, 독립적인 네임스페이스를 사용해야 하므로 네임스페이스로 선언해 주어야 한다.(DTD보단 스키마를 사용하는 편이 바람직함. 독립적인 네임스페이스를 위함) 2. : 스프링 어플리케이션 컨텍스트는 XML:에 담긴 DI정보를 활용할 수 있으며, 해당 루트 엘리먼트를 사용한다. 자바의 @Configuration 과 동일하다. 7. : @Bean은 AnnotationConfigApplicationCo.. 더보기
[spring] 수정자메소드(setter) DI realConnectionMaker DConnection을 그대로 두고 카운터만 늘리기 위한 클래스 생성자가 아닌 수정자 메소드 DI를 통해 커넥션 객체를 주입하는 방식 14. AnnotationConfigApplicationContext : ApplicationContext로 해야함(앞쪽) 15, 28. getBean을 통해 SpringContext(@Configuration) 의 메서드명을 검색한다. 더보기
[spring] spring ioc_DI 1.Commons-logging : Spring-context가 사용 2. Mysql-connector : Mysql JDBC 3.Spring-aop : 스프링 기능 자체의 aop, Spring ProxyFactoryBean 4. Spring-bean : 스프링 코어와 함께 의존성 주입 제공 (Core Container) 5. Spring-context : 스프링 코어, BeanFactory를 확장한 어플리케이션 컨텍스트 구현, 리소스 로드 및 국제화 지원(Core Container) 6. Spring-core : 다른 스프링 모듈이 사용하는 유틸리티(Core Container) 7. Spring-expression : EL 확장 Bean속성(배열, 컬렉션 포함).(Core Container) Inter.. 더보기
[java] IOC_오브젝트팩토리 다양한 회사의 커넥션 객체를 받기 위함 : 다형성(Interface) 지금은 D사의 Connection클래스를 생성하였지만 추후 N사의 커넥션 객체를 만들 수 있다. 회사 및 여러 DBMS 클래스를 생성하여 유연해질 수 있다. 인터페이스를 통해 인자로 객체를 전달받음. DAO는 어떤 커넥션 객체가 올지 모름. 투명성 팩토리 : 객체생성 방법을 결정하고 그렇게 만들어진 오브젝트를 돌려줌(객체 공장) N사와 D사에 DaoFactory 소스를 제공하여. 적절하게 변경된 클래스를 바라보도록 수정하도록 가이드해줌 제어의 역전(Inversion Of Control) : 프로그램에서 오브젝트를 생성하는 것이 아닌 사용자쪽에서 오브젝트를 생성해 제어할 수 있는 구조 더보기
[java] 추상화 인터페이스(클래스분리 리팩토링) 추상화 : 공통적인 성격을 뽑아내어 이를 따로 분리하는 작업 > 인터페이스 도입 : 자신이 구현한 클래스에 대한 구체적인 정보는 모두 감춤 UserDao 입장에서 ConnectionMaker 인터페이스 타입의 오브젝트라면 어떤 클래스로 만들어 졌던지 관계없이 makeConnection() 메소드를 호출하기만 하면 Connection 타입의 오브젝트를 만들어서 돌려줄 것이라고 기대할 수 있다. 인터페이스로 분류했지만 위처럼 고객에게 자유로운 DB커넥션 확장 기능을 가진 UserDao를 제공할 수 없다. 하지만 위의 기능을 클라이언트에게 떠넘기면? 이렇게 인터페이스를 도입하고 클라이언트의 도움을 받으면 UserDao 코드는 아무런 영향을 받지 않는다.(유연하다)(다양한 회사의 커넥션 객체를 받을 수 있다. .. 더보기
[java] 클래스분리(상속을 통한 확장 리팩토링) VO > 자바빈(JavaBean) : 파라미터가 없는 디폴트 생성자를 갖고 있어야한다. 툴이나 프레임워크에서 리플렉션을 이용해 오브젝트를 생성하는데 필요하기 때문 1. 리플렉션 : 객체를 통해 클래스의 정보를 분석해내는 프로그램 기법(class.forName을 통해 메모리에 로딩된 객체의 메서드 생성자 등을 알아내서 사용가능) 2. 프레임워크 : 흐름을 주도한다. 프레임워크 위에 개발한 클래스를 등록하고 프레임워크가 흐름을 주도함 3. Property : id, name, password(자바빈의 속성) 프로퍼티는 set/get 메서드를 이용해 수정 또는 조회 가능하다. 2개의 관심사(커넥션/SQL)을 아예 독립적으로 분리시키면 손쉽게 확장이 가능하고 상속을 사용하지 않아도 됨. 12. 여기서 다시 원점.. 더보기
[static] 자바 static 정리 static의 경우 클래스가 메모리에 로딩되기전 이미 정적변수와 정적메소드를 위한 메모리 공간(Method Area)이 할당되므로 객체가 생성될때마다 메모리 공간이 할당되지 않는다. 첫째로, static을 쓴 변수나 메소드는 객체생성없이 모든 객체가 아무런 제약없이 공유할수 있다. 물론 객체생성하고 써도 상관없다. 둘째로, static을 쓴 변수는 값을 공유하므로 연속적으로 그 값의 흐름을 이어갈수 있다는 것이다. JVM은 static으로 선언한 놈을 딱한번 메모리를 할당함. Static 메서드에는 인스턴스 변수가 올 수 없다 당연하다. 스태틱 메서드는 인스턴스를 생성안하고도 호출할 수 있으니까 Main 메서드는 static인 이유 : 누군가 호출하기 전에 실행되어야 한다. 즉, 메모리에 올라가 있어야 .. 더보기
[자바 상속] extends 확장 VO > 자바빈(JavaBean) : 파라미터가 없는 디폴트 생성자를 갖고 있어야한다. 툴이나 프레임워크에서 리플렉션을 이용해 오브젝트를 생성하는데 필요하기 때문 1. 리플렉션 : 객체를 통해 클래스의 정보를 분석해내는 프로그램 기법(class.forName을 통해 메모리에 로딩된 객체의 메서드 생성자 등을 알아내서 사용가능) 2. 프레임워크 : 흐름을 주도한다. 프레임워크 위에 개발한 클래스를 등록하고 프레임워크가 흐름을 주도함 3. Property : id, name, password(자바빈의 속성) 프로퍼티는 set/get 메서드를 이용해 수정 또는 조회 가능하다. 고객의 DB패스워드가 변경되었다고 해보자. UserDao의 바이너리를 판매한 상태이다. Dao 소스코드를 전달하여 줄 것인가?? 수정해.. 더보기