(원본 : 합쥐(hab__g) 작가님 이모티콘. 작가님께 수정 및 사용 허락을 받았습니다!🥰)
원래는 수저 위에 한살 이라고 써있지만 나이 먹는것 보다 자바가 더 힘드니까 조금 수정해 보았습니다(???)
객체지향 Part2 - 드디어 나왔다. 상속, 오버라이딩, 캡슐화, 다형성, 추상 클래스, 인터페이스...(너무 많이 나왔는데)
오버라이드가 대체 뭐에요? -> 가져와서 덮어쓰기.
오버로딩과 비슷하면서도 아닌듯. 사실은 다른 애입니다.
-
오버로딩은 - 한 클래스 안에 이름이 같은 메서드를 여러개 정의하는 것.
-> 왜 써요? : 입력 값은 다르지만 기능은 같은 경우가 많을 때.
특징 : extends나 implements가 필요없다. 보통 생성자를 여러개 쓸때 사용하는 방법이기 때문. -
오버라이딩은 - 메서드를 상속 받아와서 내가 원하는대로 덮어버리는 것.
인터페이스? - 추상 메서드의 묶음. 가장 간단한 문법. 특정 기능이 필요하지만 내용은 반드시 달라져야만 할 때
자바 문법 뽀개기에서, 인터페이스는 '특정 동작이 필요할때' 사용하는 것이라고 했다.
접근제어자, return type, method 이름만 선언하고 내용은 없다고. 그래서 '가장 간단한 문법' 이라고 표현한 바 있다.
얼마나 간단하냐면, ↓이렇게 써도 인터페이스 선언 끝임.
interface myInter {
void myinter(int x);
}-> 인터페이스는 추상 클래스와 마찬가지로 구현부(몸통. 중괄호 부분)가 비어있어서, 반드시 상속해서 자식 클래스에서 구현해줘야 한다.
그래서 인터페이스를 상속받는 클래스는 반드시 그 상세내용을 담고 있어야 한다고.
- 모든 멤버가 public임!
- 상수(리터럴 말고) 이외의 변수는 가질 수 없음!
-> 위 두 가지를 종합해보면, 인터페이스의 변수는 항상 public static final 이 붙어서 선언될 것!
인터페이스랑 추상클래스의 비슷한 점?🤔
- 둘 다 몸통이 거의 비어있다. 자세한 내용이 없이 대충 선언만 툭 되어있음.
- 그래서 밑에서 상속받아서 상세내용을 구현해줘야 한다.
인터페이스와 추상클래스의 다른 점😎
- 추상클래스는 한 클래스밖에 상속 못받지만, 인터페이스는 여러개를 implements 해서 받아올 수 있다.
-> (예를 들면 class character implements armor, weapon, skill, bag 등등 여러가지를 받아올 수 있을것!) - 추상클래스 안에는 추상 메소드만 존재해야 하는건 아닌데, 인터페이스 안에는 무조건 추상 메소드만 있어야 한다. (인터페이스 자체가 추상 메소드의 집합체라서!)
-> 그래서 인터페이스 안의 메서드는 항상 public abstract 메서드이름(매개변수); 형식으로 되어있다.
오늘의 기술매니저님 팁 - JAVA는 원탑인 버전이 있다. 바로 8.
- 동현 기술매니저님의 팁 - JAVA가 대대적 변화를 보인건 버전 8부터. 8과 다른 버전의 차이점을 알아두면 좋을 것.
-> 그러고보니 자바 8과 11이 가장 많이 쓰인다고는 들었는데(지금 자바는 20 언저리 버전까지 나왔던데),
8과 11의 LTS 종료일이 비슷하다는 것도 들었다.
어제 느슨한 결합이며 시간복잡도며 이래저래 썼는데 날아갔다... 저장도 됐고 수정도 했다고 생각했는데... 울어도 되나😭
느슨한 결합이 뭔가요 - 내가 아는건 원자간 결합의 파이 시그마 뿐인데
- 클래스 내부에 메서드를 직접 구현하는 대신, 인터페이스를 사용함으로써 객체간 결합을 느슨하게 만들 수 있다.
-> '아니 그러니까 강함이고 느슨이고 뭔소린데? 전기음성도라도 가지는거야 뭐야' 라는 생각이 들 수 있다.
<느슨한 결합을 공부할 때 주의할 것>
인터페이스를 사용하면 느슨한 결합을 만들 수 있다고 해서 '상속은 결합을 느슨하게 만드는구나' 라고 생각하면 안된다. 오히려 상속은 일반적으로 결합을 강하게 만든다. 없던 관계를 만들어서 끌어와 사용하기 때문.
-> 인터페이스가 특성상 메서드의 몸통부가 구현되어 있지 않기 때문에, 내부 내용이 없어서 끌어다가 필요한 것을 수정하면 되기 때문에 결합을 느슨하게 만들 수 있는 것이다.
-
어떤 메서드를 클래스 내부에 직접, 한번에 모든걸 와장창 다 구현해서 때려넣어 놓은 상태라면, 단순한 기능 하나만 고치는데도 여기저기 연쇄적으로 수정해야 할 가능성이 높다!
-> 이걸 '강한 결합'이라고 한다. 뭐 하나를 바꾸려면 그걸 '뜯어내야' 하는 수준인 관계의 코드일 때. -
JAVA 5일차 내용에도 나오지만, 이를테면 계산기 클래스 하나 안에 모든 기능을 다 넣어놓아서 하나 수정할 때 다른것도 다 열어재껴야 한다면 SOLID 원칙도 두루두루 위반해주고 있는 총체적 난국이 된다.
-> 일단 이런 계산기라면 SRP도 위반하고 OCP도 자동적으로 위반하게 된다.
- 단일 책임이 아닐 뿐더러(왜 사칙연산의 모든 책임을 한 녀석에게 몰빵시켰는가!?),
- 나의 확장에는 열려있고 주변의 변화에는 닫혀있는 형태도 아니다. 주변의 변화때문에 뜬금없이 열리기도 하고, 나는 확장되지 않는 상황이다.
예를 들어 고장난건 8층의 서버인데, 이거 하나 고치는데 5층 총무과 들르고 7층 랜선함 들러야 한다면 유지보수 난이도도 높고, 안정적인 구조가 아니다.
