나름 정리해봤는뎅 이거 너무많은데...?
이거 설명하라고하면 어떻게 설명함?
interface의 특징
1.인터페이스는 클래스가 아닌 인터페이스라는 고유한 형태를 가지고 있다.
2.인터페이스는 통일성 있는 설계를 가능하게 해주며 다형성의 대표적인 방법이다.
3.접근제어자는 public 또는 default만 올 수 있다.
→인터페이스는 다른 구현자들에게 로직을 받는다는 것을 가정하기 때문에, 그 로직의 패키지를 기준으로 접근 제어자를 생각해보면 public과 default가 오는 것은 당연하다.
4.상수 필드와 추상메소드로 구성되어있다.(일반 변수 선언 불가)
→JAVA 8부터는 default 메소드와 static 메소드 또한 인터페이스의 멤버로 추가되었다.
5.한번에 다중상속(implements)이 가능하다.
6.인터페이스는 인터페이스끼리 상속이 가능하다.
이때는 extends 키워드를 사용하고 클래스 상속과 동일한 형식을 갖는다.
7.구현할 클래스가 추상클래스나 다른 클래스를 상속하는 경우에는 선 상속 후 구현을 하여야 한다.
8.인터페이스는 생성자가 없으므로, 객체를 생성 할 수 없다.
추상클래스의 특징
1.클래스들의 공통되는 필드와 메소드를 정의한 클래스
를 말한다.
2.추상 클래스,추상 메소드에는 abstract 키워드를 추가한다.
3.추상클래스는 생성자를 만들 수 있으나, 상속을 위한 클래스이기 때문에 필드에 따로 객체를 생성할 수 없다. 따라서 상속을 통해 자식 클래스에서 인스턴스를 생성해야 한다.
4.추상 클래스는 추상 메소드, 일반 메소드, 필드(멤버변수), 생성자로 구성된다.
5.일반적인 상속의 특성과 동일하다.(extends 이용, 단일 상속, 생성자 호출 등)
6.추상 클래스를 상속받는 클래스는 추상 메소드를 반드시 오버라이딩해야 한다. 오버라이딩 할 때 abstract를 제외한 시그니처를 클래스에서 동일하게 적어줘야 한다.
※abstract 와 interface의 공통점
1.상속을 강제하기위한 규제
→즉 반드시 상속을 해서 사용해야한다.(상속을 강제한다)
2.추상메소드들은 오버라이딩을 반드시 해야한다.
3.추상메소드는 구체적인 로직을 담고있지않고, 시그니쳐만 가지고 있다.
4.abstract와 interface를 사용하는 사용자의 의도
추상 클래스,인터페이스 → 상호간의 공통적으로 약속한 부분을 기입
상속(implements,extends)받는 하위 클래스 → 상황에따라 달라지는 부분을 기입
5.객체를 못만든다.
→인터페이스는 생성자가 없으므로, 객체를 생성 할 수 없다.
→추상클래스는 생성자를 만들 수 있으나, 상속을 위한 클래스이기 때문에 필드에 따로 객체를 생성할 수 없다.
인터페이스는 뼉다구만 설계해놓고 외부에선 그 인터페이스를 바라보게 해서 결합도를 줄이는 역할 추상클래스는 그냥 진짜 말그대로 만들어진 기능에 ++하는게 전부임
추상클래스를 인터페이스처럼 그냥 외부 파일로만들고 그걸가지고 바라보게만들면 결국은 인터페이스와 똑같은거아닌가? 패키지내에나 외부패키지내의 추상클래스를 임포트한다는개념으로
내부 구현체가 그대로 상속되는데 어떻게 결합도가 낮아지겠어 구현 여부가 핵심임 한 두개의 클래스만 생각하지말고 수백 수천개가 서로 상속되고 있고 서로 인터페이스된다고 생각을 하면 쉬울듯?
인터페이스로 다중상속하면, 결합도가 줄어드는것에 있어서는 좋은것은 맞네, 다중상속이 핵심인듯
가장 많이 얘기하는건 다중상속인데 지금 생각에는 그것보다는 composite랑 인터페이스 상속으로 각각의 장단점이랑 각각 지향하는 코드를 말하는게 더 높은 의미를 가져올듯
composite랑 인터페이스 상속으로 각각의 장단점은 위에 설명되있는게아님? 각각 지향하는게 머겠음?
둘다 지향하는것은 공통된 내용(필드나메소드)들을 추출하여 통일된 내용으로 작성하도록 규격화하는 것
님이 생각하는 거랑은 다른 내용인데, 인터페이스로 핵다귀 설계해놓고 현업에서 함? 아직 취준생이라 사실 설계대로 했을 때의 생각은 기획자분이나 수주주시는 분들의 의견이 바뀔 가능성이 있어서 특정 로직에 대해 쓰는 건 좀 부정적임.. 애너테이션이나 클래스를 위해 쓴다던가 제공한다던가 하는건 긍정적인..생각이랄까? 물론 바뀔 염려가 없는 코드면 default 인터페이스가 좋다고 봄 테스트코드가 짜기도 좋고, 메타 프로그래밍으로 해당 구조가 어떤 구조구나 하고 파악이되니까. 틀만 제공했을 때는 위와 동일
바뀔 염려가 없는 코드는 예를 들면 개발자들을 위한 코드 ex) 에러 검증 같은거 ㅇㅅㅇ
전에 프갤에서 25년차 개발자분이랑 카카오 개발자분이랑 대화를 해봤는데 내가 놓친 부분도 있을 수 있겠지만, 대화를 간단하게 나눠봤을 때 저정도의 답변을 얻었음
대신에 인터페이스에 대해 어떻게 정의했는지 명세서에 적혀있어야겠지 ㅇㅅㅇ 예를 들어, 인터페이스 default 메소드를 사용하면 이건 override해서 코드를 바꾸지 않는다 같은 composite와 나름의 분리?
생각해보니 abstract랑은 상관없는 내용이네 ㅇㅅㅇ abstract와의 차이점은 인터페이스 용도로 쓰거나 STATIC 변수 값으로 쓰이는걸로 알음
아니면 JPA 쓸 떄는 애너테이션으로 데이터 이용할 때 default 메소드 인터페이스 허용을 안해서 이 경우 방금과 같이 검증의 이유로 확장 가능성이 없으면 롬북 함수 용도로 쓰겠지
나중에 읽어보면서 생각좀해보겠음. composite는 복합체 패턴말하는거임?
@getter @setter 이런거
몰라 그냥 ㅇㅅㅇ 이정도면 찾아봐야지
다른 클래스로 데이터 접근하는거 composite패턴이랑은 다름
DI IOC 찾아봐
공부해야 늘음 ㅇㅅㅇ
ㅇㅇㄳ