[스프링 입문을 위한 자바 - 객체 지향의 원리와 이해] 정리

스프링을 입문을 위한 자바 객체지향의 원리와 이해

• 1장
• OOP - 객체 지향 프로그래밍 C++ / 자바 / C#
• 2장
  • JDK - JVM용 소프트웨어 개발 도구
  • JRE - JVM용 OS
  • JVM - 가상의 컴퓨터
  • 스태틱 영역 - 클래스들의 놀이터
  • 스택 영역 - 메서드들의 놀이터
  • 힙 - 객체들의 놀이터
• 3장
  • 캡슐화
    • 정보 은닉
    • private - 본인만 접근 가능
    • default - 같은 패키지 내의 클래스에서 접근 가능
    • protected - 상속 / 같은 패키지 내의 클래스에서 접근 가능
    • public - 모두가 접근 가능
  • 상속
    • 재사용 + 확장
    • 상위 클래스의 메서드와 필드를 하위 클래스에서도 사용하거나 추가
  • 추상화
    • 구체적인 것을 분해해서 관심 영역에 있는 특성만 가지고 재조합하는 것 = 모델링
  • 다형성
    • 오버라이딩 - 같은 메서드 이름, 같은 인자 목록으로 상위 클래스의 메서드를 재정의
    • 오버로딩 - 같은 메서드 이름, 다른 인자 목록으로 다수의 메서드를 중복 정의
• 객체 지향의 4대 특성 - 캡! 상추다
• 4장

  public abstract class 동물{
  	abstract void cry();
  }
  

  • 추상 클래스는 객체를 만들 수 없다.
  • 추상 메서드는 하위 클래스에게 메서드의 구현을 강제한다.
  • 추상 메서드를 포함하는 클래스는 반드시 추상 클래스여야한다.
  static 블록
  • 클래스의 정적 속성을 사용할 떄 출력
  • 클래스의 정적 메서드를 사용할 때 출력
  • 클래스이 인스턴스를 최초로 만들 때 출력
• public class animal{ static{ System.out,println("animal is ready!"); } public static void main(String[] args){ animal lion = new animal(); } } 출력: animal is ready!
• abstract 키워드 - 추상 메소드와 추상 클래스
• 5장결합도와 응집도응집도 - 하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성으로, 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져 재사용이나 기능의 수정, 유지보수가 용이하다.
  • 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.
  • 남자 클래스와 남자 클래스에 의존하는 여자친구, 어머니, 직장상사, 소대장 클래스가 있다면,
  • 각 여자친구, 어머니, 직장상자, 소대장 클래스에서 필요한 남자 클래스의 메서드만 분리하여 특정 메소드가 변경 될때 다른 클래스나 메소드에 영향이 없어야한다. (유지보수 용이)
  OCP - 개방 폐쇄 원칙
  • 확장에 대해서는 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 한다.
  • (수동)마티즈 클래스와 (자동)쏘나타 클래스가 있다면 운전자는 마티즈에서 쏘나타로 바뀌면 조작방법(메서드)도 바꿔줘야한다. 하지만, 인터페이스나 상위 클래스를 둠으로써 동일한 메서드로 다른 차(객체)를 사용할 수 있다.
  • JDBC또한 개방 폐쇄 원칙 적용 - 클라이언트는 데이터베이스가 바뀌더라도 Connection 설정 외에 수정할 필요가 없다.
  LSP - 리스코프 치환 원칙
  • 서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다.
  • 하위클래스 is a kind of 상위클래스, 구현 클래스 is able to 인터페이스
  • 하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의 인스턴스 역할을 하는데 문제가 없어야 한다.
  • 딸 인스턴스 > 아버지 인스턴스 > 할아버지 인스턴스 x
  • 고래 > 포우류 > 동물 o
  ISP - 인터페이스 분리 원칙
  • 클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다.
  • 단일 책임 원칙 문제와 동일
  • 상위 클래스는 풍성하게, 인터페이스는 최소화시켜 불필요한 형변환이나 불필요한 메서드를 제거
  • 인터페이스는 그 역할에 충실한 최소한의 기능만 공개
  DIP - 의존 역전 원칙
  • 추상화된 것은 구체적인 것에 의존하면 안된다, 자주 변경되는 구체클래스에 의존하지 마라
  • 자동차 클래스는 스노우 타이어에 의존 x
  • 자동차 클래스는 타이어 인터페이스에 의존(언제든지 교체 가능)
