인프런 실전 자바 기본편(3)

공부 내용을 정리하고 앞으로의 학습에 이해를 돕기 위해 작성합니다.

 

자바 기본 편 강의를 완강했다. 

오늘 공부한 내용을 정리해 보겠다.

 

final

1. 변수에 final 키워드가 붙으면 값을 변경할 수 없다.

2. 대문자 사용, 구분은 _ (언더스코어) (관례)

3. 필드를 직접 접근해서 사용

4. 참조형 변수에 final이 붙으면 참조 대상은 변경 불가 But 참조 대상의 값은 변경 가능

출처 - 인프런 실전 자바 기본편 (김영한) 강의

상속

 

특징

1. extends 대상은 하나만 선택할 수 있다.

2. 자바는 다중 상속을 지원하지 않는다. (다이아몬드 문제)

3. 상속 관계를 객체로 생성할 때 메모리 구조

출처 - 인프런 실전 자바 기본편 (김영한) 강의

- 부모 클래스, 필드, 메서드 모두 포함해서 생성된다.

- 외부에서는 하나의 인스턴스를 생성하는 것 같지만 내부에서는 부모와 자식이 모두 생성되고 공간도 구분된다.

- 호출하는 변수의 타입(클래스)을 기준으로 어떤 메서드를 호출할지 결정한다.

- 호출하는 타입이 ElectricCar인데 move()를 호출하면 부모 메서드를 호출한다.

- 만약 부모에서도 찾지 못하면 더 상위 부모에서 필요한 기능을 찾는다.

- 상속 관계의 객체를 생성하면 부모와 자식이 모두 생성된다.

 

오버라이딩

1. 상속받은 기능을 자식이 재정의 하는 것

2. @Override

• @이 붙은 부분을 애노테이션이라 한다.
• 프로그램이 읽을 수 있는 특별한 주석이다.
• 조건을 만족시키지 않으면 컴파일 에러를 발생시킨다.
• 실수로 오버라이딩을 못하는 경우를 방지

3. 오버 로딩 : 메서드 이름이 같고 매개변수(파라미터)가 다른 메서드를 여러 개 정의하는 것

4. 메서드 오버라이딩 조건

• 메서드 이름이 같아야 한다.
• 메서드 매개변수(파라미터)의 타입, 순서, 개수가 같아야 한다.
• 반환타입이 같아야 한다. 단, 반환 타입이 하위 클래스 타입일 수 있다.
• 접근 제어자가 상위 클래스의 메서드보다 더 제한적이어서는 안 된다.
• 상위 클래스의 메서드보다 더 많은 체크 예외를 throw로 선언할 수 없다.
• static, final, private 키워드가 붙은 메서드는 오버라이딩 될 수 없다.
• 생성자는 오버라이딩 할 수 없다.

접근제어

<UML 표기법>

•  + : public
•  # : protected
•  ~ : default
•  - : priate

<접근 제어자의 종류>

• private : 모든 외부 호출을 막는다.
• default (package-private): 같은 패키지안에서 호출은 허용한다.
• protected : 같은 패키지안에서 호출은 허용한다. 패키지가 달라도 상속 관계의 호출은 허용한다. 
• public : 모든 외부 호출을 허용한다.

순서대로 `private` 이 가장 많이 차단하고, `public` 이 가장 많이 허용한다. `private -> default -> protected -> public`

 

super 

 

<부모참조>

1. 부모와 자식의 필드명이 같거나 메서드가 오버라이딩 되어 있으면 자식에서 부모의 필드나 메서드 호출 불가

-> super 키워드로 부모 참조 가능

 

<생성자>

1. 자식 클래스의 생성자에서 부모 클래스의 생성자는 반드시 호출해야 한다.

2. 생성자의 첫 줄에 super(...)를 사용해서 호출한다.

3. 부모 클래스의 생성자가 기본 생성자인 경우 super() 생략 가능하다.

4. A(부모), B(자식) - 기본 생성자 없음, C(B의 자식) 일 때 C는 super()를 생략할 수 없다.

5. 상속 관계의 생성자 호출은 부모에서 자식 순서로 실행된다.

6. this(...)를 사용하더라도 반드시 한 번은 super(...)를 호출해야 한다.

 

다형성1

 

<다형성 참조>

출처 - 인프런 실전 자바 기본편 (김영한) 강의

1. 부모 타입은 자식 타입을 담을 수 있다.

2. 자식 타입은 부모 타입을 담을 수 없다.

• 참조값을 호출하면 먼저 참조값을 사용해서 인스턴스를 찾는다.
• 인스턴스 안에서 사용할 타입을 찾아야 한다.
• 하지만 상속 관계는 부모로만 찾아서 올라갈 수 있다. 자식 타입에 있는 메서드는 호출할 수 없다.

<다형성과 캐스팅>

출처 - 인프런 실전 자바 기본편 (김영한) 강의

1. 다운 캐스팅을 이용하여 자식타입에 부모타입을 담을 수 있다. 

• Child child = (Child) poly // Parent poly

2. 캐스팅을 한다고 해서 Parent poly의 타입이 변하는 것은 아니다. 참조값을 꺼내고 꺼낸 참조값이 Child 타입이 되는 것이다.

3. 업캐스팅 : 부모 타입으로 변경 / 다운캐스팅 : 자식 타입으로 변경

