🌈 [Section1] 14. 객체지향 프로그래밍4

📕 오늘 배운 내용!

• 객체 지향의 4가지 원리 중 다형성 / 추상화

---

✏️ 다형성 (polymorphism)

• 상위 클래스 타입의 참조변수를 통해서 여러 타입의 하위 클래스 객체들을 참조할 수 있도록 만든 것
• 메서드 오버라이딩과 메서드 오버로딩 또한 다형성의 한 예시

✔ 타입 변환(캐스팅) 조건

조건 (1) 상속관계
서로 상속관계에 있는 상위 클래스 - 하위 클래스 사이에만 타입 변환이 가능
조건 (2) 오버라이딩 필수
하위 클래스 메서드가 반드시 재정의 되어있어야 함
조건 (3) 업캐스팅일 때 형변환 연산자 생략 / 다운캐스팅일 때 형변환 연산자 꼭 명시

• 업캐스팅 - 하위 클래스의 객체 주소를 상위 클래스 타입으로 타입 변환하는 것
  👉 형변환 연산자(괄호)를 생략 가능

• 다운캐스팅 - 상위 클래스의 객체 주소를 하위 클래스 타입으로 변환하는 것
  👉 형변환 연산자(괄호)를 반드시 적기

⚠️ 다운캐스팅은 이전에 업캐스팅이 최소 한번 이상 실행되었을 경우에만 가능 !! )
상위클래스를 하위클래스로 바로 다운캐스팅은 불가능 !! )

---

아래 두 코드에서 Friend가 상위클래스 / 각각 BoyFriend, GirlFriend가 하위클래스라고 할 때,

• 1, 2번 - 객체 타입과 참조변수의 타입이 일치하므로 당연히 캐스팅이 가능

• 3번 - 객체와 참조변수의 타입이 일치하지 않음 ( 업캐스팅 )
  👉 GirlFriend라는 하위클래스의 객체를 상위클래스의 Friend 타입으로 지정해 준 것이므로
  GirlFriend 객체가 Friend 타입의 객체로 취급되기 때문에 GirlFriend 클래스 안의 필드/메서드는 접근할 수 없게 되고 상위클래스의 Friend의 멤버에만 접근 가능
  ( 하위클래스의 많은 기능들을 상위클래스로 취급함으로 인해 줄여준다고 생각하기 )

• 4번 - 상위클래스의 객체를 하위클래스 타입의 참조변수로 지정해주는 것은 불가능

• 5번 - 객체와 참조변수의 타입이 일치하지 않음 ( 다운캐스팅 )
  👉 Friend라는 상위클래스의 객체가 저장된 참조변수 자체를 GirlFriend라는 하위클래스의 타입으로 타입 변환하여 freind2에 할당
  But, friend2라는 참조변수 타입이 이전에 업캐스팅을 해준 상태가 아니기 때문에 상위 -> 하위 클래스로 바로 다운캐스팅 하면 오류!!
  

• 1번 - 객체 타입과 참조변수의 타입이 일치하므로 타입 변환 필요 X

• 2번 - 상위클래스를 하위클래스로 업캐스팅 해주는 경우 (타입변환) 생략 가능

• 3번 - 하위클래스를 상위클래스로 다운캐스팅 해주는 경우 (타입변환) 꼭 명시 해줘야함

• 4번 - 상속관계가 아니므로 타입 변환 불가 👉 에러 발생

( ⚠️ 캐스팅되는 우항 부분이 모두 참조변수라는 것을 헷갈리지 않기!!! ⚠️ )

---

✔ instanceof 연산자

참조변수의 타입 변환, 즉 캐스팅이 가능한 지 여부를 boolean 타입으로 확인할 수 있는 자바의 문법요소

참조_변수 instanceof 타입

👉 앞에 있는 참조변수가 뒤에 있는 인스턴스 타입에 포함되는가?

