Интерфейсы, коллекции

Question

Доброго времени суток. Есть класс с полями, он имлементирует интерфейс с некоторыми методами. В новой классе создается список. Возможна ли следующая запись создания списка(1). Если да, то как обращаться к элементу такого списка?

 public interface MyInt{
  void getSmth();
  }

 public class MyClass implements MyInt{
  public String name;
  public Integer age;

  @Override
  public void get(){
  ....
   }

  public class Work{
 (1) private static List<MyInt> list = new LinkedList<>();

Answer 1

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

private static List<MyInt> list = new LinkedList<>();

private static void main(...) {
     list.add(new MyClass());
     list.add(new MyClass());
     MyClass obj = (MyClass) list.get(0); // плохой код (даже при проверки перед этим на instanceof)
     String name = obj.getName();
}

Намного правильнее сделать новый интерфейс в котором будут все нужные поля или просто хранить MyClass вместо интерфейса. Если вам в коллекции нужны только методы интерфейса, то все проще

private static void main(...) {
     list.add(new MyClass());
     list.add(new MyClass());
     MyInt obj = list.get(0); // нормальный код
     obj.getSmth();
}

Answer 2

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

public class Test {

    public interface InterfaceX {
        public void iMethod();
    }

    public static class A implements InterfaceX {

        public void methodA() {
            System.out.println("call methodA()");
        }

        public void iMethod() { System.out.println("call iMethod from A"); }

    }

    public static class B implements InterfaceX {

        public void iMethod() { System.out.println("call iMethod from B"); }

    }

    public static List<InterfaceX> list = new LinkedList<>();

    public static void main(String...args) {
        list.add(new A());
        list.add(new B());
        for(InterfaceX item : list) {
            //надо проверять, когда существует такая возможность
            //java.lang.ClassCastException
            //((A) item).methodA();
            if(item instanceof A)
                ((A) item).methodA();
            item.iMethod(); 
        }
    }

}

Answer 3

Не совсем понятно, с чем именно вы пытаетесь разобраться... Если вы хотите понять, зачем нужен интерфейс, то это плохой пример, так Вы ничего не поймете. У интерфейсов есть несколько назначений. Во-первых, это уровень абстракций. Чтобы понять это присмотритесь к интерфейсу List и классам, его имплементирующим. Идея в том, что общий родитель всегда дает Вам пользоваться ООП в полную силу. Полиморфизм, наследование немыслимы без этого. Дополнительный уровень абстракций в этом смысле дает вам возможность писать более универсальный код, если можно так выразиться. Представьте, что вы пишите метод, на входе вы принимаете коллекцию. И тут у вас есть выбор... Если вы примите одну из конкретных реализаций, например ArrayList, то больше ни с чем Ваш метод работать и не сможет. Если вы напишите метод, принимающий List, то теперь можно использовать его сразу с несколькими наследниками, Вам все равно с какими именно. Ну а если вы примите Collection, то Ваш метод совсем универсальный и из всех стандартных коровых коллекций не принимает разве что Maр. Во-вторых, есть GRASP-паттерн Low Coupling. Плюсы этого в том, что код становится гибким и легко изменяемым. Идея в том, чтобы между вашими классами было как можно меньше связей. Этим, кстати, пользуется спринг. И это называется слабая ссылка. Такой код реализуется именно с помощью интерфейсов. Любой из классов имплементирует свой интерфейс, а другие классы обращаются именно с интерфейсами. Тогда изменения в классах никак не касаются других классов, ведь они взаимодействуют исключительно с интерфейсами. Стоит импелементировать какой-либо из интерфейсов и Вы можете даже подменить Ваш класс, а программа при этом будет и дальше работать, не нуждаясь ни в каких изменениях.
В-третьих,интерфейсы помогают при разделении обязанностей при написании приложения в команде. Предположим, Вам надо четко разделить обязанности, но полагаться на память других участников команды в плане того, что именно они должны сделать, глупо. Член команды может просто забыь реализовать нужный метод. неправильно его называть, вернуть значение не того типа и т.д. Поэтому можно написать ряд интерфейсов и каждый из участников реализует именно определенный набор интерфейсов. Все компоненты взаимодействуют на уровне интерфейсов и никаких проблем не возникает. В Вашем случае у интерфейса только один метод и один класс, его импелементирующий. Разумеется , если Вам нужен только этот метод, то все нормально. В остальном в данном конкретном локальном примере приведение этого класса к инетрфейсу не имеет смысла.