• SRP - 단일 책임 원칙
• 결합도 - 모듈(클래스) 간의 상호 의존 정도로서 결합도가 낮으면 모듈 간의 상호 의존성이 줄어들어 객체의 재사용이나 수정, 유지보수가 용이하다.
• 객체 지향 설계 5원칙 - SOLID
• 6장요리도구 - 4대 원칙레시피 - 디자인 패턴
  • 개방 폐쇄 원칙(OCP)을 활용한 설계 패턴
  프록시 패턴
  • 대리자, 대변인 등 다른 누군가를 대신해 그 역할을 수행하는 존재
  • 메서드의 반환값에 가감하지 않는다는 것
  • 제어의 흐름을 변경하거나 다른 로직을 수행하기 위해 사용
  • 개방 폐쇄 원칙(OCP)과 의존 역전 원칙(DIP)
  데코레이터 패턴
  • 원본에 장식을 더하는 패턴
  • 프록시 패턴 + 반환값에 장식을 덧입힘
  • 메서드 호출의 반환값에 변화를 주기 위해 중간에 장식자를 두는 패턴
  • 개방 폐쇄 원칙(OCP)과 의존 역전 원칙(DIP)
  싱글턴 패턴
  • 하나의 인스턴스를 만들어 사용 (두 개의 객체가 존재 x)
  템플릿 메서드 패턴
  • 상위 클래스의 견본 메서드에서 하위 클래스가 오버라이딩한 메서드를 호출하는 패턴
  • 의존 역전 원칙(DIP) 활용
  팩터리 메서드 패턴
  • 객체를 생성 반환하는 메서드
  • 의존 역전 원칙(DIP) 활용
  전략 패턴
  • 전략 메서드를 가진 전략 객체
  • 전략 객체를 사용하는 컨텍스트
  • 전략 객체를 생성해 건텍스트에 주입하는 클라이언트
  • 클라이언트가 전략을 생성해 전략을 실행할 컨텍스트에 주입하는 패턴
  템플릿 콜백 패턴
  • 전략 패턴의 변형 / 스프링에서 DI에 사용되는 특별한 형태의 전략 패턴
  • 개방 폐쇄 원칙(OCP)과 의존 역전 원칙(DIP)
  익명 내부 클래스 1회성 인스턴스 생성 없이 메서드를 구현, 사용하기 위해
• 어댑터 패턴
• 요리도구 사용법 - 설계원칙(SOLID)
• 스프링이 사랑한 디자인 패턴
• 7장Ioc/DI - 제어의 역전/ 의존성 주입
  • 의존성 - 전체가 부분에 의존한다.
  • new car();
  • Car 객체 생성자에서 new Tire();
  • (자동차가 타이어에 의존)
  • 의존하는 객체와 의존되는 객체 사이에 집합 관계, 구성관계로 구분됨
  스프링 없이 의존성 주입 - 생성자를 통한 의존성 주입
  • 주입 - 자동차 내부에서 타이어를 생성하는 것이 아닌 외부에서 생성된 타이어를 자동차에 주입
  스프링 없이 의존성 주입2- 속성을 통한 의존성 주입
  • 운전자가 타이어를 교체 장착하기 위해 속성을 통한 의존성 주입을 사용
  스프링을 통한 의존성 주입 - XML 파일 사용

  ApplicationContext context = new ClassPathXmlApplicationContext("expert002.xml", Driver.class);
  
  Tire tire = (Tire)context.getBean("tire");
  
  Car car = (Car)context.getBean("car");
  car.setTire(tire);
  

  <?xml version="1.0" encoding="UTF-8"?>
  <beans ....
  ..
  ..
  >
  <bean id="tire" class="expert002.KoreaTire"></bean>
  <bean id="americtire" class="expert002.AmericaTire"></bean>
  
  </beans>
  
  

  • 종합 쇼핑몰(스프링 프레임워크)에 상품(bean)을 등록한다.
  • 미국타이어로 바꾸기위해 자바코드를 변경/재컴파일/재배포 할 필요 없이 xml파일 id만 변경하면 된다.
  스프링을 통한 의존성 주입 - 스프링 설정 파일(XML)에서 속성 주입

  <bean id="tire" class="expert003.KoreaTire"></bean>
  <bean id="americtire" class="expert003.AmericaTire"></bean>
  
  <bean id="car" class="expert003.Car">
  	<property name="tire" ref="koreaTire"></property>
  </bean>
  

  • 속성 메서드를 이용해 자동차 타이어 속성을 주입
  스프링을 통한 의존성 주입 - @Autowired를 통한 속성 주입

  <contextLannotation-config />
  
  <bean id="tire" class="expert004.KoreaTire"></bean>
  
  <bean id="americtire" class="expert004.AmericaTire"></bean>
  
  <bean id="car" class="expert004.Car"></bean>
  </bean>
  

  • 스프링 제공
  • @Autowired - 자동으로 속성의 설정자 메서드에 해당하는 역할을 해줌 (자동 의존성 주입)
  • id가 없이 단일 빈만 가지고 있으면 해당 속성 자동 매칭
  • id가 다른 단일 빈만 가지고 있으면 해당 속성 자동 매칭
  • id가 없는 두 개 이상의 빈을 가지고 있으면 에러
  • id매칭보다 type매칭이 우선
  스프링을 통한 의존성 주입 - @Resource를 통한 속성 주입
  • 표준 자바 제공
  • type매칭 보다 id매칭이 우선
  @Autowired vs @Resource
  • 둘 차이가는 크게 없지만 자바 표준인 resource를 추천
  • resource와 <property> 중에서 <property> 추천
• import javax.annotation.Resource; @resource Tire tire;
• import org.springframeword.beans.factory.annotation.Autowired; @Autowired Tire tire;
• ApplicationContext context = new ClassPathXmlApplicationContext("expert002.xml", Driver.class); Car car = context.getBean("Car", Car.class);
• import org.springframeword.context.ApplicationContext; import org.springframeword.context.support.FileSystemXmlApplicationContext;
• Tire tire = new KoreaTire(); Car car = new Car(); car.setTire(tire);
• Tire tire = new KoreaTire(); Car car = new Car(tire);
• 스프링 삼각형 - POJO (IOC/DI, AOP, PSA)