• 리턴 값이 true --> 타입 변환 가능
• 리턴 값이 false --> 타입 변환 불가능
  ( 참조 변수가 null인 경우에는 false 반환 )
  (뒤에 오는 타입은 자신의 객체 타입 또는 자신의 상위 클래스의 객체 타입이여야 함)

소스 코드가 길어져서 많은 생성 객체들의 타입을 확인하기 어려울 경우에 instanceof 연산자 사용하여 캐스팅 여부를 확인해서 에러를 최소화할 수 있음

---

아래 두 코드에서 Animal이 상위클래스 / 각각 Cat, Bat가 하위클래스라고 할 때,

• 1-1번 - 참조변수 a가 참조하고 있는 Animal 인스턴스 타입이 최상위 클래스 Object에 속하기 때문에 true

• 1-2번 - 자신의 인스턴스 타입이므로 true

• 1-3번 - 참조변수 a가 참조하고 있는 Animal 인스턴스 타입이 하위클래스 인스턴스 Bat에 속하지 않기 때문에 상위 -> 하위 로 변환은 안돼서 false
  (이전에 업캐스팅을 하지 않았기에 바로 다운캐스팅이 안됨)

• 2-1번 - 참조변수 b가 참조하고 있는 Animal 인스턴스로 취급받는 Cat 인스턴스가 최상위 클래스 Object에 속하기 때문에 true

• 2-2번 - 참조변수 b가 참조하고 있는 Animal 인스턴스로 취급받는 Cat 인스턴스가 상위클래스 Animal에 속하기 때문에 true

• 2-3번 - 참조변수 b가 참조하고 있는 Animal 인스턴스로 취급받는 Cat 인스턴스가 자기 자신의 타입 Cat과 동일하기 때문에 true

• 2-4번 - 상속관계가 아니므로 b 참조변수가 Bat 이라는 객체 타입에 속하지 않아 false

💥💥 여기서 내가 헷갈렸던 점!! 💥💥
⠀
✔️ 1-3번 - 다운캐스팅이 있는데 왜 false 일까?
👉 instanceof 연산자는 인스턴스 타입의 포함관계를 집중적으로 보기 때문에 참조변수의 형변환과 관련이 없음! 따라서 다운캐스팅도 물론 안되고 상위 -> 하위클래스로 타입 변환도 불가!
⠀
✔️ 2-3 - 참조변수 cat의 인스턴스 타입을 Cat 으로 취급해서 true일까
아니면 Cat 객체가 Animal 타입의 객체로 취급 되어서 true일까?
👉 하위클래스 Cat 객체를 상위클래스 Animal타입 객체로 취급하는 것! 상위->하위 변환은 불가이기 때문에 전자는 불가능
⠀
✔️ 2-3 - 위에서 Cat 객체를 Animal 타입 객체로 취급한다고 했는데 그러면 Animal b = new Cat(); == Cat b == Cat(); 둘이 같은 것일까?
👉 참조변수 b가 모두 같은 Cat 객체를 포함하고 있음
다만 여기서 둘의 다른 점은!!
전자는 하위클래스 Cat이 상속받은 멤버(필드,클래스) + 자기 자신만의 멤버를 가지고 있을텐데 Cat을 상위클래스인 Animal 타입 객체로 타입을 변환할 경우, 자기 자신만의 멤버는 사용이 불가하고 상속받았던 상위클래스의 멤버만 사용이 가능하다
후자는 서로 같은 자기자신이기 때문에 상속받은 멤버 + 자기 자신의 멤버 보두 사용 가능하다

---

✏️ 추상화

• 기존 클래스들의 공통적인 속성/기능들을 뽑아서 상위 클래스를 만들어 내는 것
  ( 상속의 반대라고 생각 )

• 클래스의 상속 순위가 높을 수록 추상화의 정도가 높고 그 아래로 내려갈수록 구체화됨
  ( 상위클래스일수록 더 공통적인 멤버들이 정의되어있고 내려갈 수록 더 구체적인 멤버들이 정의되어있음 )

✔ abstract 제어자

