Абстракция и интерфейсы - Java

Статус: Offline
Реєстрація: 26.07.2010
Повідом.: 52
Абстракция и интерфейсы - Java

Приветствую друзья.
Перешёл к новому разделу. Если раньше я понимал мысли автора и код программы то, с абстракциями и интерфейсами у меня полный завал. Не понимаю, зачем автор перестал вести обсуждение программ.

Код:
interface Game { boolean move(); }
interface GameFactory { Game getGame(); }

class Checkers implements Game {
    private int moves = 0;
    private static final int MOVES = 3;

    public boolean move() {
        System.out.println("Checkers move " + moves);
        return ++moves !=MOVES;
    }
}
class CheckersFactory implements GameFactory {
    public Game getGame() { return new Checkers(); }
}

class Chess implements Game {
    private int moves = 0;
    private static final int MOVES = 4;

    public boolean move() {
        System.out.println("Chess move " + moves);
        return ++moves !=MOVES;
    }
}
class ChessFactory implements GameFactory {
    public Game getGame() { return new Chess(); }
}

public class Games {
    public static void playGame(GameFactory factory) {
        Game s = factory.getGame();
        while(s.move());
    }
    public static void main(String[] args) {
        playGame(new CheckersFactory());
        playGame(new ChessFactory());
    }
}

Результат программы я разобрал. Но если начать с чистого листа, я не могу повторить код, т.к. плохо представляю, что происходит в данной программе. Я не понимаю, зачем эти строчки:
Код:
interface Game { boolean move(); }
interface GameFactory { Game getGame(); }
автор не описывает смысл этих строк. Абстракция, но для чего создаётся такая абстракция?
Далее, понятно, что пояляются два класса использующие интерфейсы для шашек и для шахмат, в одном идёт подсчёт ходов, в другом создание экземпляра (начало игры что ли).

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

Можете объяснить, что в ней происходит?

P.S> Я плохо понимаю интерфейсы вообще. Почему автор утверждает, что они очень простые? Бред... бред... бред...

Взять к примеру программу с наследованием

Apply.java
Код:
class Processor {
    public String name() { return getClass().getSimpleName(); }

    public Object process(Object input) { return input; }
}
class UpperCase extends Processor {
    public String process(Object input) { return ((String)input).toUpperCase(); }
}
class LowerCase extends Processor {
    public String process(Object input) { return ((String)input).toLowerCase(); }
}
class Splitter extends Processor {
    public String process(Object input) { return Arrays.toString(((String) input).split(" ")); }
}


public class Apply {
    public static String s = "Disagreement with beliefs is by definition incorrect";
    public static void process(Processor p, Object s) {
        System.out.println("Using Processor " + p.name());
        System.out.println(p.process(s));
    }

    public static void main(String[] args) {

        process(new UpperCase(), s);
        process(new LowerCase(), s);
        process(new Splitter(), s);
    }
}

и её же только с использованием интефейса

Apply.java
Код:
interface Processor {
    String name();
    Object process(Object input);
}
public class Apply {
    public static void process(Processor p, Object s) {
        System.out.println("Using processor " + p.name());
        System.out.println(p.process(s));
    }
}
StringProcessor.java
Код:
import java.util.Arrays;

public abstract class StringProcessor implements Processor {
    public static String s = "Disagreement with beliefs is by definition incorrect";
    public String name() { return getClass().getSimpleName(); }
    public abstract String process(Object input);

    public static void main(String[] args) {
        Apply.process(new UpperCase(), s);
        Apply.process(new LowerCase(), s);
        Apply.process(new Splitter(), s);
    }
}
class UpperCase extends StringProcessor {
    public String process(Object input) { return ((String)input).toUpperCase(); }
}
class LowerCase extends StringProcessor {
    public String process(Object input) { return ((String)input).toLowerCase(); }
}
class Splitter extends StringProcessor {
    public String process(Object input) { return Arrays.toString(((String)input).split(" ")); }
}

Первый вариант значительно понятнее, короче и, проще, чем через интерфейс.
 
Останнє редагування:
Нужно, чтобы проще было изменять программу, добавлять в нее новую функциональность, повторно использовать написанный ранее код.
Например, когда пишешь чат, разумнее написать абстрактный протокол обмена сообщениями и привязывать графику к нему. Тогда будет проще добавлять новые протоколы и изменять существующие. Фабрика это создание объектов, не уточняя заранее, какой именно класс будет реализовывать данную функциональность.

interface Game { boolean move(); }
https://ru.wikipedia.org/wiki/Интерфейс_(объектно-ориентированное_программирование)
interface GameFactory { Game getGame(); }
https://ru.wikipedia.org/wiki/Абстрактная_фабрика_(шаблон_проектирования)
 
reflect

Я понимаю о чём Вы говорите. Я не понимаю логику создания программы с таким подходом абстрактности. Сложно объяснить.

Я понимаю (понимал) подход (смысл) реализации программы так:
Код:
class Processor {
    public String name() { return getClass().getSimpleName(); }

