Вызов методов после сужения типов

Приняло на instanceof, потому как, что уже было показано в комментах, при моем старом подходе - возможны были исключения. В старом коде 58 строка действительно бесполезна ибо если бы она была true, то такой объект тупо не передался бы в метод, согласен.

58 я строка не бесполезна, она делает не то, что предполагается, но не бесполезна. Т.к. помимо проверки принадлежности класса она заодно и выдает false если переданный объект null. А в переписанном виде через instanceof уже нет т.к. null просто не удовлетворит ни одному условию. Но в приведенной в вопросе реализации нужна проверка на нулл. Т.к. getClass вроде кидает NullPointerException если вызвать от null. А сравнение по имени действительно использовать не стоит, можно использовать проверку по классу getClass, но switch это не переварит уже. проверки через instanceof и через равенство getClass имеют право на жизнь. Т.к. все наследники любого из этих интерфейсов пройдут по сравнению instanceof (что в некоторых проектах может быть нежелательно), но не пройдут по точному сравнению класса. Лекция была про equals и hashCode и там оба подхода сравнивались не помню уже на каком уровне правда.

Ниже Justinian привел ссылку где собственно идет речь о equals и hashCode. Оба подхода имеют место, в определенных условиях. Конкретно в моем коде, который приведен в посте 58 строка мне показалась бесполезной ибо в метод ничего кроме объекта, который реализует Person прийти не может же, вот если там был бы Object, как параметр - да. Но с проверкой на null я таки прозевал, да. Хотя валидатор принял с instanceof без проверки на null

А, проглядел статью про сравнение от Justinian. С instanceof в данном конкретном случае не обязательна проверка на null т.к. там нет дефолтного случая - он просто по всем условиям пройдет и ничего не выполнит в случае null. Даже если бы валидатор тестировал этот метод подавая туда null и - он бы отработал только на корректных классах. А в реальном приложении это наверняка надо обработать, и если даже надо пропустить, то тоже лучше умышленно отдельным условием.

Да, я понимаю что метод просто ничего не сделает и завершится. Просто мне кажеться, в таком случае какой-то нужно эксепшн бросить или что-то типа того, ну собственно как ты и написал.

Да, но это действие должно быть уже либо идеологией продиктовано, либо если "закажут" какую то конкретную обработку, в общем иметь какую то идею. А пока если просто обозначить, что ты помнишь, что он тут может быть - уже хорошо и заодно привычка будет.

58 строка бесполезна в данном случае потому что вызывается следующей строкой для только что созданного объекта, он не может быть null, ведь с ним манипуляций ни каких не производится до этой проверки. Но если говорить о глобальном использовании метода или многопоточности, это уже совсем другая история

В данном конкретном задании можно без него обойтись. Но это обучение для использования в потом в каких то реальных условиях, где такая проверка полезна (если не обязательна т.к. метод может вызвать кто угодно). И даже в этом задании валидатор мог вполне проверить метод отдельно (таких заданий немало, где не пропускает без проверки на null и явно это не указывают иногда в условии, обычно это когда надо написать метод с указанными функциями).

С проверкой по имени самого класса и возможными проблемами с ней связанными - согласен. Перепилил на isntanceof дабы учитывать древо наследования. Но, мне кажеться если я бы использовал полное имя(в котором есть пакет и учитывается вложенность) - тоже норм бы было, нет? Такой вариант принял валидатор

if(person instanceof Person.User){
           ((Person.User) person).live();
       }else if(person instanceof  Person.Loser){
           ((Person.Loser) person).doNothing();
       }else if(person instanceof Person.Coder){
           ((Person.Coder) person).writeCode();
       }else  if(person instanceof Person.Proger)
       {
           ((Person.Proger) person).enjoy();
       }

Так вот, вроде как тоже работает, если передать объект вот такого класса - исключения нет

package com.javarush.task.task14.task1411;
public class SomeBadClass {
    public static class Coder implements Person{
    }
}

Сам код:

String personClass = person.getClass().getName();
       switch (personClass){
           case "com.javarush.task.task14.task1411.Person$User":{
               Person.User user = (Person.User) person;
               user.live();
               break;
           }
           case "сom.javarush.task.task14.task1411.Person$Loser":{
               Person.Loser loser = (Person.Loser) person;
               loser.doNothing();
               break;
           }
           case "com.javarush.task.task14.task1411.Person$Coder":{
               Person.Coder coder = (Person.Coder) person;
               coder.writeCode();
               break;
           }
           case "com.javarush.task.task14.task1411.Person$Proger":{
               Person.Proger proger = (Person.Proger) person;
               proger.enjoy();
               break;
           }
       }

Только что быстрее работает?

То о чем говорили в комментах, нельзя личность человека определять/сравнивать по одному имени, нужно по паспорту и налоговому номеру. Ты сказал - окей, тогда может сравним по имени и фамилии? Я могу поломать и этот вариант :) Время не хочу тратить, просто прими как должное, кастинг и явное приведение опасная операция. И проверять нужно суть, а не имя, которое как ярлык, проверка на него нам ничего не говорит о том, можно явно привести или нет. Относительно скорости, это неважно, речь сначала о том, что работает. Два основных способа, которые используют для определения типа - instanceof и getClass, вот они по скорости отличаются. Почитай к примеру сравнение объектов в Java первую часть статьи про instanceof /getclass или погугли что-то другое.