111 lines
48 KiB
TeX
111 lines
48 KiB
TeX
|
\documentclass[../j-spec.tex]{subfiles}
|
|||
|
|
|
|||
|
|
\begin{document}
|
|||
|
|
\section{Интерфейсы}
|
|||
|
|
\begin{longtable}{|p{35mm}|p{135mm}|}
|
|||
|
|
\hline
|
|||
|
|
Экран & Слова \\ \hline
|
|||
|
|
\endhead
|
|||
|
|
|
|||
|
|
Титул & Здравствуйте, добро пожаловать на курс посвящённый инструментарию разработки джава \\ \hline
|
|||
|
|
|
|||
|
|
Отбивка & и сегодня на повестке дня у нас интерфейсы, но не те интерфейсы, что графические, а те, что программные. \\ \hline
|
|||
|
|
|
|||
|
|
На прошлом уроке & На прошлом уроке мы поговорили о файловых системах и представлении данных в запоминающих устройствах; Поверхностно посмотрели на популярные пакеты ввода-вывода. Подробно разобрали один из самых популярных ссылочных типов данных String и разные механики вокруг него, такие как стрингбилдер и стрингпул. \\ \hline
|
|||
|
|
|
|||
|
|
На этом уроке & Поговорим об интерфейсах, рассмотрим понятие и принцип работы, поговорим о ключевом слове implements; Наследование и множественное наследование интерфейсов, реализация, значения по умолчанию и частичная реализация интерфейсов. Естественно, что говоря об интерфейсах нельзя не сказать о функциональных интерфейсах и анонимных классах. Коротко рассмотрим модификаторы доступа при использовании интерфейсов и немного подробнее поговорим о глубинных процессах, таких как раннее и позднее связывание в объектно-ориентированном программировании. \\ \hline
|
|||
|
|
|
|||
|
|
06-01 & Разговор об интерфейсах хотелось бы построить не так, как мы это делали на лекциях обычно, а от некоторой практической составляющей, чтобы где-то в середине лекции у вас сложилось явное впечатление, что что-то тут явно можно улучшить, а когда мы применим интерфейсы, вы подумали «ааааа так вот зачем оно нужно и как применяется», а потом уже поговорим о теоретической составляющей и особенностях. \\ \hline
|
|||
|
|
|
|||
|
|
Отбивка & Приложение для примера \\ \hline
|
|||
|
|
|
|||
|
|
06-02 & Итак начнём с преамбулы, здесь я призываю вас не особенно обращать внимание на то, какие именно классы и методы используются, а внимательно следить за взаимодействием и отношениями объектов, потому что интерфейсы, о которых мы сегодня планируем поговорить - это как раз механизм упрощающий и универсализирующий взаимодействия объектов. Код может показаться непростым, но зато задачу мы поставим таким образом, что если делать нормально, то без интерфейсов не обойтись, и когда мы закончим - у вас, как я только что и сказал, должно появиться ощущение что «о, так вот зачем они нужны». Почему будет сложно? потому что несмотря на то что вы уже знаете принципы ооп - надо уметь их применять.\\ \hline
|
|||
|
|
|
|||
|
|
06-03 & Итак, что мы будем делать? мы сделаем некий небольшой набросок своего собственного игрового 2д движка, без физики и прочего, а просто с объектами и анимацией, чисто демонстрационный. на его основе можно что угодно запилить, и будет отлично работать. На слайде вы видите окно, кружки летают (имейте ввиду, они перемещаются плавно, если у кого-то что-то дёргается, это интернет с низким ФПС передаёт, а не приложение). пока что ничего тут не обрабатывается, ничего толком не происходит. Итак, самое главное, что нам понадобится, это окно, которое будет как-то взаимодействовать с операционной системой, на окне будет канва, на которой мы будем всё рисовать, и собственно объекты, которые мы будем рисовать. \\ \hline
|
|||
|
|
|
|||
|
|
06-04 & Быстро создаём окно, буквально константы с размерами, координатами, и конструктор окна прямо здесь же вместе с методом мейн, не вдаваясь в подробности того, как работает фреймворк свинг на котором мы всё это пишем, на эту тему у нас будет отдельный урок, на котором мы закрепим информацию об ООП, многопоточности и отлову исключений в графических интерфейсах. Самое важное для нас сейчас - это то, что окно - это объект с какими-то свойствами и каким-то поведением. Если коротко, стартуем программу, создаём объект окна, говорим, что окно с каким-то заголовком, какого-то размера и находится по каким-то координатам, а когда мы нажмём на крестик, то закрыть нужно будет не только окно, но и программу целиком. \\ \hline
|
|||
|
|
|
|||
|
|
06-05 & Итак есть такой компонент JPanel, с ним можно много что делать но самое интересное, что можно на нём рисовать. Итак создали наследника Jpanel с названием GameCanvas. Что умеет любой компонент в свинге? он умеет перерисовываться, посредством вызова метода paintComponent. Применим полиморфизм. Из документации мы знаем, что метод пэинтКомпонент вызывается тогда, когда фреймворку надо перерисовать панельку. Мы этот метод переопределим и напишем свою собственную реализацию перерисовки. Давайте сделаем так: создадим конструктор этой пенльки, и будем в конструкторе делать что то незначительное, например, менять цвет фона на синий. Заоверрайдили пэинтКомпонент и тут-же вызвали родительский метод. То есть по сути мы говорим, что нас вполне устраивает то, как перерисовывается панелька, но мы потом захотим туда что-то добавить. Ну и добавим четыре метода, возвращающие границы нашей канвы, левую, правую, верхнюю, нижнюю.\\ \hline
|
|||
|
|
|
|||
|
|
06-06 & Наладим взаимодействие компонентов и привяжем все действия нашего игрушечного движка ко времени физического мира. В нашем основном окошке, в конструкторе, создали переменную класса GameCanvas и расположили её на окне прям в центре. Пока что всё понятно и хорошо. Всё работает. В принципе можно начать писать логику игры прям здесь, в классе панельки, но это архитектурно не очень хорошо, ведь это же канва на которой мы рисуем, значит здесь мы должны по логике только рисованием заниматься. Давайте примем архитектурное решение писать логику игры в нашем классе с кружками, а GameCanvas будет универсальным, чтобы рисовать вообще всё что угодно. Для этого описали в нашем основном окошке метод, назвали его как-нибудь нормально onDrawFrame и в нём будем описывать реализацию цикла для нашего модного приложения, то есть так называемую бизнес-логику. На данный момент это будут два метода - апдейт который будет как то изменять состояние нашего приложения, и рендер, который будет отдавать команды всяким рисующим компонентам. \\ \hline
|
|||
|
|
|
|||
|
|
06-07 & Теперь нам надо чтобы при перерисовке наш с вами GameCanvas этот метод дёргал, и тем самым изображение как-то менялось. Для этого нашей канве надо знать как минимум чей метод она будет дёргать, то есть ей нужно знать на каком окне она находится. создаём в классе канвы локальную переменную, которая умеет хранить объекты класса MainCircles и передадим значение этой переменной в конструкторе. И в пэинтКомпоненте будем вызывать controller.onDrawFrame(); Далее, чтобы зациклить это действие мы можем пойти несколькими путями: самый простой - создать постоянно обновляющуюся канву, то есть в методе пэинтКомпонент взять и написать repaint() но это вариант прямо скажем "так себе", он полностью нагрузит одно из ядер процессора только отрисовкой окна - не самое лучшее применение одного из ядер. Второй путь - это применение магии из занятия по потокам. мы можем заставить наш поток какое-то время поспать, начиная с 20-й строки вы видите некоторую конструкцию, смысл которой вам будет понятен немного позже Thread.sleep(16); это даст нам фпс близкий к 60, приемлемо для условной игры, не надо ни больше ни меньше, пожалуй. Получится, что мы отрисовали компонент, посчитали что там изменится апдейтом, отправили обратно на отрисовку рендером, отрисовали пэинтКомпонентом.\\ \hline
|
|||
|
|
|
|||
|
|
06-08 & Довольно интересно, кстати, как при этом изменился код, вызывающий конструктор канвы, ведь мы из основного класса с окном теперь как-то должны в канву передать это самое основное окно, как вы могли догадаться, для этой цели мы применяем указатель на текущий объект класса this, то есть в конструкторе основного окна мы передали ссылку на экземпляр этого окна канве. немного ломает привычное использование для обращения к полям в конструкторе, но, поверьте, то ли ещё будет. Предлагаю запомнить такой способ применения ключевого слова this, он нам сегодня ещё пригодится. \\ \hline
|
|||
|
|
|
|||
|
|
06-09 & Закончим с отрисовкой и методом onDrawFrame. Он будет обновлять сцену и рендерить её. Для обновления сцены было бы очень неплохо знать дельту времени, которая прошла с предыдущего кадра, чтобы обновлять физику. Конечно можно писать физику, опираясь на частоту кадра, или на то что мы там спим 16миллисекунд, но это всё очень сомнительная опора, потому что мы гарантированно спим 16миллисекунд, но сколько именно мы будем спать неизвестно, потому что отрисовка происходит не через фиксированные промежутки времени и ещё куча факторов. Лучше всего точно знать сколько времени прошло с предыдущего кадра. поэтому сделаем так чтобы метод onDrawFrame эту самую дельту у канвы получал и отдавал методу обновления. Соответственно считаем дельту в канве. Вот, собственно и вся физика, которая нам понадобится. Теперь посмотрим вот на что - у нас в пэинтКомпонент прилетает объект класса графикс, который отвечает, как это ни удивительно, за графику, то есть за рисование. Это же то, что нам нужно. Давайте этот самый объект отдадим нашему методу onDrawFrame, пусть он что-нибудь рисует. а где рисует? на канве, значит нам надо будет как минимум знать её размеры. какой канвы размеры получаем? нашей, той самой. себя и отдадим. onDrawFrame будет распределять - апдейту отдаст дельту и канву, а рендеру - канву и графику. Для универсальности. Все изменения канвы вы видите на слайде, все изменения основного окна ему соответствуют, изменена сигнатура метода онДроФрейм, на неё мы посмотрим через несколько секунд. Пока самое главное, что нам нужно понять об этих двух объектах - канва считает для нас время и постоянно перерисовывает себя, сообщая об этом факте основному окну, а основное окно на этот факт как-то реагирует. Ну и ООП вокруг этого тоже было бы хорошо понимать, объекты передают ссылки друг на друга и вызывают друг у друга всякие интересные методы. \\ \hline
|
|||
|
|
|
|||
|
|
06-10 & Давайте попробуем что нибудь нарисовать при помощи нашего с вами игрового цикла, например прямую белую линию. Видим, что отлично получается, теперь мы умеем рисовать и наша канва умеет это отображать. Отлично. Наше приложение будет рисовать какие-то объекты, будут это кружки, квадратики, картинки, человечки или какие-то другие объекты - не важно. Важно, чтобы у программы было описан механизм и поведение этих объектов. Это как раз то, о чём я говорил и говорю - применение архитектуры, применение ООП. Мало просто посмотреть уроки, почитать книжки, посидеть на семинаре. Надо сидеть и думать в рамках парадигмы ООП. Это ещё простенькая архитектура. Я понимаю вас, вы смотрите сейчас, и вроде всё понятно, а сами в жизни бы такое не написали. Я сам несколько лет назад такое в жизни не написал бы, так что не переживайте, всё придёт с опытом. Главное, не путайте понятия уметь программировать и знать язык программирования. В какой-то момент вы поймаете себя на мысли, что вы не думаете о циклах и условиях, а думаете на следующем уровне абстракции, думаете о взаимосвязях, об архитектуре, а пальцы сами набирают какие-то языковые конструкции. \\ \hline
|
|||
|
|
|
|||
|
|
06-11 & Соответственно, рисовать просто линии круги и прочее - довольно скучно, поэтому будем рисовать объекты, Создадим класс Спрайт. Ни от чего наследоваться не будем. Просто опишем общее для всех рисуемых объектов в нашей программе поведение. Что может быть у всех объектов в приложении общего? размеры, местоположение. Обычно, когда вы начинаете изучать какой-то графический фреймворк вы замечаете, что начало координат у этого фреймворка находится в верхнем левом или нижнем левом углу. Однако очень часто, когда пишутся какие-то игры или другие приложения с использованием графики в качестве координат используется центр объекта. То есть надо условиться - что х и у - это центр любого визуального объекта на нашей канве. И соответственно удобно хранить не длину-ширину, а половину длины и половину ширины. А границы объекта соответственно будем отдавать через геттеры и сеттеры. Дополнительно научим наш спрайт рисоваться. Ну как научим, просто скажем, что он умеет обновляться и рендериться, а его наследники пусть уже решают, как именно они хотят это делать. Но спрайты лишены логики, они ничего не знают о том, как именно будут меняться их свойства. \\ \hline
|
|||
|
|
|
|||
|
|
06-12 & Поэтому естественно нужно создать класс собственно шарика, который будет по нашему экрану прыгать, а то непорядок какой-то. В конструкторе задаём ему рэндомные размеры. Давайте придумаем ему какие-нибудь глобальные свойства. Можно конечно придумать класс, который будет направлять наш спрайт и вообще задавать ему скорость и прочие физические величины, но мы ж с вами пример пишем, так что придумаем ему просто - скорость по осям х и у соответственно и цвет. для цвета есть совершенно неожиданно называющийся класс Color которому можно задать величины в формате РГБ в диапазоне от 0 до 255. Для шарика переопределяем апдейт и рендер. суперы нам не нужны, они всё равно пустые. Самый простой рендер - мы объекту графики зададим цвет текущего шарика и сделаем fillOval, которому передадим лево, верх, ширину и высоту. Несмотря на то что наши объекты содержат поля типа флоут, мы работаем с пиксельной системой координат (что конечно же не подходит для реальных проектов, там нужно всё сразу переводить в мировые координаты (например принять центр экрана за 0, верх и лево за -1 низ и право за 1, как это делает OpenGL) чтобы рендерить экраны). Но это нам и пяти лекций не хватит чтобы вникнуть так что не будем. А в методе апдейт мы просто прибавляем к нашим текущим координатам нашу скорость, умноженную на дельту времени, то есть как в третьем классе. Расстояние, которое должен был преодолеть наш шарик за то время пока наш поток спал и наша канва рендерилась. ну и обрабатываем отскоки, то есть описываем 4 условия, что при достижении границы мы меняем направление вектора. \\ \hline
|
|||
|
|
|
|||
|
|
06-13 & давайте быстренько допилим основной класс и будем переходить к беседе об интерфейсах уже, а то чувствую вы подустали от вступлений. В основном классе мы делаем очень прямолинейно - создаём классовый массив из спрайтов и называться он будет sprites и мы говорим что будет у нас допустим 1 кружчек. В методе апдейт мы пробежимся по всем спрайтам и скажем каждому из них - апдейться так как ты умеешь. В методе рендер мы сделаем тоже самое - пробежимся по всем спрайтам и скажем - отрисуйся так, как ты хочешь. И всё, реализацию обновления и отрисовки мы оставили самим объектам, то есть инкапсулировали в них, только каждый объект сам по себе знает, как именно ему обновляться с течением времени, и как рисоваться, а основной экран уже управляет - на какой канве, когда и кого рисовать. Итак инициализировали наше приложение одним новым шариком и напишем небольшую магию по добавлению новых шариков в динамически расширяемый массив. Как известно, в джава все массивы имеют неизменяемую размерность. Это накладывает некоторые архитектурные ограничения на программиста, но мы ж с вами крутые программисты, вон сколько лекций и семинаров позади, можем обмануть систему. Код не сложный, когда старый массив заполнился, просто увеличиваем его в два раза и переносим шарики из старого в новый. \\ \hline
|
|||
|
|
|
|||
|
|
06-14 & И осталось эти методы откуда-то вызывать. Мы на нашу канву в конструкторе вешаем слушателя мышки, который нам рассказывает когда произоши какие-то события. Сегодня как раз будем анонимные классы проходить, поговорим об этом явлении подробнее. И по этому произошедшему событию мы говорим - добавь нам спрайт с новым мячиком, у которого будут координаты этого события. Для этого конечно пришлось немного модифицировать класс шарика, добавив в него ещё один конструктор, который сразу задаёт начальные координаты. На правую кнопку мышки повесим удаление спрайта из списков обновления и отрисовки. \\ \hline
|
|||
|
|
|
|||
|
|
06-15 & Получается, мы меньше чем за полчаса написали довольно простое и очень хорошо расширяемое приложение, которое не только рисует вещи, но и на действия пользователя реагирует, кажется, неплохо. Напомню, что самое главное, что мы должны из этого приложения извлечь - это взаимодействия и взаимовлияния объектов. Наследование, полиморфизм, инкапсуляция поведений и свойств. Если честно, я слегка устал от синего цвета нашего фона и решил создать отдельный класс фона, но сразу столкнулся с необходимостью думать головой. Логично было бы предположить, что фон - это спрайт, имеющий прямоугольную форму и всегда рисующийся первым. но вот беда, при изменении размеров окна фон тоже желательно изменить в размерах. Поэтому в отрисовке я просто говорю канве, что она должна изменить свой цвет фона, а что, ссылка то на канву у меня есть. Цвет фона я меняю синусоидально по каждому из трёх компонент цвета, поэтому изменение происходит довольно плавно. В общем, получается, что от спрайта нам фактически нужно только поведение, а свойства не нужны. Но и отказаться от наследования нам бы не хотелось, потому что тогда мы не сможем фон единообразно в составе массива спрайтов обновлять. Это наталкивает нас на мысль об унификации поведения, на мысль об интерфейсе. \\ \hline
|
|||
|
|
|
|||
|
|
Отбивка Понятие интерфейса & Механизм наследования очень удобен, но он имеет свои ограничения. В частности мы можем наследовать только от одного класса, в отличие, например, от языка С++, где имеется множественное наследование \\ \hline
|
|||
|
|
|
|||
|
|
фото руля-педалей-коробки, фото юсб, фото клавиатуры-мыки-монитора & В языке Java эту проблему частично позволяют решить интерфейсы. Интерфейсы определяют некоторый функционал, не имеющий конкретной реализации, который затем реализуют классы, применяющие эти интерфейсы. И один класс может реализовать множество интерфейсов. Если сказать проще, интерфейс можно очень-очень грубо представить как очень-очень абстрактный класс. До седьмой джавы это был просто набор методов без реализации. Начиная с восьмой наделали много тонкостей, с ними будем разбираться. Итак интерфейс - это описание методов. Примером интерфейса в реальной жизни может быть интерфейс управления автомобилем, интерфейс взаимодействия с компьютером или даже интерфейс USB, так, компьютеру не важно, что именно находится по ту сторону провода, флешка, веб-камера или мобильный телефон, а важно, что компьютер умеет работать с интерфейсом USB, отправлять туда байты или получать. Потоки ввода-вывода, которые мы проходили чуть раньше - это тоже своего рода интерфейс, соединяющий не важно какой программный код и не важно какой, например, файл. Все методы во всех интерфейсах всегда публичные, и в классическом варианте не имеют реализации. Ну и поскольку все методы всегда паблик то этот модификатор принято просто не писать. Для новичка это неочевидно и сбивает с толку, может показаться что модификатор дефолтный, а на самом деле он публичный, поблагодарим разработчиков джавы и пойдём дальше. \\ \hline
|
|||
|
|
|
|||
|
|
& \\ \hline
|
|||
|
|
& \\ \hline
|
|||
|
|
& \\ \hline
|
|||
|
|
& \\ \hline
|
|||
|
|
& \\ \hline
|
|||
|
|
& \\ \hline
|
|||
|
|
& \\ \hline
|
|||
|
|
& \\ \hline
|
|||
|
|
& \\ \hline
|
|||
|
|
|
|||
|
|
\end{longtable}
|
|||
|
|
\end{document}
|
|||
|
|
|
|||
|
|
****** Для чего же?
|
|||
|
|
Например, создадим пару классов, классА и классБ. КлассА будет у нас реализовывать интерфейсА. То есть множественного наследования нет, но мы можем реализовать сколько угодно интерфейсов. Для того, чтобы реализовать интерфейс - мы должны переопределить все его методы, либо сделать класс абстрактным. Вот, статический анализатор кода в идее нам об этом явно говорит. Выведем модное сообщение о том что это класс1 или класс2.
|
|||
|
|
И теперь самая соль - мы можем в мэйне объявлять не только классы и создавать объекты, но и создать переменную, которая реализовывает интерфейсА. То есть тут могут лежать абсолютно никак не связанные между собой сущности, главное, чтобы они реализовывали интерфейсА. И мы можем работать с методами интерфейса, которые могут быть для разных классов вообще по-разному реализованы. Такой вот полиморфизм. Понимаете насколько сильно это отличается от наследования, когда мы с вами создавали общий абстрактный класс животное и от него наследовали наших котиков?
|
|||
|
|
****** Также важно
|
|||
|
|
Что в интерфейсах также разрешено наследование. То есть у нас интерфейс может наследоваться от другого интерфейса, соответственно при реализации интерфейса мы должны переопределить методы всех родителей нашего интерфейса, то есть тут картина очень похожа на наследование классов
|
|||
|
|
****** Вернёмся к бэкграунду
|
|||
|
|
Он наследуется от спрайта, но ему от спрайта вообще ничего не надо, кроме двух методов. в которых он полностью пишет собственную реализацию. И вот сложилась ситуация в которой нам надо хранить в одном массиве очень похожие объекты но наследовать их друг от друга не логично. Как поправить?
|
|||
|
|
****** Напишем некий интерфейс, назовём его GameObject
|
|||
|
|
и скажем, что у него есть методы апдейт и рендер, без реализации. То есть это будут некие объекты которые должны уметь рисоваться и апдейтиться. Идём в спрайт, и говорим, что мы реализуем интерфейс гейм объекта. Смотрим, что сломалось, кто навскидку скажет, почему? (модификатор должен быть пабликом). И Фон тоже теперь у нас реализует интерфейс гейм объекта. При этом получается, то фон вообще никак не связан со спрайтом, у них даже набор полей разный. Но оба умеют рисоваться и апдейтиться, благодаря интерфейсу.
|
|||
|
|
****** Теперь идём править основное окно и логику
|
|||
|
|
Здесь всё просто, мы массив спрайтов меняем на массив геймОбъектов и пробуем запустить. Вопросы, оценка сложности.
|
|||
|
|
***** Интерфейсы
|
|||
|
|
****** Давайте посмотрим со стороны
|
|||
|
|
что мы тут понаписали. У наших классов канвы и спрайта, а также у интерфейса нет никакой специфики, их можно применить где угодно. Универсальные получились штуковины.
|
|||
|
|
****** создадим какую-то условную вторую игру
|
|||
|
|
новый пакет, новый класс, скопипастим немного кода, чтобы всё запускалось. И не писать же нам по новой спрайты и интерфейсы. сделаем правильное дробление по пакетам. то есть получается, что у нас есть некий библиотечный пакет, и какие-то игры с конкретными реализациями. создадим паке КОММОН и переносим туда канву, спрайт и геймобъект, и ща будем всё чинить.
|
|||
|
|
Структура понятна?
|
|||
|
|
Что не нравится канве? ондрофрейм нужно паблик
|
|||
|
|
Что не нравится мэйн виндоу? гейм канвас надо сделать паблик
|
|||
|
|
Гейм объект это интерфейс, ему вообще на всё плевать, только импорты лишние выкинем
|
|||
|
|
Спрайт тоже не сломался
|
|||
|
|
Идём в шарик он не видит спрайта, сделаем спрайт пабликом
|
|||
|
|
он же не видет поля и методы, сделаем их протектед
|
|||
|
|
он же не видит методы канвы. сделаем их публичными
|
|||
|
|
И идём в мэйн, что тут? он не видит конструктор канвы. делаем пабликом
|
|||
|
|
****** второе окно также инитим
|
|||
|
|
конструктор, размеры, положение. И вот хотим воспользоваться нашей канвой. Но не даёт же. почему, мы ж так классно всё придумали, никакой специфики. Но нет, канва то может принимать в конструкторе mainCircles. и канва уже у этого класса вызывает метод onDrawFrame(). Как это решается? это решается интерфейсом. нам нам надо написать какой-то интерфейс вроде canvasPaintListener, который будет уметь ждать от канвы вызов метода и как-то по своему его реализовывать, и собственно реализовать этот интерфейс. А то у нас получается катастрофа - игры зависят от общего пакета, а общий пакет вообще ничего не должен знать о том, какие игры он помогает создать.
|
|||
|
|
Создаём в общем пакете интерфейс с одним методом, который имеет сигнатуру из нашего mainCircles. И перепишем канву, чтобы она не какой-то класс с шариками на вход принимала, а canvasPaintListener, назовём переменную листнер. и везде используем листнер.
|
|||
|
|
И в главном окне мы говорим что ты хороший класс, с прекрасным наследованием, но только ещё будешь реализовывать интерфейс слушателя канвы. а метод у нас уже правильно написан, с верной сигнатурой. Чтобы подчеркнуть, что это реализация интерфейса, напишем аннотацию оверрайд.
|
|||
|
|
Во второй игре мы тоже реализуем этот же интерфейс, и передаём канве себя, потому что мы умеем слушать канву
|
|||
|
|
***** Анонимные классы
|
|||
|
|
****** Итак все мы знаем
|
|||
|
|
что классы это такой новый для нашей программы тип данных. Мы уже привычными движениями создаём публичные классы в отдельный файлах и пишем в них логику, но это не всё, что позволяет нам джава. Классы также бывают вложенными и внутренними. Внутренние классы - это классы, которые пишутся внутри класса, который описан в файле, мы его даже можем использовать и вызывать его методы. А также вложенные или локальные классы, которые мы можем объявлять прямо в методах, и работать с ними, как с обычными классами, но область видимости у них будет только внутри метода.
|
|||
|
|
К чему я это веду? к анонимным классам. Давайте переименуем наш интерфейс во что то вроде MouseListener и опишем в нём пару методов, например mouseUp(), mouseDown(). Перейдём в наш основной класс и скажем, что наш локальный класс будет реализовывать интерфейс и значит должен переопределять все его методы. Видим. Теперь мы можем экземпляр этого класса создать и даже попользоваться его методами.
|
|||
|
|
****** Пока что ловите мысль?
|
|||
|
|
Очень часто, какието элементы управления (кнопчки, события входящих датчиков (клавиатура, мышка) требуют на вход каких нибудь слушателей, которые будут отлавливать их события и вообще знать что делать и это всё интерфейсы. Значит если мы туда передадим что-то, что реализует интерфейс, то это нечто уже начнёт ловить события и как-то их обрабатывать. Соответственно весьма часто такие классы создаются без имени, прямо в аргументе методов. Ну и действительно, зачем ему имя, если он будет использован только один раз и только в этом методе? Вот допустим у нас есть переменная MouseListener listener и нам нужно создать туда какой-то экземпляр, который реализует этот интерфейс. для этого есть такой синтаксис:
|
|||
|
|
new MouseListener дальше пишем интерфейс, который реализуем
|
|||
|
|
{} и у нас по сути открывается объявление класса, где мы пишем реализацию. И получается что мы создаём один экземпляр анонимного класса, который реализует интерфейс MouseListener. И конечно потом мы этот анонимный класс уже кладём в идентификатор (или можем прям вот так передать в метод). Конечно мы можем избежать этого, сейчас поговорим как, но в чужом коде это сплошь и рядом, вот такой замороченный синтаксис, спасибо разработчикам джава.
|
|||
|
|
Понятен-ли этот синтаксис? Это создание объекта анонимного класса, никак не называющегося, реализующего интерфейс.
|
|||
|
|
Тут можно поговорить о лямбдах, для того чтобы сократить синтаксис мы можем просто убрать то что неизменно для этого анонимного класса - название интерфейса, название метода и класс аргумента.
|
|||
|
|
****** Вернёмся к нашим кружочкам
|
|||
|
|
Смотрим прям первый метод, invokeLater() он принимает на вход какой-то Runnable. Идём в Runnable и видим, что это интерфейс, который реализует один единственный метод run(). Получается, что мы в invokeLater передаём новый экземпляр анонимного класса который РЕАЛИЗУЕТ ИНТЕРФЕЙС Runnable, вот описание этого класса, мы в нём переопределяем метод run. Вот так это читается. Ровно тоже самое мы сделали с mouseListener. Здесь немного сложнее. Есть интерфейс MouseListener в котором описаны вот эти все методы. И есть специальный класс MouseAdapter в котором все эти методы уже реализованы. Реализации пустые, но они есть, поэтому мы можем не все методы оверрайдить, а только те, которые посчитаем нужными. И когда мы этот MouseAdapter отдаём нашему методу, мы говорим: создай нам новый экземпляр анонимного класса, который НАСЛЕДУЕТСЯ ОТ КЛАССА MouseAdapter и переопредели вот этот метод. Остальные оставляй пустыми. Чувствуете разницу? Как можно избежать таких конструкций и при этом получить понятный код без лишних заморочек? Очень просто. Скажем, что наш класс - реализует тот или иной интерфейс, и переопределим все методы. В некоторые из них даже напишем реализацию, и туда, где требуется интерфейс - передадим себя. Мы же теперь MouseListener, да и Runnable.
|
|||
|
|
****** в тему анонимных классов можно ещё коротко сказать о перечислениях
|
|||
|
|
в самом частом случае - перечисления это список именованных констант. объявленные в перечислении идентификаторы - это публичные статические финальные поля класса. в более сложных случаях перечисления могут содержать также методы, например, поиска идентификатора по значению, или получения значения из идентификатора
|