스프링 핵심 기술
- IOC(Invertion of Control, 제어 역전)
- 인스턴스(객체)의 생성부터 소멸까지 객체의 생명주기 관리를 개발자가 아닌 스프링이 대신 해주는 것
- 즉, 제어권이 개발자가 아닌 IOC에 있으며, IOC가 개발자의 코드를 호출하여 그 코드로 생명주기를 제어함.
- DI(Dependency Injection, 의존성 주입)
- 프로그래밍 내 구성요소 간의 의존 관계가 코드 내부가 아닌 외부의 설정파일을 통해 정의되는 방식
- 스프링을 이용하여 필요할 때마다 외부 기술을 뺐다 꼈다 하면서 적절하게 기능을 수행해낼 수 있음.
- AOP(Aspect-Oriented Programming, 관점 지향 프로그래밍)
- 로깅, 트랜젝션, 보안 등 여러 모듈에서 공통으로 사용하는 기능을 분리하여 관리함.
- 즉, 여러 객체에 공통으로 적용할 수 있는 기능을 구분함으로써 재사용성을 높여주는 기법
- POJO(Plain Old Java Object)
- 별도의 프레임워크 없이 Java EE를 사용할 때와는 달리 인터페이스를 직접 구현하거나 상속받을 필요가 없어서 기존 라이브러리를 지원받기 용이하고, 객체가 가벼움.
- 즉, getter/setter를 가진 단순한 자바 오브젝트를 말함.
객체 지향 특징
- 추상화
- 실제 세상을 객체화하는 대신, 필요한 정보만을 중심으로 간소화하는 것
- 클래스들의 공통적인 특성(변수,메소드)들을 묶어 표현하는 것
- 캡슐화
- 데이터와 코드의 형태를 외부에서 알지 못하게 하는 것 (외부에는 행동만을 제공함)
- 데이터의 구조와 역할,기능을 하나의 캡슐 형태로 만드는 것
- 상속
- 부모 클래스의 기능을 자식 클래스에서 상속받아 사용하는 것
- 중복되는 코드의 재사용성을 위해 사용
- ⭐️다형성⭐️
- 하나의 메세지에 대해 객체 별로 가진 고유한 방법으로 응답하는 것
- 메소드 오버라이딩/오버로딩
클래스
- 속성이 같은 객체들을 대표할 수 있는 대상을 클래스라고 한다.
- 클래스는 객체를 정의하는 틀이며, 필드(속성)와 메서드(행위)로 구성된다.
인스턴스
- 인스턴스는 클래스에서 생성한 객체로, 고유한 상태가 있다.
- 동일한 클래스에서 생성된 객체라도 필드와 메서드의 내용은 다를 수 있다.
오버로딩
- 같은 이름의 메서드를 여러개 가지면서 매개변수의 유형,개수를 다르게 하는 것이다.
- 메서드 오버로딩과 생성자 오버로딩이 있다.
오버라이딩
- 상위 클래스가 가진 메서드를 하위 클래스에서 재정의하여 사용할 수 있다.
- 즉, 메서드 이름과 매개변수, 반환형이 전부 같을 경우 상속받은 메서드를 덮어쓴다고 보면 된다.
- '부모 클래스의 메서드는 무시하고, 자식 클래스의 메서드 기능을 사용하겠다'는 의미이다.
스프링과 객체 지향
- 스프링은 다형성을 극대화해서 이용할 수 있게 해준다.
- 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.
- 스프링을 사용하면 마치 공연 무대의 배우를 선택하듯이 구현을 편리하게 변경할 수 있다.
- 좋은 객체지향 설계의 5가지 원칙(SOLID)가 존재한다.
객체 지향 설계 원칙 S.O.L.I.D
- SRP: Single Reponsibility Principle
- 클래스는 단 하나의 책임만을 가져야 한다.
- 클래스는 작게 만드는 것이 원칙인데, 이는 '책임'의 개수로 정해진다. 여기서 책임이란 수행하는 기능이다.
- 클래스는 인스턴스 변수의 개수가 적을수록 좋고, 클래스의 메서드가 인스턴스 변수를 많이 사용할 수록 응집도가 높다.
- '함수를 작게, 매개변수 목록을 짧게' 전략 → 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아지지 않게 변수와 메서드를 적절하게 분리해서 새로운 클래스 2-3개로 쪼개는 과정이 필요하다. 즉, 응집도를 유지하면 작은 클래스 여러개가 나온다.
- OCP: Open Closed Principle
- '확장'에는 열려있어야 하고, '변경'에는 닫혀있어야 한다.
- 즉, 기능 추가/수정 시 클래스의 상속을 통한 확장을 해야하고, 직접 코드를 변경하지 않아야 한다.
- 확장 방법: Interface(전부 껍데기만 정의) / abstract(일부는 구현,일부는 껍데기만) 클래스
- 다형성과 확장을 가능하게 하여 객체지향의 장점을 극대화하는 원칙
- LSP: Liskov Substitution Principle
- 하위타입 객체는 상위타입 객체에서 가능한 행위를 수행할 수 있어야 한다.
- 즉, 상위타입의 객체를 선언하고 하위타입의 인스턴스를 받으면, 상위타입 메서드를 사용해도 정상적으로 동작해야 한다.
- 대표적으로 자바의 Collection 인터페이스로 예를 들 수 있다. (LinkedList, HashSet 모두 add 실행)
- ISP: Interface Segregation Principle
- 클라이언트는 자신이 사용하는 메서드에만 의존해야 한다.
- 즉, 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 않아야 한다.
- 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다는 뜻이다.
- 자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스로 분리
- DIP: Dependency Inversion Principle
- 의존관계를 맺을 때, 변하기 쉬운 것(구체화)보다는 변하기 어려운 것(추상화)에 의존해야 한다.
- 즉, 구현 클래스에 의존하기보다 abstract 클래스나 Interface에 의존하라는 뜻이다. (= 특정 배우가 아닌 극 역할에 의존)
정리
- 객체 지향의 핵심은 다형성
- 다형성만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다. 즉, OCP와 DIP를 지킬 수 없다.
- 뭔가 더 필요하다!