4. 일시적 다운 캐스팅

출처 - 인프런 실전 자바 기본편 (김영한) 강의

• Parent poly = new Child();
• ((Child) poly).childMethod(); // 괄호를 이용해서 연산 우선순위 변경

<업캐스팅이 안전하고 다운캐스팅이 위험한 이유>

1.  업캐스팅의 경우 객체를 생성하면 해당 타입의 상위 부모 타입은 모두 함께 생성된다.

-> 위로만 타입을 변경하는 업캐스팅은 메모리 상에 인스턴스가 모두 존재하기 때문에 항상 안전하다.

2. 다운캐스팅의 경우 인스턴스에 존재하지 않는 하위 타입으로 캐스팅하는 문제가 발생할 수 있다.

-> 객체를 생성할 때 자식 타입은 생성되지 않기 때문이다.

 

<instanceof>

1. 변수가 참조하는 인스턴스의 타입을 확인할 수 있다.

 

<다형성과 메서드 오버라이딩>

1. 오버라이딩 된 메서드가 항상 우선권을 가진다.

출처 - 인프런 실전 자바 기본편 (김영한) 강의

• poly.method() : 자식인 Child에서 method() 함수가 오버라이드 되어있으므로 Child.method()가 실행된다.
• 자식이 많다면 더 하위 자식의 오버라이딩 된 메서드가 우선권을 가진다.

2. 멤버 변수는 오버라이딩 되지 않는다.

3. 메서드는 오버라이딩 된다.

 

다형성2

 

<추상 클래스>

1. 부모 클래스는 제공하지만 실제 생성되면 안 되는 클래스

2. 인스턴스가 존재하지 않는다.

3. 추상 메서드는 상속받는 자식 클래스가 반드시 오버라이딩 해야 한다.

4. 메서드 앞에 abstract 키워드를 붙인다.

5. 추상 메서드가 하나라도 있는 클래스는 추상 클래스로 선언해야 한다.

6. 순수 추상 클래스 

• 모든 메서드가 추상 메서드인 추상 클래스
• 인스턴스를 생성할 수 없다.
• 상속 시 자식은 모든 메서드를 오버라이딩 해야 한다.
• 주로 다형성을 위해 사용된다.

<인터페이스>

1. interface 키워드를 사용한다.

2. 메서드는 모두 public, abstract이다.

3. 다중 구현(다중 상속)을 지원한다.

4. UML에서 점선을 사용한다. --------->

5. implements 키워드로 구현한다.

6. 클래스, 추상클래스, 인터페이스는 프로그램 코드, 메모리 구조상 모두 똑같다. 모두 자바에서는. class로 다루어진다. 인터페이스를 작성할 때도. java에 인터페이스를 정의한다.

7. 인터페이스는 순수 추상 클래스와 비슷하다.

 

<인터페이스를 사용해야 하는 이유>

1. 제약 

• 인터페이스를 만드는 이유는 구현하는 곳에서 인터페이스의 메서드를 반드시 구현해라는 규약(제약)을 주는 것이다.
• ex) USB 인터페이스는 규격에 맞추어 키보드, 마우스를 개발하고 연결해야 한다. 그러지 않으면 작동하지 않는다.
• 순수 추상 클래스의 경우, 누군가 실행 가능한 메서드를 끼워 넣을 수 있다. 그러면 추가된 기능을 자식 클래스에서 구현하지 않을 수 있고 더는 순수 추상 클래스가 아니게 된다.
• 인터페이스는 모든 메서드가 추상 메서드이기 때문에 이런 문제를 원천 차단할 수 있다.

다형성과 설계

 

<객체 지향 프로그래밍>

1. 프로그램을 객체들의 모임으로 파악하고자 하는 것이다.

2. 프로그램을 유연하고 변경이 용이하게 만든다. -> 대규모 소프트웨어 개발에 많이 사용된다.

 

<역할과 구현을 분리>

1. 역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며 변경도 편리해진다.

2. 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.

3. 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.

4. 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

5. 인터페이스를 안정적으로 잘 설계하는 것이 중요

6. 한계

• 역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생한다.

<다형성의 본질>

1. 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

 

<정리>

1. 다형성이 가장 중요하다.

2. 디자인 패턴 대부분은 다형성을 활용하는 것이다.

3. 스프링의 핵심인 제어의 역전(IoC), 의존관계 주임(DI)도 결국 다형성을 활용하는 것이다.

 

<OCP 원칙>

1. Open for extension : 새로운 기능의 추가나 변경 사항이 생겼을 때, 기존 코드는 확장할 수 있어야 한다.

2. Closed for modification : 기존의 코드는 수정되지 않아야 한다.

3. 확장에는 열려있고 수정에는 닫혀있다.

 

* 전략 패턴 : 디자인 패턴 중 가장 중요한 패턴 / 클라이언트 코드의 변경 없이 쉽게 교체할 수 있다.

 

마무리

자바 기본 강의를 완강했다.

이해가 안 되는 부분은 여러 번 돌려보면서 정리했더니, 예상보다 시간이 좀 걸리긴 했지만 그만큼 값진 시간이었다. 

앞으로는 백엔드 개발자 로드맵에 있는 강의를 차근차근 수강하며 역량을 키워 나갈 계획이다.