오브젝트 그냥 만들면 되는거야?
어떻게 오브젝트를 만들란 거야?
스프링에서의 객체지향을 바라보는 시선(서론)
스프링 이야기를 해야하는데 뜬금없이 오브젝트라니? 하지만 토비의 스프링에 가장 첫번째로 적혀있는 문장은 바로 “스프링이 자바에서 가장 중요하게 가치를 두는 것은 객체지향 프로그래밍이다.”이다. 이렇듯 스프링을 알기전에 제일 중요한건 우리가 모르고 살았던 객체 지향 프로그래밍이다.
그럼 객체 지향의 설계의 방향은 어떻게 잡아야 하는 거야?(원리, 개념)
설계 개념
변화에 대응할 수 있으며, 한 객체가 변화를 수용 할 때 이 객체를 사용하는 다른 객체에 변화가 없어야 한다. 또한 한 객체에 관심도가 집중되고 다른 객체와의 결합도는 낮아야 한다.
•
참 어렵다.
체크리스트 (원리 적용)
필자의 경우도 잘하는게 아니다. 하지만 필자는 바보기 때문에 더욱 명료한 기준이 필요했다. 그래서 간단한 체크리스트를 만들었다. (물론 아닐 수 있다. 지적 및 태클은 매우 감사합니다.)
변화에 대응 할 수 있는가? (수정, 추가, 삭제)
한 객체 또는 개체가 변화를 수용 할 때 이 객체 또는 개체와 관계있는 객체 또는 개체들의 변화가 발생하는가? (수정, 추가, 삭제)
한 객체에는 그 객체의 관심사만 집중되어 있는가?
토비의 스프링에서는 어떻게 변화에 대응할 오브젝트를 만드는가?(방법)
초초초초초초초초초초초초초초초초초초초난감 DAO
덜 초난감 DAO 메서드 추출 방식
난감한 DAO abstract class상속을 통한 방식
덜 난감한 DAO class 분리를 통한 방식
이제 안 난감한 DAO interface를 이용한 방식
객체는 위와 같은 과정을 통하여 만드는 것이 이상적이다. 체크해보자(이제 안 난감한 DAO 기준)
변화에 대응 할 수 있는가? (인터페이스만 상속받으면 된다.)
한 객체 또는 개체가 변화를 수용 할 때 이 객체 또는 개체와 관계있는 객체 또는 개체들의 변화가 발생하는가? (사용하는 입장에서는 D사를 쓰건 N사를 쓰건 바라보는건 인터페이스 뿐이다. 수정할 일이 없다.)
한 객체에는 그 객체의 관심사만 집중되어 있는가? (커넥션은 커넥션만, 데이터 엑세스를 담당하는 DAO는 DAO의 역할만 할 뿐이다. 더 이상 커넥션을 DAO에서 생성하고 관리하지 않아도 된다.)
여기서 애드립 (interface와 abstract class는 같은 일을 하는데 왜 차이가 나는거야?
방법 정리
1.
메서드 추출을 우선적으로 고려하라. (바뀌는 부분과 바뀌지 않는 부분을 생각하기)
2.
abstract class의 사용도 고려해보면 좋다. (바뀌는 부분을 효율적으로 바꾸는 것을 생각하기)
3.
class로 관심 자체를 분리해보는 것도 좋은 방법이다. (관심사라는 부분을 생각하기)
4.
class와 abstract로 해결되지 않는 문제는 interface사용을 고려해보자. (모든 부분을 포함하고 의존성이라는 부분을 생각해보기)
정리
1.
객체를 만들 때는 변화에 대응할 수 있으며, 한 객체가 변화를 수용 할 때 이 객체를 사용하는 다른 객체에 변화가 없어야 한다. 또한 한 객체에 관심도가 집중되고 다른 객체와의 결합도는 낮아야 한다.
2.
위의 개념을 적용하는 방법은 크게 4가지로 정리했다.
a.
메서드 추출을 우선적으로 고려하라. (바뀌는 부분과 바뀌지 않는 부분을 생각하기)
b.
abstract class의 사용도 고려해보면 좋다. (바뀌는 부분을 효율적으로 바꾸는 것을 생각하기)
c.
class로 관심 자체를 분리해보는 것도 좋은 방법이다. (관심사라는 부분을 생각하기)
d.
class와 abstract로 해결되지 않는 문제는 interface사용을 고려해보자. (모든 부분을 포함하고 의존성이라는 부분을 생각해보기)
체크 리스트
주제 : 오브젝트를 만드는 방법과 개념 (그럼 객체 지향의 설계의 방향은 어떻게 잡아야 하는 거야?)
원리 및 개념 : (그럼 객체 지향의 설계의 방향은 어떻게 잡아야 하는 거야? 개념 설명과 나만의 체크리스트)
방법 : (토비의 스프링에서는 어떻게 변화에 대응할 오브젝트를 만드는가? 방법 4가지)
인용 및 참고
[JAVA] 자바 인터페이스와 추상클래스 차이
모두 추상이라는 개념을 사용하여 자식클래스의 기능을 구현해줍니다. 추상클래스 뒤에 클래스라고 붙은 것처럼, 추상클래스는 클래스의 한 종입니다. 클래스의 일종이기 때문에 자식클래스에서 추상클래스를 상속받아 사용할 수 있고, 추상클래스에서 추상클래스를 상속받아서도 사용할 수 있습니다. ( 자식클래스는 일반 혹은 추상클래스 중 한개만 상속가능 ) 추상클래스는 추상메소드를 사용할 수 있고, 자식클래스에서 추상메소드의 구현을 강제하도록 합니다.
https://mozi.tistory.com/556
추상 클래스와 인터페이스의 차이 1-2 ( 개념에 가까운 예제)
1장 오브젝트와 의존관계
토비의 스프링 1권 1장을 요약한 내용 입니다.
https://incheol-jung.gitbook.io/docs/study/tobys-spring/undefined/1
토비의 스프링 요약 및 정리
부가 설명
왜 50page 기준인데 87page까지 정리된 것인지 의문일 수 있다. 이 이유는 오브젝트의 설계와 스프링의 제어역전 기능을 같이 설명하기엔 주제와 괴리감이 생기기 때문에 제외했다.
애드립 적용 결과 (간단한 계산기를 체크리스트와 같이 적용시켜보자)
체크리스트에 맞게 적용해 볼 것이다. 하지만 체크리스트를 한방에 맞게 적용시키기 보다는 토비의 스프링에서 추천하는 방식의 흐름을 한번 따라가보려고 한다.
1.
메서드 추출을 우선적으로 고려하라. (바뀌는 부분과 바뀌지 않는 부분을 생각하기)
2.
abstract class의 사용도 고려해보면 좋다. (바뀌는 부분을 효율적으로 바꾸는 것을 생각하기)
3.
class로 관심 자체를 분리해보는 것도 좋은 방법이다. (관심사라는 부분을 생각하기)
4.
class와 abstract로 해결되지 않는 문제는 interface사용을 고려해보자. (모든 부분을 포함하고 의존성이라는 부분을 생각해보기)
계산기이다. 하지만 초초초초초초난감한 DAO와 마찬가지로 한번 만들어 볼까 한다. 하지만 완벽한 계산보다는 객체지향관점을 이해하기 위한 예제로 존재하는 점을 이해하고 봐주기를 바란다. (완벽하게 생각하진 못했다.. 그리고 목표는 Calculator.class 자체의 수정을 적게 만들기 위함이다.)
초초초초초초초초난감 계산기?
덜 초난감한 계산기? 메서드 추출을 일단해보자 (바뀌는 부분?)
난감한 계산기? abstract class 상속을 통한 방식 (효율적으로 바꾸기?)
덜 난감한 계산기? class 분리를 통한 방식 (관심사 분리?)
이제 안 난감한 DAO interface를 이용한 방식(느슨한 결합?)
솔직히 만들기 전까진 “이렇게 하면 될 것이다.” 라는 생각을 가지고 있었다. 하지만 막상 만들어 보니 생각보다 실수 하는 부분이 많이 있고 이해 못하는 부분이 많다는 사실을 알았다. 예를 들자면 연산과 결과 출력을 한번에 묶어 생각했다는 점처럼 아직 수정해야 할 부분이 많다.