추상 클래스의 작성 (2)

추상 클래스의 작성

이번 시간은, "아직 추상 클래스가 왜 필요한지 잘 모르겠다!" 라는 생각을 말씀히 지워보는 시간이다.

예를 들어서, 같은 회사의 50인치 Tv A, B, C가 있다고 가정해보자.

그러면, 설계도가 비슷할 것이다.
공통부분이 있고, 약간의 부분만 다를 것이다. 

이것들을 설계도를 하나하나씩 관리한다면, 
만약, 변경사항이 생기면, 설계도를 하나하나씩 다 고쳐야 할 것이다.

그래서 객체지향 개념에서는 이것을 어떻게 하냐면,
공통부분을 조상클래스로 묶는다.

대신 이것은 미완성 설계도 이다.

그리고, 이 미완성 설게도를 바탕으로 설계도를 완성시킨다.
부모 자손관계로 해놓으면, 중복이 제거되고, 자손들은 옵션만 추가하면 완성된다.

처음보다 설계도를 만들기 쉬워졌다.

그리고, 만약에 또 새로운 모델이 만들어 진다면, 
공통부분을 묶어놓은 미완성 설계도를 상속받아서 옵션을 추가해서 새로운 설계도를 만들면 된다.

처음에 작성한 미완성 설계도는 미완성이지만, 그것이 있음으로해서 다른 설계도의 작성이 쉬워졌다.

그리고 또다른 장점은, 공통부분을 바꾸려면, 미완성 설게도에서만 바꾸면,
이것을 상속받아서 사용하는 설계도들에도 변경이 적용된다.
즉, 코드의 관리가 용이해진다.

그리고 추상 클래스를 하나만 만들어 놓는게 아니라,
단계별로 만들어 놓으면, 
조상으로부터 상속받으면서 추상 클래스가 점점 구체적으로 된다.

추상클래스를 하나만 만드는게 아니라,
추상클래스가 의미있는 단계별로 하나씩 만들면 어떤 장점이 있냐면,
공통부분에서 다른 한 부분도 바꾸고 싶을 때, 해당 단계의 추상클래스를 상속받아서 추가하면 된다는 장점이 있다.

 

---

 

추상화의 반대말은, 구체화다.
구체화의 반대말은 추상화다.

구체화는 명확, 구체적인 것이고,
추상화는 불명확하고 덜 구체적인 것이다.

그러면, "구체적인게 좋은게 아닐까?"
물론 구체적인게 명확하고 좋다.

하지만, 때로는 불명확한 것(애매한 것)이 더 좋을 때가 있다.

추상화된 코드는 구체화된 코드보다 유연하다. (변경에 유리)

 

이 코드를 보면,

첫번째 코드는 구체적이다. 어떤 클래스의 객체를 만들 것인지 명시되어 있고, 참조변수의 타입또한 다루고자하는 객체의 타입과 일치한다.
굉장히 명확하다. 내가 어떤 클래스의 객체를 만들어서 이것을 그 클래스 타입의 참조변수로 다루고자 한다라는 것이 확실하고, 해당 인스턴스 객체의 모든멤버를 컨트롤 할 것이라는 것을 예상할 수 있다. 모든게 분명하다.

두번째 코드는 추상적이다. 두번째 코드는 Calendar의 객체를 반환한다. 이것을 Calendar타입의 참조변수 cal로 받는데, 
해당 예제에서 쓰인 Calendar클래스는 추상클래스인데, (문제에서 가정한 것임)
추상클래스타입의 참조변수로 자손객체를 다루는 것이 가능하다.  두번째 코드는 엄밀히 말하면, Calendar의 자손객체를 반환하는데,
그래서, getInstance()라는 메서드가 무엇을 반환할지 불분명하다. 이것이 바로 추상화다.

 

명확한 코드의 장점도 분명 있지만, 추상적인 코드도 분명 장점이 존재한다. 아래 코드를 보자.

getInstance라는 메서드가 무엇을 반환하냐면, 캘린더를 생성해서 반환한다.
 createCalendar라는 메서드가 어떤 역할을 하냐면, 객체 생성을 통해서 반환을 하는데, 
case에 따라서 (caltype에 따라서- 불교력, 일본력, 서양력​) 다른 객체를 생성해서 반환하는 것이다.

그런데 만약에 코드를 구체적으로 써놓으면, 나라마다 코드를 변경해야 한다.
그러나, 두번쨰 코드처럼 코드를 추상적으로 써놓으면, 더 유연하다.

추상화는 다형성과 관계가 깊다.