Swapped
24 уровень

Интерфейсы.

Статья из группы Архив info.javarush
участников
Доброго дня всем. Начал изучать такую интересную тему как интерфейсы. Некоторые задачи выполняются чисто интуитивно, но не совсем понятно как что работает. Ниже выкладываю код программы, которая успешно прошла проверку на сервере. /* Исправление ошибок 1. Переделай наследование в классах и интерфейсах так, чтобы программа компилировалась и продолжала делать то же самое. 2. Класс Hobbie должен наследоваться от интерфейсов Desire, Dream. */ public class Solution { public static void main(String[] args) throws Exception { System.out.println(Dream.HOBBIE.toString()); System.out.println(new Hobbie().INDEX); } interface Desire { } interface Dream //implements Hobbie { static Hobbie HOBBIE = new Hobbie(); } static class Hobbie implements Desire, Dream { static int INDEX = 1; @Override public String toString() { INDEX++; return "" + INDEX; } } } Хотелось бы описать как я понимаю её, но мысли очень разбросаны. Не могли бы вы в 2х словах описать работу данной программы, а именно что происходит в этом интерфейсе: interface Dream //implements Hobbie { static Hobbie HOBBIE = new Hobbie(); } Спасибо.
Комментарии (9)
  • популярные
  • новые
  • старые
Для того, чтобы оставить комментарий Вы должны авторизоваться
Joysi
Уровень 41
25 февраля 2016, 13:56
Очень рекомендую скачать\купить книгу
Swapped
Уровень 24
25 февраля 2016, 14:02
Какую? Я читаю книгу, но изучение на джавараш с ней немного не совпадает.
Joysi
Уровень 41
25 февраля 2016, 14:24
Сорвался ответ (не то нажал)…
Мечты и желания порождают Хобби.

В интерфейсе Dream создаются два объекта в памяти:
1) класс Hobbie, у которого есть переменная INDEX=1
2) экземпляр класса Hobbie (то есть собственно объект от класса
Hobbie), у которого есть метод toString(), но переменная INDEX не принадлежит ему, хотя объект и имеет доступ к ней.

и вызывая
System.out.println(Dream.HOBBIE.toString());

мы увеличиваем значение переменной класса INDEX (было 1 стало 2).
Второй вывод в консоль
System.out.println(new Hobbie().INDEX);

создает другой объект Hobbie и через него получит значение переменной класса INDEX (равное 2)

Если бы написали вместо
System.out.println(new Hobbie().INDEX);

выражение
System.out.println(new Hobbie().toString());

то вывело бы INDEX=3, так как был бы вызван метод объекта, который увеличивает значение переменной класса.

Очень рекомендую скачать\купить книгу www.ozon.ru/context/detail/id/31079082/
Там самая первая большая глава посвящена интерфейсам и более реальным их применениям.
Swapped
Уровень 24
25 февраля 2016, 15:06
Спасибо, разобрался, только вот пока не въеду какие плюсы от того, что можно создавать экземпляры класса в интерфейсе.
Joysi
Уровень 41
25 февраля 2016, 15:29
Например, вы JAva-фермер, у вас есть класс скотина/живность (Creatures) который реализует интерфейс польза (Profitable).
А в интерфейсе Profit создается:
экземпляр класса GiveMilk со своим набором примитивных переменных: Молоко в месяц, Густота, Вкуснота…
экземпляр класса GiveEgg с другим набором переменных: Яйца в день, Множество (Set) типы яиц, Общее кол-во яиц
экземпляр класса GiveGuano с набором: Множество (Set) тип гуано, double Кол-во в день.

Например добавляя или удаляя корову вы модифицируете экземпляры класса GiveGuano и GiveMilk,
а если вылупился птенчик — то уменьшаете Общее кол-во яиц и GiveGuano

Почему классы, а не переменные — потому что методы более гибко реализуют поведение животного/птицы по мере взросления и т.п.
И классы созданные в интерфейсе характеризуют единственное последнее актуальное состояние вашей фермы, при этом у вас только животные, нет объектов ферма, глобальных переменных и других левых сущностей.
Фактически такой вот вариант Singleton-а реализованный в интерфейсе и растворенный в созданном в нем единственном (по определению класс и его переменные) экземпляре.
Swapped
Уровень 24
25 февраля 2016, 15:39
Хорошее пояснение, надо время чтобы это «переварить до конца». :D А не могли бы Вы ещё какой-нибудь небольшой пример кода изобразить здесь?
Joysi
Уровень 41
25 февраля 2016, 16:18
Пробуйте сами. Отлаживайте и станет понятнее.
Возьмите и делайте параллельно небольшую задачу.
Для примера:
есть 3 типа воинов: берсерк, лучник и пехотинец. У них пусть по 3 разных подтипа поведения (интерфейса) и частично пересекающиеся свойства(здоровье, кол-во стрел, скорость, кол-во грибов).
Наберите 2 войска из разных типов воинов и столкните между собой, выводя в консоль шаги битвы + введите частичную зависимость выбора действий воинов от random-а.
Поле битвы — Singleton, а вот войско можно реализовывать по разному в объектной модели.

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

или другие задачи придумайте. Пробуйте (если есть время).
Swapped
Уровень 24
25 февраля 2016, 16:23
Очень интересная идея, а я как раз на днях думал над чем бы интересным заморочиться, и так сказать применить свои знания на практике) Всё в принципе в голове сложилось кроме поля битвы. Воины и их характеристики (переменные), спеллы/скиллы (методы) — это ± понятно как реализовать, а вот что имеется ввиду под «полем битвы» пока не ясно. Но это были мысли в слух, ещё раз спасибо за такие подробные разъяснения)
Joysi
Уровень 41
25 февраля 2016, 16:33
Поле битвы — единственный объект (Singleton).
Содержит физическую карту (пусть банальный двумерный массив).
При обращении к нему конкретного воина выдает в зависимости от его обзорности и текущей позиции кусочек этой карты с расположенными на нем войсками.
Расставляет начальное расположение войск.
Определяет исход битвы — например не осталось войск противоположной стороны — завершает битву.
и т.п.