[상속]
🍗 공통된 부분을 하나로 합쳐 재사용할 수 있다면, 중복이 제거되며 코드가 한결 간결해질 것이다. 이것이 상속의 목적이다. 공통 부분을 extends 키워드를 써 상속(확장)해서 사용한다. 여러 클래스를 물려받는 다중 상속은 안 된다.
포함관계와는 차이가 있다. 다형적 표현이 가능해야 상속관계이다. 콜라(하위)는 음료수(상위)이다. 라고 말할 수 있어야 한다. 엔진은 자동차이다.(X) 이는 포함관계라고 볼 수 있다.
super는 부모(상위)클래스 객체를 뜻한다. 내가 extends하고 있는 클래스의 주체이다. super()는 그 상위 클래스의 생성자를 호출한다. 용법은 this()와 같다. 바라보는 객체가 다를 뿐이다. 생성자 안에서만, 맨 첫줄에 적어야만 사용가능하다.
실무에서 상속이 어떻게 사용되는지 궁금했다. 지금 와서 생각해보면 예전 작업했던 프로젝트에 중복되는 코드가 엄청 많았던 것 같은데 그걸 상속, 추상화와 다형성을 이용해서 리팩토링을 진행해봤으면 좋았겠다는 생각이 든다. 옛날부터 "상속"이라는 걸 학습할 때면 꼭 Animal - Cat 야옹 Dog 멍멍 이렇게 진행했었는데 항상 딱 거기서 끝난다. 상속이 뭔지는 알겠는데 써보라 하면 정작 적용하지 못한다. 연습해야지..
[캡슐화]
🍗 특정 객체의 속성, 기능을 캡슐에 가두어 데이터를 보호하고 쓸데 없이 노출되는 것을 막는다. 그래야 함부로 속성이나 기능을 변경하는 일이 없을 것이고, 다른 객체로 악영향을 끼치는 일이 없을 것이다.
public이라는 접근 제어자가 붙은 멤버는 어디서나 사용가능 하다. protected는 다른 패키지의 하위클래스까지, default는 동일 패키지, private를 사용하면 동일 클래스에서만 접근 가능하도록 보호된다. 이렇게 private로 보호된 필드에 외부에서 접근하기 위해서는 getter와 setter를 사용한다.
네 가지 특성 중 제일 이해하기 수월했고 익숙한 챕터였다. 새로 알게 된 사실이 있다면, 도대체 캡슐화를 해서 누구한테 노출한다는 걸 방지한다는 거지..;; 숨기라니 숨겨야겠다 라는 생각을 항상 해왔었는데(ㅋㅋ) 객체 내부와 외부를 철저히 분리하자고 생각하게 되었다. 제대로된 캡슐화에도 도달해보지 못 한 것 같다. 내부 변경으로 인해 외부에도 수정이 일어나지 않도록 열심히 모으고 감싸기!!
[다형성]
🍗 상위 클래스 타입의 참조변수로 하위 클래스들의 객체를 참조할 수 있도록 만들어준다. 상위 클래스 타입에서 하위 클래스로 형변환 하는 경우가 다운캐스팅, 그 반대가 업캐스팅인데, 업캐스팅이 선행되어야만 다운캐스팅이 가능하다. 알쏭달쏭 형변환. 현재 타입(A)이 어떠한 타입(B)과 상속관계가 있는지 알아야 캐스팅이 가능하다. 캐스팅 가능여부를 알아보기 위해 instanceof 연산자를 사용한다. A instanceof B. B의 타입이 A와 같거나 그 상위 클래스 타입인 경우에만 true, 그 외 (형제도 안 된다) false이다.
업캐스팅과 다운캐스팅.. 객체의 특성을 살리고 또 공통으로 묶어주고 (복작복작)... 무튼 다운캐스팅을 하는 경우는 어떤 경우인가? 라는 질문에 대답을 잘 못 하겠다. 참조하는 객체가 아닌 객체 자체의 타입에 따라 메모리에서 객체에 접근하는 순서가 다른 것과 관련이 있는 걸까? 포스팅 마치고 공부해서 추가해두어야겠당. 정리하면서 궁금해졌는데 왜 Child 객체를 생성해서 Parent 타입으로 할당해놓았을 때 메서드는 Child 객체에 먼저 접근하는데 변수는 Parent에 먼저 접근하는 걸까?
[추상화]
🍗 클래스들의 공통성을 모아 상위클래스를 만들어내는 것. 만들어진 추상 클래스는 적어도 한 개의 추상 메서드를 가지고 있다. 이 추상 클래스를 상속받은 클래스는 추상 메서드를 오버라이딩하여 구현한다.
인터페이스는 추상클래스보다 추상성이 더 높다. 추상 메서드와 상수만으로 이루어진다. 인터페이스를 확장하여 구현하기 위해서는 'implements' 키워드를 사용한다. 정의된 모든 추상 메서드를 구현해야 한다. 다중 상속이 안되는 것과 달리 인터페이스는 다중구현 할 수 있고, 상속(extends)와 함께 사용할 수도 있다.
기능과 역할을 분리시켜주는 것이 가장 큰 포인트. 그래야 코드에 변화가 있어도 변경하는 데 번거로움이 적다. 결합도 낮춰주기.
추상 클래스와 인터페이스를 구분해서 사용하는 게 아직 어렵다. 결국 정의된 메서드를 확장/구현해서 사용하면 결과는 같은데 언제 인터페이스가 알맞고 언제 추상클래스가 맞는 건지를 공부해야 한다. 추상화와 다형성의 관계는 한 마디로 표현하기 어려웠다. 실습을 하면서는 다형성을 활용해 한 타입으로 구분지어 배열로 관리할 수 있어서 편리했는데, 그게 질문이 묻고자 하는 의도가 맞는지 선뜻 답하기 어려웠다.
🥗 Unit 8. [Java] 객체지향 프로그래밍 심화를 마치고!
객체지향에서 가장 중요하지만 가장 어려운 사대장이 시작됐다. 그와 함께 나도 코로나에 감염되었다. 정말 내 인생 가장 아쉬운 순간 TOP5 안에 들 것이다. 이럴 거면 더 더 앞에서 걸리면 좋았을텐데....^ㅡㅠ
어찌어찌 진도는 따라잡았어도 그 시간에 더 많이 실습하고 익힐 수 있었을텐데 싶다. 내 조급한 마음도 한 몫 하는 것 같다. 그럴 필요가 전혀 없는데 말이다.. 아주 중요한 내용이다보니 더 그런가보다.
그래도 무엇보다 중요한 건, 프로그래밍을 하면서 이번 유닛의 내용을 항상 신경써야할 것이라는 점이다. 변화에 잘 대처할 수 있는, 낮은 결합도와 높은 응집도를 가진 멋쟁이 프로그램을 완성할 수 있느냐의 시작은 여기에 달려있을텐데. 전혀 익숙하지 않다보니 어렵기만 하다.😵💫벌써부터 고민해야 할 문제가 맞을까 싶은 마음도,, 충돌하고 있다ㅋㅋ
지금껏 가장 어려운 회고 작성이었따. 분명히 모든 내용이 이론적으로는 이해가 갔는데... 뭔가 실제로 사용한다거나 본격적으로 활용하기 어려운 느낌이다. 연습을 많이 해서 익숙해지는 게 필요할 것 같다. 이번 실습 코드에서도 상속과 추상화를 많이 사용했는데 열심히 곱씹어봐야겠다. 객체지향 프로그래밍 심화 회고 끝.
'공부기록 > 유닛 회고' 카테고리의 다른 글
S1U10 [Java] 심화(Effective) 회고 (2) | 2022.11.16 |
---|---|
S1U9 [Java] 컬렉션(Collection) 회고 (0) | 2022.11.15 |
S1U7 [Java] 객체지향 프로그래밍 기초 회고 (0) | 2022.11.12 |
S1U6 [Java] 기초 회고 (0) | 2022.11.10 |
S1U4 [Linux] 회고 (0) | 2022.10.31 |
댓글