Модификаторы доступа, переопределение методов, реализация абстрактных методов

— Я расскажу тебе про «модификаторы доступа». Когда-то я уже рассказывал про них, но повторение – мать учения.

Ты можешь управлять доступом (видимостью) методов и переменных твоего класса из других классов. Модификатор доступа отвечает на вопрос «Кто может обращаться к данному методу/переменной?». Каждому методу или переменной можно указывать только один модификатор.

1) Модификатор «public».

К переменной, методу или классу, помеченному модификатором public, можно обращаться из любого места программы. Это самая высокая степень открытости – никаких ограничений нет.

2) Модификатор «private».

К переменной, методу или классу, помеченному модификатором private, можно обращаться только из того же класса, где он объявлен. Для всех остальных классов помеченный метод или переменная – невидимы. Это самая высокая степень закрытости – только свой класс. Такие методы не наследуются и не переопределяются. Доступ к ним из класса-наследника также невозможен.

3) «Модификатор «по умолчанию».

Если переменная или метод не помечены никаким модификатором, то считается, что они помечены «модификатором по умолчанию». Переменные и методы с таким модификатором видны всем классам пакета, в котором они объявлены, и только им. Этот модификатор еще называют «package» или «package private», намекая, что доступ к переменным и методам открыт для всего пакета, в котором находится их класс

4) Модификатор «protected».

Этот уровень доступа чуть шире, чем package. К переменной, методу или классу, помеченному модификатором protected, можно обращаться из его же пакета (как package), но еще из всех классов, унаследованных от текущего.

Таблица с пояснением:

Есть способ, чтобы легко запомнить эту таблицу. Представь себе, что ты составляешь завещание и делишь все вещи на четыре категории. Кто может пользоваться твоими вещами?

— Если представить, что классы, лежащие в одном пакете, – это одна семья, то очень даже похоже.

— Хочу также рассказать тебе несколько интересных нюансов насчет переопределения методов.

1) Неявная реализация абстрактного метода.

Допустим, у тебя есть код:

class Cat {
    public String getName() {
        return "Васька";
    }
}

И ты решил унаследовать от него класс тигр и добавить новому классу интерфейс

class Cat {
    public String getName() {
        return "Васька";
    }
}

interface HasName {
    String getName();
    int getWeight();
}

class Tiger extends Cat implements HasName {
    public int getWeight() {
        return 115;
    }

}

Если ты просто реализуешь все недостающие методы, которые тебе подскажет Intellij IDEA, то можешь потом долго искать ошибку.

Оказывается, что в классе Tiger есть унаследованный от Cat метод getName, который и будет считаться реализацией метода getName для интерфейса HasName.

— Не вижу в этом ничего страшного.

— Это не очень плохо, это скорее потенциальное место для ошибок.

Но может быть еще хуже:

interface HasWeight {
    int getValue();
}

interface HasSize {
    int getValue();
}

class Tiger extends Cat implements HasWeight, HasSize {
    public int getValue() {
        return 115;
    }
}

Оказывается, ты не всегда можешь унаследоваться от нескольких интерфейсов. Вернее унаследоваться можешь, а вот корректно их реализовать – нет. Посмотри на пример, оба интерфейса требуют, чтобы ты реализовал метод getValue(), и не ясно, что он должен возвращать: вес(weight) или размер(size). Это довольно-таки неприятная вещь, если тебе придется с ней столкнуться.

— Да, согласен. Хочешь реализовать метод, а не можешь. Вдруг ты уже унаследовал метод с таким же именем от базового класса. Обломись.

— Но есть и приятные новости.

2) Расширение видимости. При переопределении типа разрешается расширить видимость метода. Вот как это выглядит:

class Cat {
    protected String getName() {
        return "Васька";
    }
}

class Tiger extends Cat {
    public String getName() {
        return "Василий Тигранович";
    }
}

public static void main(String[] args) {
    Cat cat = new Cat();
    cat.getName();
}

public static void main(String[] args) {
    Tiger tiger = new Tiger();
    tiger.getName();
}

public static void main(String[] args) {
    Cat catTiger = new Tiger();
    catTiger.getName();
}

— Не уверен, что понял полностью, но то, что так можно делать, запомню.

3) Сужение типа результата.

В переопределенном методе мы можем поменять тип результата, сузив его.

class Cat {
    public Cat parent;
    public Cat getMyParent() {
        return this.parent;
    }
    public void setMyParent(Cat cat) {
        this.parent = cat;
    }
}

class Tiger extends Cat {
    public Tiger getMyParent() {
        return (Tiger) this.parent;
    }
}

public static void main(String[] args) {
    Cat parent = new Cat();

    Cat me = new Cat();
    me.setMyParent(parent);
    Cat myParent = me.getMyParent();
}

public static void main(String[] args) {
    Tiger parent = new Tiger();

    Tiger me = new Tiger();
    me.setMyParent(parent);
    Tiger myParent = me.getMyParent();
}

public static void main(String[] args) {
    Tiger parent = new Tiger();

     Cat me = new Tiger();
    me.setMyParent(parent);
     Cat myParent = me.getMyParent();
}

— Ага. Я понял. Надо при переопределении методов беспокоиться о том, как все это будет работать, если мы передадим наши объекты в код, который умеет обращаться только с базовым классом, и ничего о нашем классе не знает.

— Именно! Тогда вопрос на засыпку, почему нельзя расширить тип результата при переопределении метода?

— Это же очевидно, тогда перестанет работать код в базовом классе:

class Cat {
    public Cat parent;
    public Cat getMyParent() {
        return this.parent;
    }
    public void setMyParent(Cat cat) {
        this.parent = cat;
    }
}

class Tiger extends Cat {
    public Object getMyParent() {
        if (this.parent != null)
            return this.parent;
        else
            return "я - сирота";
    }
}

public static void main(String[] args) {
    Tiger parent = new Tiger();

    Cat me = new Tiger();
    Cat myParent = me.getMyParent();
}

— Отличный пример, Амиго!

В Java перед вызовом метода не проверяется, есть ли такой метод у объекта или нет. Все проверки происходят во время выполнения. И [гипотетический] вызов отсутствующего метода, скорее всего, приведет к тому, что программа начнет выполнять байт-код там, где его нет. Это, в конце концов, приведет к фатальной ошибке, и операционная система принудительно закроет программу.

— Ничего себе. Буду знать.