상속 기반이 아닌 코드의 문제점
위의 코드는 상속을 사용하지 않은 코드이다. 인맥 관리 프로그램은 기본적으로 저장/확인 기능이 구현되어야 할 것이다. 두 클래스의 멤버 변수/메소드가 서로 다르므로 저장/확인 구현도 각각 구현해야 할 것이다. 하지만 이러한 클래스 디자인 기반해서 관리 대상이 늘어난다면 그 만큼 코드 수도 늘어나 복잡해질 것이다.
상속 기반의 문제 해결
ComFriend와 UnivFriend은 분명 다른 클래스지만, Friend가 두 클래스를 상속하게 만듦으로 인해 두 클래스에 공톡적인 규칙과 규약을 적용하게 된다. 여기서 말하는 규칙과 규약은 상위클래스(Friend)이다.
상위클래스 참조변수로 각각의 하위클래스 인스턴스를 참조한 상황이다. 보시다시피 배열이 하나니까 저장하는 방법도 하나로 간결해졌다. 뿐만 아니라 전체 정보를 출력하는데 있어서, 하나의 일련된 순서(for문)을 통해 저장된 정보들을 출력 할 수 있게 됐다.
출력문에서 showInfo()를 유의하자! 참조변수(Friend)가 하위클래스 인스턴스를(ComFriend, UnivFriend) 참조하고 있다. 참조변수가 접근 가능한 영역은 상위클래스 영역으로 제한되므로 Friend의 showInfo()가 호출된다고 생각할 수 있다. 하지만 각각의 인스턴스가 자기의 기능을 발휘할 수 있는 이유는 바로 메소드 오버라이딩이 있기 때문이다. 메소드 오버라이딩 덕분에 Friend의 showInfo()가 아닌 ComFriend, UnivFriend에서 재정의한 showInfo()가 호출된다.
재활용을 위해 상속을 사용하는 것이 아님을 유의하자. 위의 예제처럼 상속은 연관된 일련의 클래스들에 의해 공통적인 규약을 정의 및 적용할 수 있기 때문에 사용하는 것이다.
Object 클래스
우리는 toString을 정의한 적이 있다! 지금까지 정의한 toString은 사실 Object 클래스에 있는 toString을 재정의한 것이고, 메소드 오버라이딩을 통해 재정의한 toString을 호출한 것이다. 물론 재정의 하지 않는다면 Object가 가지고 있는 기본 toString이 호출된다.
'Programming > Java' 카테고리의 다른 글
JAVA 17(2) 인터페이스의 기본 접근 지정자 (0) | 2021.08.04 |
---|---|
JAVA 17(1) 인터페이스 (0) | 2021.08.04 |
JAVA 15 오버라이딩 (0) | 2021.08.04 |
JAVA 14 상속 (0) | 2021.08.04 |
JAVA 13 1차원 배열의 이해와 활용 (0) | 2021.08.04 |