Loading...

JAVA / / 2022. 5. 31. 22:59

복습) 추상화

반응형

프로그램을 만들 때 처음부터 추상화된것부터 생각하기는 어렵다.

구체적인것부터 올라가며 추상화시켜야한다.

 

___________

의존성 주입 ?

나는 A가 필요한데 A는 B가 필요하다.

이때 알아서 다 필요한걸 DI를 해줘서 내가 신경쓸 필요가 없다.

 

라이브러리는 모두 DI이다.

 

gradle이나 maven이 없으면, 의존성 관리 도구가 없으면 너무너무 힘들다. 라이브러리 관리하기가 !!

이걸 사용하면 필요한 라이브러리만 가져오면 애들이 다 갖다준다.

 

DI가 왜좋냐. 생성자 주입을 해주니까. 필요한거있으면 다 주입해준다.

 

pip도 똑같고 npm 똑같고 라이브러리  관리 도구는 모두 DI 방식이다. 엄청 편하다. 다 똑같음 !

 

DI의 특징 : 라이브러리를 가지고있는 컨테이너가 필요하다.

IoC도 똑같은 개념이다.

 

Mockito도 똑같다. mockito안에 있는거 필요할때마다 다 넣어준다. InjectMocks로!

____________

 

 

드라군의 피 상태를 변화시킬 수 있는 메서드가 있을거고

히드라는 공격을 할 수 있기 때문에 본인의 행위 어택 메서드를 가지고 있을 수 있다,

근데 이 어택(행위)은 본인(히드라)의 상태를 변경하는게 아니다,

히드라 입장에서 어택을 한다는 얘기는 얘가 다른애의 피 상태를 직접 변경할 수 없기때문에

다른애의 상태를 변화시키는 메서드를 때리는것이다.

 

그렇기 때문에 히드라는 드라군의 레퍼런스 주소가 필요하다.

 

그 말은 히드라가 드라군에 의존적이므로 컴포지션이 필요하다.

 

얘들은 다른데 상속할 순 없잖아.

 

여기서 재밌는건 드라군도 히드라에게 의존적이다.

 

울트라, SCV, 탱크에게도 의존적이다. 때리기 위해선!

 

이건 완전 미친짓이다.

 

그렇기 때문에 추상적인것에 의존해야한다.

 

프로토스 <- 질럿, 드라군

저그 <- 히드라, 울트라

테란 <- SCV, 탱크

 

프로토스, 저그, 테란은 abstract 메서드이다.

 

이제 자식들의 공통적인것들을 뽑아올 수 있다.

뽑아서 부모에 만들어두면 오버라이딩이 가능해 재사용할 수 있다.

 

공통적이지 않은 것을 부모에게 뽑아올리면 자식들이 무조건 구현해야하기 때문에 맞지않다.

 

공통적인것들을 뽑아올려야한다.

 

최종적으로 스타크래프트 유닛으로 추상화한다.

스타크래프트 <- 프로토스, 저그, 테란

다형성도 성립한다.

 

또한 프로토스와 저그, 테란의 공통적인것을 스타크래프트에게로 뽑아올린다.

 

이제 새로운 유닛이들어오면 설계하는 방향이 달라진다.

 

처음에 설계할때는 구체적인 것에 제약이 없고 잘 만든뒤 공통적인것들을 뽑아올렸는데

그 이후에 새로운 유닛을 추가하면 강제성이 부여되어 적절한 부모에게 넣어줘야한다.

 

추상화를 왜해요?

천천히대답

 

여기서 문제가 될게 있다.

 

저글링이라는 유닛이 추가되어 저그를 상속받는다.

추상클래스 데미지, 어택 메서드를 구현해야한다.

 

근데 클라이언트가 데미지 메서드를 호출하는게 맞나?

어택 메서드를 통해 데미지가 호출된다.

 

여기서 이제 노출될 메서드와 안될 메서드를 가려야한다.

 

노출시킬 메서드를 정해야하는데 바로 이게 인터페이스이다.

 

공통적이라고 모두 인터페이스에 넣는게 아니라 노출할 행위들(필요한 행위)만 넣어두고 무조건 구현해야하게 만든다.

 

1000개의 메서드를 가진 게임이라고 할 때 클라이언트가 a키만 누르면 내부적으로 30개 메서드가 호출될 수 있게 해야한다.

이때 외부에 a키만 노출시키면 되는데 이게 인터페이스이다.

이런것을 조이스틱이라고도 부른다.

 

이렇게 만들면 뭐가 좋냐면 모든 메서드를 private하게 만들 수 있다. 은닉이 가능.

왜 은닉시키냐? 얘들은 다이렉트하게 호출할 일이 없기 때문이다.

노출된 인터페이스의 메서드가 호출시켜줄거기 때문에 !

 

실제로 세상에 존재하는게 유닛들(오브젝트)이기 때문에 인터페이스를 다이렉트로 유닛들에게 얹히는 것이다.

implements로 !

 

왜 인터페이스를 최상위인 스타크래프트에게 걸지않았을까?

스타크래프트의 제약이 아니기 때문이다.

실제 세상에 존재할 수 있는것들에게 걸려야 할 제약이다.

 

 

원래 private 상태에 접근하기 위해 getter, setter를 다 만들었는데 이젠 생각하고 만들자.

다 만들필요없다.

 

행위를 만들때 내 상태를 변경하는지 다른 오브젝트의 상태를 변경하는지 잘 확인해야한다.

 

final이 붙으면 디폴트생성자를 만들 수 없다.

 

메서드는 다른 오브젝트와 협력해야하기 때문에 public으로 공개되어 있어야함

반응형