abstract 란? -> 추상적인 -> 충분히 구체적이지 않은 -> 미완성인

abstract class 클래스명 { // 추상 메서드가 최소 하나 이상 포함돼있는 추상 클래스
	abstract void 메서드명(); // 메서드 바디가 없는 추상메서드
}

• 추상 클래스(abstract class)
  -> 추상 메서드를 하나 이상 가지고 있는 클래스
  -> 나머지는 그냥 일반 클래스와 같음
  ( ⚠️ 일반 클래스 앞에 abstract 키워드를 붙이고 추상메서드를 쓰지 않아도 그 클래스는 추상클래스로 분류되어 객체 생성이 불가 )

• 추상 메서드(abstract method)
  -> 메서드 시그니처만 있고 바디가 없는 메서드
  -> 미완성 설계도이기 때문에 메서드 바디가 완성이 되기 전까지 이를 기반으로 객체 생성 불가
  -> 상위클래스에 추상메서드를 넣고 그 값을 상속받는 하위클래스들에 추상메서드를 오버라이딩하여 각각 상황에 맞는 메서드 구현 가능

✔ final 키워드

• 클래스 앞에 붙는 경우
  -> 변경/확장 불가능한 클래스, 상속 불가

• 메서드 앞에 붙는 경우
  -> 오버라이딩 불가

• 변수 앞에 붙는 경우
  -> 값 변경이 불가한 상수

셋 모두 공통적으로 final 제어자가 추가되면 변경이 불가능하고 확장할 수 없다

✏️ 인터페이스 (interface)

• 추상클래스 보다 추상화 정도가 더 높은 가장 기초적인 “밑그림"
• 추상 메서드와 상수(final)만 멤버로 가진 클래스 (간단히 말해 추상메서드들의 집합)

❗ 추상클래스와 인터페이스의 차이알아두기!!

[ 기본 구조 ]

• class 키워드 대신 interface 키워드를 사용
• 내부의 모든 필드가 public static final로 정의
• static과 default 메서드 이외의 모든 메서드가 public abstract로 정의
  (그러나 이는 일부 또는 전부 생략 가능)

[ 인터페이스 구현 ]

그 자체로 인스턴스를 생성 불가, 메서드 바디를 재정의하는 구현 클래스를 따로 작성해야함
(like. 추상메서드들을 재정의한 하위클래스들)

➜ implements 키워드 사용해서 인터페이스 구현 ( 메서드 재정의 )

❗ 인터페이스끼리는 extends 할 수 있고, 클래스에 구현하려면 implememts

class 클래스명 implements 인터페이스명 {
		... // 해당 인터페이스에 정의된 모든 추상메서드 구현
}

👉 인터페이스에서 바디가 없었던 모든 추상 메서드들을 구현 클래스 내에서 오버라이딩하여 각각 바디를 완성

class 클래스명 implements 인터페이스명1, 인터페이스명2, 인터페이스명3 { 
				...
}

위와 같이 다중 구현 가능

💡 클래스에서 다중 상속이 불가능했었던 이유
➜ 상위클래스에 동일한 이름의 멤버가 존재하는 경우 충돌이 발생하기 때문

But, 인터페이스 - 애초에 미완성된 멤버를 가지고 있기 때문에 충돌이 발생할 여지가 없고, 따라서 안전하게 다중 구현이 가능

class 클래스명 extends 상위클래스명 implements 인터페이스명 { 
				...
}

위와 같이 다른 클래스 상속과 인터페이스 구현을 동시에 하는 경우도 있음

[ 인터페이스의 장점 ]

• 선언 / 구현을 분리시켜 개발시간 단축

• 역할과 구현을 분리시켜 사용자 입장에서는 복잡한 것과 상관없이 해당 기능을 사용 가능