    public Object process(Object input) { return input; }

есть метод name, которые возвращает строковый тип, т.е. используя этот метод к объекту, он отобразит название класса объекта.
Далее, создаются классы для обработки строк, которые унаследованы от базового класса Processor
Код:
class UpperCase extends Processor {
Метод name() универсален и не переопределяется. Метод process переопределяется для каждого класса, в первом случае, помещенный объект возвращается в строкой форме в верхнем регистре, во втором случае - в нижнем регистре и т.д. Есть последовательность.

Мне понятно, что, зачем, откуда, куда, почему. В абстракциях как-то сложнее. Казалось бы со слов автора всё должно стать легче, но из примеров приведёнными им всё усложнилось. Одни восходящие преобразование типов, боюсь называть это слово, потому что плохо ещё представляю его значение, но по-моему везде ковариантность. Короче, полный фарш.
Я не улавливаю логику, простоту, алгоритм. Глава одна жижа
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
Про музыкальные инструменты Instrument самый доступный пример, улавливаю логику с переводом строки в разные регистры Processor и то, как я сказал, наследование гораздо понятнее - всё остальное дремучий лес.
 
Останнє редагування:
Upcast'ы от незнания Generics, Hive of Interfaces от ума...

Автор выбрал неудачный пример...

Hive of Interfaces - почти завсегда может быть заменён абстрактными классами c вдумчивой финализацией методов и использованием паттерна Template Method. Из полученных абстрактных классов можно сделать выделение интерфейса в случае реальной необходимости...

Hive of Interfaces - появляется на этапах попытки проектирования как средство разграничения всего от вся...


Вводя Processor автор хотел получить нечто вроде:
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
но не асилил

ИМХО еесно
ЗЫ
Не все книги адинакаво палезны
 
Upcast'ы от незнания Generics
дженерики только в 5й яве появились

Я не понимаю логику создания программы с таким подходом абстрактности. Сложно объяснить.
Извини, мне лень разбираться в коде. Возьми другую книжку отсюдава:
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
 
ТС, судя по твоему уровню - не лезь в эти дебри.
Пока что прими для себя интерфейсы как базовые классы с абстрактными методами (что кстати по сути и есть :) )
Имплементя интерфейс - ты по сути наследуешь такой базовый класс и реализуешь его абстрактные методы. Далее кто-то колбасит по методам класса через интерфейс - а мог бы привести объект к базовому классу и колбасить по абстрактным методам.

Короче смотри на интерфейсы как на базовые классы с абстрактными методами. Когда заматереешь в програмировании - найдешь для себя мелкие полезные отличия, без которых кстати можно легко обойтись ;)
Надеюсь смысл и преимущества создания иерархии классов тебе объяснять не надо?
 
ТС, судя по твоему уровню - не лезь в эти дебри.
Пока что прими для себя интерфейсы как базовые классы с абстрактными методами (что кстати по сути и есть :) )
Имплементя интерфейс - ты по сути наследуешь такой базовый класс и реализуешь его абстрактные методы. Далее кто-то колбасит по методам класса через интерфейс - а мог бы привести объект к базовому классу и колбасить по абстрактным методам.

Короче смотри на интерфейсы как на базовые классы с абстрактными методами. Когда заматереешь в програмировании - найдешь для себя мелкие полезные отличия, без которых кстати можно легко обойтись ;)
Надеюсь смысл и преимущества создания иерархии классов тебе объяснять не надо?

Новый термин "имплиментить", это тоже самое, что адвертайзить или оптимизировать, но есть мелкие полезные отличия.
 
Они вошли в лес темный и заблудились навсегда,когда сделали вид,что не заблудженные ,обосновались,там и всем передавали по радио,чтобы не ходили туда.
Так они заблудженные стали лесниками ,рубали там ,интерхейсили по чем зря,и думали,как сделать так,чтобы все были заблудженные,хто и не ходил в тот лес.
Так росло целое поколение потлатых ,заросших снежных имплементов.Когда уже начинали вымерать,шастать начали по окраинам лесу темного,распуская корни по кругу.
Так зарождалось болото.
 
Они вошли в лес темный и заблудились навсегда,когда сделали вид,что не заблудженные ,обосновались,там и всем передавали по радио,чтобы не ходили туда.
Так они заблудженные стали лесниками ,рубали там ,интерхейсили по чем зря,и думали,как сделать так,чтобы все были заблудженные,хто и не ходил в тот лес.
Так росло целое поколение потлатых ,заросших снежных имплементов.Когда уже начинали вымерать,шастать начали по окраинам лесу темного,распуская корни по кругу.
Так зарождалось болото.

завязывай с ускоряющими структурами
 
BFG-9000

Мой уровень - новичок, не только в Java, но и в ООП вообще. Поэтому разбираюсь не спеша.

Вначале главы, я именно так представил себе это.

Код:
import java.util.Random;

enum Note {
    MIDDLE_C, C_SHARP, B_FLAT;
}
interface Instrument {

    void play(Note note);

}

class Wind implements Instrument {
    public void play(Note note) { System.out.println(getClass().getSimpleName() + ".play " + note); }
}

class Percussion implements Instrument {
    public void play(Note note) { System.out.println(getClass().getSimpleName() + ".play " + note); }
}

