protected의 핵심을 요약하자면 아래와 같다.

 

접근제어자가 protected로 설정되었다면, 동일 패키지의 클래스 또는 해당 클래스를 상속받은 다른 패키지의 클래스에서만 접근이 가능하다.

 

 

public vs protected 

 

public은 외부에서 접근할 수 있지만 protected는 외부에서 접근할 수 없다.

 

어떻게보면 public와 protected는 비슷하다고 볼 수 있다.

 

protected는 원하는 클래스의 메소드를 직접 instance를 만들어 사용할 순 없지만, 상속 관계가 되는 경우

자유롭게 이용이 가능하기 때문이다.

 

그럼 오직 외부에서의 접근을 막기 위해 protected를 써야 하는지에 대한 궁금증이 생겼기에

구글링을 통해 OOP에서의 protected의 역할을 찾아봤다.

 

protected는 잠재적으로 자식 클래스가 오버라이드(Override)해서 바꾸어야 할 경우를 고려한 접근제어자이다.

아래의 새(Bird) 코드와 타조(Ostrich)클래스 예시를 보자

 

public class Bird {

    void fly() {
        System.out.println("I am flying");
    }

    protected void moveFast() {
        fly();
    }
}

 

public class Ostrich extends Bird{
    public static void main(String[] args) {
        Ostrich ostrich = new Ostrich();
        ostrich.moveFast();
    }

    void run(){
        System.out.println("I am running");
    }
    protected void moveFast(){
        run();
    }
}

 

타조는 Bird 클래스를 통해 moveFast() 메서드를 상속받았지만 다른 새들과 달리 fly()를 사용할 수 없기에

불가피하게 moveFast()를 오버라이드를 통해 변경해야 한다. 따라서 변경이 짐작되는 메서드는 protected를 통해 변경의 요지를 표시하는 용도로 사용될 수 있다.

 

Object, Clonabel인터페이스, clone()메서드

 

위 사진은 Object에서 사용할 수 있는 메서드 종류이다. clone, finalize 메서드는 protected 접근제어자를 가진다.

 

finalize메서드는 Deprecated 

 

Clonabel 인터페이스(믹스인 용도) : 일반적인 인터페이스랑 다르다. 아무 내용이 없다, clone()메서드의 동작방식을 결정한다. (믹스인 : 객체지향에서 다른 클래스에서 사용할 목적으로 만들어진 클래스) Clonable 인터페이스를 구현하지 않은 상태에서 clone()를 호출하면 CloneNotSupportedException을 던진다.

 

기본적인 사용법은 clone()를 사용하려는 클래스에서 Clonable 인터페이스를 구현하고, clone()를 오버라이딩 해서 사용한다.

 

왜 clone()를 오버라이딩 해야하냐

아래의 블로그를 참조하자 아직 헷갈린다.

 

https://cinnamonc.tistory.com/273

 

[Java 공부하기] clone 메소드를 오버라이딩 해서 사용해야하는 이유에 대해서 찾아보기

clone 메소드를 공부하다가 멘붕이 와서 한번 정리하기로 했다. 일단 clone 메소드는 Object의 메소드이며, 접근수준 지시자는 protected이다. 이 clone 메소드를 다른 클래스에서 사용하려면 Cloneable 인

cinnamonc.tistory.com

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=2feelus&logNo=220576845725 

 

Java에서 protected 의 의미와 용도

1. Java의 접근자(modifier)들 Java 의 필드와 메소드들에 대한 접근 권한 제어를 modifier라고 한다.&nb...

blog.naver.com