• 독립적인 프로그래밍 -> 코드 변경의 번거로움 최소화 / 한 클래스 에서의 변경이 다른 클래스에 미치는 영향을 최소화할 수 있음

  Ex. a클래스가 b클래스를 의존하고 있을 때(모든 속성 기능이 b클래스를 호출한 것일 때), b 클래스 멤버의 이름이 변경될 경우 모두 일일이 바꿔야함
  ⠀
  👉 인터페이스를 만들어서 b클래스에서 구현하고, a클래스의 매개변수를 인터페이스를 받도록 설정하면 b클래스가 변경되어도 변경된 멤버들이 자동으로 인터페이스에 가게되고 그 매개변수를 받는 a클래스도 자동으로 수정되어 출력

---

✏️ 객체 지향 설계 원칙 SOLID

( 좀 더 유지보수하기 쉽고, 유연하고, 확장이 쉬운 소프트웨어를 만들기 위한 원칙 )

✔️ SRP (S)

• 단일 책임 원칙 (Single responsibility principle)

• 클래스가 제공하는 기능들은 하나의 책임을 수행하는데 집중해야 한다는 원칙

• AOP는 별도의 부가 기능을 핵심 로직에서 분리했기 때문에 SRP의 원칙을 지킨 방식이라고 할 수 있음

  Ex. Hyunju 라는 클래스가 있다면, 역할별로 나누어서
  친구의 역할 / 딸의 역할 / 직원의 역할 / 학생의 역할 등

[ SRP를 잘 지킬 경우 ]

• 응집력이 높아지고, 결합도는 낮아짐

• 코드 가독성도 좋아짐

• 테스트 범위도 작아짐
  ➜ 유지보수 편해짐

✔️ OCP (O)

• 개방-폐쇄 원칙 (Open/closed principle)

• 확장에는 열려있고(Open), 변경에는 닫혀 있어야 한다(Close)는 원칙
  ( 변하는 기능은 Open, 변하지 않는 기능은 Close )

• 변하지 않는 기능은 용이한 확장과 수정을 위해 인터페이스를 통해 느슨하게 의존하게 만들어야 한다

  Ex. Car이라는 객체가 있다면,

  • 변하지 않는 동작
    ➜ 움직이는 것
  • 변하는 동작
    ➜ 수동 모드, 오토메이션 모드, 크루즈컨트롤 모드 등

✔️ LSP (L)

• 리스코프 치환 원칙 (Liskov substitution principle)

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다는 원칙

• 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다
  ( 특정 메소드가 상위 타입을 인자로 사용한다고 할 때, 그 타입의 하위 타입도 문제 없이 정상적으로 작동을 해야 한다 )

• OCP 원칙의 기반이 된다고 생각됨

✔️ ISP (I)

• 인터페이스 분리 원칙 (Interface segregation principle)

• 일반적인 하나의 인터페이스를 조금 더 구체적인 인터페이스로 쪼개는것이 낫다는 원칙

  Ex. 사람의 행동에서 (일반적인 하나의 인터페이스)

  • 걷기 (구체적인 인터페이스)
  • 말하기 (구체적인 인터페이스)
  • 뛰기 (구체적인 인터페이스)
    등

✔️ DIP (D)

• 의존관계 역전 원칙 (Dependency inversion principle)

• 자주 변경되는 기능은 구체 클래스에 의존하지 않고, 추상화(일반화) 된 클래스에 의존하는 것을 의미

• 구체 클래스가 추상 클래스에 의존하므로 의존 관계가 역전된 형태

• 의존성 주입이 이 원칙을 따르는 방법 중 하나

[참고] https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)

---

🌈 느낀점

오늘은 다형성에서 타입변환 부분이 제일 헷갈리고 이해도 잘 안돼서 원래 궁금한 것은 빨리 풀고 넘어가야 직성이 풀리기에 점심도 못먹고 계속 찾아보면서 공부했고 그래도 이해가 안되는 부분은 줌 세션에서 질문하여 좀 더 이해할 수 있도록 했다 !
아직까지 100% 이해가 된 건 아니지만 내일 정리할 수 있는 시간이 있으니 내일 객체지향 관련해 다 복습해야겠다!!