낙서장1

주제

원리, 개념

방법

결과 및 정리

인용

주제

첨에는 오브젝트를 어떻게 만들것인가에 대한 의문

그냥 만들면 되는 거야? 여기서 말하는것은 오브젝트란 어케 만들어야하는 것인가에 대해서

아니!

개념, 원리에 대응하는 항목

몇가지의 체크 목록

변화에 대응할 수 있는가?

변화에 대응되는 어떠한 개체의 주변에 영향은 없는가?

관심이 집중 되어 있는가?

즉, 변화에 대응할 수 있으면 변화에 대응하는 어떠한 개체의 주변에 영향이 없으며 관심도가 하나에 개체에 집중되어 있는가? 그것이 잘 지켜진다면 그 개체는 잘만든 개체가 될 것이다.

이를 한마디로 표현한 개념

높은 응집도, 낮은 결합도 OCP

방법

그럼 어떻게 해야 잘만드는 개체가 될까?

토비의 스프링에서 추천하는 방식 (초난감DAO 기준)

[Java] 추상 클래스와 인터페이스의 차이

간단히 말하면... 클래스를 설계도라 하면, 추상 클래스는 미완성 설계도에 비유할 수 있다. (여기서 클래스가 미완성이라는 것은 추상 메서드를 포함하고 있다는 의미이다.) 예를 들면, 같은 크기의TV라도 기능의 차이에 따라 여러 종류의 모델이 있지만 설계도 90은 동일할테니, 어느정도 틀을 갖춘 상태에서 진행하는 것이 좋다. 이때 사용할 수 있는 것이 추상 클래스 이다.

https://velog.io/@new_wisdom/Java-%EC%B6%94%EC%83%81-%ED%81%B4%EB%9E%98%EC%8A%A4%EC%99%80-%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4%EC%9D%98-%EC%B0%A8%EC%9D%B4

추상 클래스와 인터페이스의 차이 1-1 (사용에 가까운 예제)

[JAVA] 자바 인터페이스와 추상클래스 차이

모두 추상이라는 개념을 사용하여 자식클래스의 기능을 구현해줍니다. 추상클래스 뒤에 클래스라고 붙은 것처럼, 추상클래스는 클래스의 한 종입니다. 클래스의 일종이기 때문에 자식클래스에서 추상클래스를 상속받아 사용할 수 있고, 추상클래스에서 추상클래스를 상속받아서도 사용할 수 있습니다. ( 자식클래스는 일반 혹은 추상클래스 중 한개만 상속가능 ) 추상클래스는 추상메소드를 사용할 수 있고, 자식클래스에서 추상메소드의 구현을 강제하도록 합니다.

https://mozi.tistory.com/556

추상 클래스와 인터페이스의 차이 1-2 ( 개념에 가까운 예제)

간략한 추상클래스와 인터페이스 차이

추상 클래스에서의 상속은 고유 속성에 가까운 정의다. 하지만 인터페이스는 행위에 대한 상속? 이라고 말할 수 있다.

Abstract를 이용한 “상속”을 통한 방식

Interface를 이용한 방식

이방법들이 곧 템플릿, 전략 패턴 등이다. 근데 하다보니 또 귀찮다. userDao를 테스트에서 일일이 만들어 주는것이... 그래서 그냥 만들어지게 하면 안될까? 팩토리 메서드 패턴을 사용

근데 이렇게 하다보니 신기하다. 내가 객체를 만드는 것이 아닌 객체가 객체를 만들어 주는 역할을 하게 되니 말이다. 단순히 client 입장에서는 요청만 보내면된다. userDao 가 필요해.. 라고 그럼 factory에서 적절한 userDao를 만들어준다. 그것도 connection이 포함된 상태로

이렇게 되면 clinet 는 내가 무엇이 필요한지 단지 요청만 하면된다. 이후에 객체의 생성과 주입은 모두 팩토리가 맡게 된다. 이 때문에 이번 장의 주제인 관심이 분리된다. 또한 자연스럽게 객체 하나의 수정이 다른 객체에 영향을 주는게 없어진다.

스프링의 ioc도 동일한 매커니즘으로 적용

factory 는 설정 정보 및 메타정보가 되고 이를 읽어 Application-Context에서 요청이 올때마다 빈(오브젝트)를 제공해준다.

하지만 중요한 차이점! 우리가 만든 factory의 확장판이 스프링 context 이지만 차이점은 분명있다. 당연하지만

스프링의 제공 빈은 싱글톤이다. 그럼 왜? 이렇게 만드는 것일까?

스프링같은 대규모 엔터프라이즈 서버 환경에서 사용하는 프레임워크는 엄청많은 요청을 받아 처리할 수 있는 높은 성능이 요구 된다. 하지만 이때마다 오브젝트를 만드는 건 매우매우 서버에 부담이된다. 그래서 싱글톤으로 만들어 사용한다.

그럼 어케 만들어 스프링에서는? 싱글톤을?

먼저 일반적인 싱글톤의 경우 한계점이 있다.

•

상속불가 (private 생성자)

•

테스트 하기 어렵다. (싱글톤은 하나만 만들어지기 때문에 다른곳에서 호출하기 까다롭기때문)

•

하나만 만들어진다? 이걸 보장하기 힘들다. 이건 코드상 구현

•

전역상태를 만들 수 있기 때문에 바람직하지 못하다.(다 접근 가능한 static 이라는 상태 때문)

하지만 스프링은 싱글톤 레지스트리를 사용함으로 이러한 비정상적인 싱글톤에서 자유롭게 해준다.

이를 통하여 좀 더 서버환경에서 좋은 factory를 스프링은 가지고 있다.

결론적으로 스프링의 di/ioc는 객체지향의 원리, 원칙에서 벗어난 녀석이 아니다. 그걸 더욱 잘 지켜주기위한 도구다.

객체지향을 더 잘지키기위한 기술적 개념일 뿐이다.

우리가 해야할일은 객체지향적으로 설계하는 것이다.이를 이루기 위한 몇 가지 규칙이 있었다.(체크리스트)

규칙을 지키기 위하여 부수적인 수단으로 사용한 것이 디자인 패턴이다.

정리

이 절에서 요구했던 객체는 어떻게 만들어야하는가? 는 체크리스트에 해당하게 만들면 된다는 걸 알았다. 이를 위해서 필요한 개념과 방법도 알아 보았다. 더 나아가 스프링 또한 이러한 원리 원칙을 준수하기 위한 프레임워크라는 점도 알 수 있었다.