class Stringer implements Instrument {
    public void play(Note note) { System.out.println(getClass().getSimpleName() + ".play " + note); }
}

class Brass extends Wind {
}

class Woodwind extends Wind {
}

class InstrumentGenerator {

    private Random rand = new Random(47);

    public Instrument choiceInstrument() {

        switch(rand.nextInt(5)) {
            default:
            case 0 : return new Wind();
            case 1 : return new Percussion();
            case 2 : return new Stringer();
            case 3 : return new Woodwind();
            case 4 : return new Brass();
        }
    }
}

public class Music {

    public static void tune(Instrument i) { i.play(Note.MIDDLE_C); }

    public static void main(String[] args) {

        InstrumentGenerator choice = new InstrumentGenerator();
        Instrument[] orchestra = new Instrument[20];

        for(int i = 0; i < orchestra.length; i++) {
            orchestra[i] = choice.choiceInstrument();
        }

        for(Instrument i : orchestra)
            tune(i);
    }
}

Потом автор резко оборвал разбор полёта. Думал, может это было связано из-за перевода на русский... Взял оригинал книги, посмотрел, там тоже самое. Очень странно, что "Философия" автора внезапно оборвалась и читатель потерял его мысли.

Спасибо за отзыв.
 
BFG-9000

Мой уровень - новичок, не только в Java, но и в ООП вообще. Поэтому разбираюсь не спеша.

Вначале главы, я именно так представил себе это.

О, да это вам к Диме надо. Ник Orshansky. Герр преподпоадет ООП!
 
Новый термин "имплиментить", это тоже самое, что адвертайзить или оптимизировать, но есть мелкие полезные отличия.
Вопервых я написал "имплЕментить". Вовторых в переводе implementation - осуществление, реализация. Втретьих - интерфейсы именно реализуются, той самой "реализующей стороной" (всегда Ваш КО).

У тебя есть какие-то проблемы с пониманием? Или с ДНК?
 
Вовторых в переводе implementation - осуществление, реализация.

молодой человек!
так а что же Вам помешало использовать общепринятый термин "реализация интерфейса", может кодировка 1251?
вы уж если калькируете английские слова, то калькируйте их уж, пожалуйста, фонетически. вы же, надеюсь, говорите "фича", а не "феатуре"...
а какой там звук идет после L можно увидеть здесь:
Тільки зареєстровані користувачі бачать весь контент у цьому розділі

так что коллега стрензер абсолютно прав.
 
Останнє редагування:
молодой человек!
так а что же Вам помешало использовать общепринятый термин "реализация интерфейса", может кодировка 1251?
Вообще-то я написал русский вариант заимствованного слова.
Более того, например википидоры со мной согланы, что это слово пишется через "е", например вот:
https://ru.wikipedia.org/wiki/Правовая_имплементация
Впрочем кто такие википидоры? Жалкие ничтожные личности. И кто Вы! Логично.
вы уж если калькируете английские слова, то калькируйте их уж, пожалуйста, фонетически. вы же, надеюсь, говорите "фича", а не "феатуре"...
Это только согласно последней инструкции ВЦСПС, по которой Вы учили английский (раз уж Вы называете меня "молодым человеком" - то именно на те годы пришлось Ваше образование), надо говорить "фича". А в приведенной Вами же ссылке произносится и пишется в транскрипции несколько подругому:
Тільки зареєстровані користувачі бачать весь контент у цьому розділі


Так что Вы меня повеселили, спасибо. Теперь я сам знаю, кто Вы :D
 
Вообще-то я написал русский вариант заимствованного слова.

и какой смысл его "заимствовать", когда есть общепринятый термин?
типа перевирание английских слов русскими буквами делает Вас круче?

Это только согласно последней инструкции ВЦСПС, по которой Вы учили английский (раз уж Вы называете меня "молодым человеком" - то именно на те годы пришлось Ваше образование), надо говорить "фича". А в приведенной Вами же ссылке произносится и пишется в транскрипции несколько подругому:
Тільки зареєстровані користувачі бачать весь контент у цьому розділі

та Вы на кнопочку "послушать" хоть нажмите, нажмите...
или у Вас там в кодировке 1251 она не отображается?
 
Останнє редагування:
Когда я изучал я мыслил приверно так

Допустим, есть класс А и класс Б, которые работают с файлам разных форматов.
Оба они делают одно и то же (загрузить, показать, сохрнить) - разница только в формате.

Можно объявить базовый абстрактный класс, от него отнаследовать оба класса.
Потом сделать класс - строитель, который в зависимости от необходимости вернет нужный класс.

Это хорошо, если классы можно отнаследовать от базового - абстрактного. А вот можно это далеко не всегда. Например, уже есть наследование от класса, а множественное не позволяется (что в принципе верно). Или дописали еще классов потом, которые уже не могут наследоваться от нужного базового. В таком случае помогут интерфейсы. Объявляем классы А и Б как реализующие фенкционал интерфейса В и юзаем на здоровье =)

Про COM молчу пока =)
 
Назад
Зверху Знизу