* GOF의 Template Method 패턴
* 추상클래스 사용 전
* 추상 클래스 사용 후 - Generalization 수행
문제점
Sorter 클래스를 직접 사용할 것도 아닌데,
일반 클래스로 만드는 것은 바람직하지 않다.
해결 및 남은 문제점
Sorter를 추상클래스로 만들어서 직접 인스턴스를 생성해 사용할 수 없게 만들었다.
개발자에게 제약을 주어서 문제를 해결했다.
다만, 서브클래스가 오버라이팅 해야하는 문제는 아직 해결되지 않았다.
기존의 Sorter 클래스를 추상 메서드로 선언하면 모든 서브 클래스가 반드시
이 메서드를 구현해야하기 때문에 서브 클래스에게 구현을 강제하는 효과가 있다.
추상 메서드를 구현하지 않는다면 상속 받은 서브 클래스는 컴파일 오류가 발생한다 !
추상 메서드를 통해 구현이 강제된 서브클래스의 결과로는 정렬이 잘 된다.
그런데 추상 메서드만 있을 경우에는 Sorter 추상 클래스를 인터페이스 문법으로 바꿔도 좋다.
* 인터페이스 사용 전
* 인터페이스와 Super
* 인터페이스 상속
// 인터페이스를 구현할 때는
// 수퍼 인터페이스의 메서드까지 모두 구현해야 한다.
* 인터페이스 다중상속
// ProtoclA와 ProtocolB에 같은 이름의 메서드가 있더라도
// 메서드 시그너처(이름, 파라미터, 리턴타입)가 같다면
// 다중 상속이 가능하다.
// - 클래스와 달리 메서드를 구현하기 전이라서 충돌날 일이 없다.
// ProtoclA와 ProtocolB에 메서드 시그너처에서 이름, 파라미터는 같지만
// 리턴 타입이 다르다면 다중 상속이 불가능하다.
// - 어느 수퍼 인터페이스의 메서드를 상속 받느냐에 따라
// 동작이 달라지기 때문이다.
* 인터페이스 다중 구현
// 다중 인터페이스를 구현이 불가한 경우,
// - 메서드 이름만 같고
// 메서드 시그너처의 다른 부분(파라미터, 리턴타입)이 다른 경우.
// - 두 인터페이스를 모두 만족시키지 못하기 때문이다.
// 다중 인터페이스를 구현이 불가한 경우,
// - 메서드 이름만 같고
// 메서드 시그너처의 다른 부분(파라미터, 리턴타입)이 다른 경우.
// - 두 인터페이스를 모두 만족시키지 못하기 때문이다.
// 인터페이스들에 같은 시그너처를 갖는 default 메서드가 여러 개 있을 경우,
// 어떤 메서드를 상속 받느냐에 따라 실행 결과가 달라지기 때문에
// 다중 클래스 상속이 불가능 한 것처럼
// 이 경우에도 다중 인터페이스 구현이 불가능 하다.
//
// 그러나, 다음과 같이 클래스에서 default 메서드를 오버라이딩을 한다면,
// 어차피 인터페이스에서 구현한 default 메서드를 사용하지 않기 때문에
// 이 경우에는 다중 구현이 가능한다.
* 인터페이스와 추상클래스
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/List.html
List (Java SE 17 & JDK 17)
Type Parameters: E - the type of elements in this list All Superinterfaces: Collection , Iterable All Known Implementing Classes: AbstractList, AbstractSequentialList, ArrayList, AttributeList, CopyOnWriteArrayList, LinkedList, RoleList, RoleUnresolvedList
docs.oracle.com
* 인터페이스 - Caller / Calle
// 인터페이스 : caller를 만드는 입장
// 인터페이스를 기준으로 한 개발자 입장:
// => 인터페이스 호출 규칙에 따라 객체를 사용한다.
// 인터페이스 : callee를 만드는 입장
// 인터페이스를 기준으로 한 개발자 입장:
// => File의 list() 메서드가 사용할 필터 객체를 만드는 입장이다.
// => 개발자는 FilenameFilter 인터페이스 규칙 따라 클래스를 작성한다.
// => 이렇게 작성한 클래스는 list() 메서드에서 사용할 것이다.
