jtd1-06-workshop.tex

@@ -1,36 +0,0 @@
-
-% СЕМИНАР: Давайте пилить стартовое окно. 
-% 	  Объявим константы, заботливо подобранные заранее, ширина окна 350 высота 230, минимальная выигрышная длина 3, минимальный размер поля 3, и максимальные размеры 10, 10. эти значения нам нужны будут для создания слайдеров. И давайте сразу объявим переменную типа GameWindow gameWindow, и зададим ей значение из конструктора. this.gameWindow = gameWindow. установим ширину и длину. Теперь давайте, чтобы сделать красиво и ровно посередине, воспользуемся ещё одним новым на сегодня классом, Rectangle, который представляет собой абстрактный прямоугольник. назовём его gameWindowBounds и создадим, = gameWindow.getBounds(), сразу передав в него значения границ нашего окна. у окон есть и такой метод, getBounds(), да. В общем это просто удобный класс для работы с прямоугольниками, то есть с окнами например. И теперь делаем немного математики, задаём переменную 
-% 	  int pos_x = (int)gameWindowBounds.getCenterX() - WIN_WIDTH / 2;
-% 	  int pos_y = (int)gameWindowBounds.getCenterY() - WIN_HEIGHT / 2;
-% 	  setLocation(pos_x, pos_y);
-% 	  setResizeable(false);
-%   setBorder(new EmptyBorder(3, 3, 6, 3));
-% 	  Сделаем заголовок, СОЗДАНИЕ НОВОЙ ИГРЫ. расположение сделаем сеткой setLayout(new GridLayout(10, 1)); Дальше нам надо добавить сюда много-много разных управляшек, и эти однотипные по сути действия мы для удобства вынесем в отдельный метод void addGameControlsMode(){}; 
-% 	  Для начала добавим надпись, для этого существует класс JLabel, пишем add(new JLabel(“Choose gaming mode”)); в конструктор можем передать собственно надпись, а можем ничего не передавать и задать её потом, но для этого надо будет поместить надпись в какой-то именованный контейнер, для нас сейчас это, понятно, лишнее. 
-% 	  Дальше нужны будут две радиокнопки, которые пригодятся не только в этом методе, поэтому объявление вынесем вверх, а присваивание значений сделаем в нашем методе, который всё добавляет. выносим 
-% 	  private JRadioButton humVSAI; 
-% 	  private JRadioButton humVShum;
-% 	  и присвоим humVSAI = new JRadioButton(“Play VS Computer”); с надписью переданной в конструктор, и вторую также. добавим на наше окно и увидим что всё неправильно работает. add(hva); add(hvh); 
-% 	  Чтобы всё заработало как мы ожидаем есть класс который связывает радиобатоны в группы, что видно из его названия ButtonGroup gameMode = newBG(); gmode.add(hvm); gmode.add(hvh); и саму радиогруппу никуда класть не надо, она просто объединит. и чтобы одна из них была выбрана по умолчанию, используем перегруженный конструктор радио кнопки, (“play vs comp”, true); 
-% ***** Слайдеры 
-% 	  пишем следующий метод addGameControlsFieldWinLen(){} в котором будем описывать наши слайдеры, то есть понятно, что это всё ещё конструктор, просто мы делаем его чисто внешне менее жирным. Ну и чтобы логически разграничить, потому что код уже получается достаточно непростой. 
-% 	  Напишем некий подзаголовок  add(new JLabel(“Выбери длину”)); и пишем новенький лейбл на котором будем писать выигрышную длину 
-% 	  JLabel lbl_win_len = new JLabel(“WIN_LEN” + WIN_LEN)); 
-% 	  add(lbl_win_len); этот видите мы создаём в два действия, потому что цифру на нём мы будем менять, а не задавать из программы. Давайте объявим слайдеры где-то рядом с JRadioButton'ами. 
-% 	  private JSlider sField_size; 
-% 	  JSlider sWin_len; и в методе также создадим. в конструкторе слайдеру можно передать три значения, мин, макс и текущее пишем 
-% 	  sWin_len = new Slider(MIN_WIN,  MIN_FIELD, MIN_WIN); 
-% 	  на слайдер мы тоже вешаем слушателя изменений, только тут он называется ChangeListener пишем sWin_len.addChangeListener(new ChangeListener)); и в нём делаем изменение текста для нашего лейбла лбл_вин_лен.сетТекст(“WIN_LEN” + sWin_len.getValue); 
-% 	  и добавим его на окно после лейбла. add(sWin_len); дальше создаём такой-же лейбл с размерами поля и аналогично ставим ему текст, добавим на окно. Теперь поинтереснее, создаём слайдер для поля, тоже аналогично, пишем чендж листнер и начинаем прикалываться, введём ещё одну переменную, current_field_size = sField_size.getValue() и будем использовать его в двух местах, во первых нам надо значения на лейбле менять, а во вторых, максимальное значение выигрышной длины тоже менять. лейбл.сетТекст(ФИЛД + каррент); и сВинЛен.сетМаксимум(каррент); и давайте аккуратно по порядку добавим слайдеры и надписи. Вот теперь вы никак не сможете ошибиться и сделать выигрышную длину больше чем размер поля.
-% ***** И осталась нам только кнопочка “начать игру” 
-% 	  в конце конструктора пишем JButton btnStartGame = new JButton(“New Game”); add(btnSG); вот у нас и получился один столбец и десять строчек. Осталось только оживить кнопочку, для этого напишем последний на сегодня метод назову его btnStart_onClick(), 
-% 	  в кнопке пишем btnSG.addActionListener(new ActionListener()); и внутри любезно предоставленного шаблона просто вызовем наш метод, чтобы много не писать. А обработчик очень интересный, в нём нам надо вызвать метод startNewGame из основного окошка, но чтобы сделать это нам надо наполнить сигнатуру разными параметрами, которые мы возьмём с наших управляшек. 
-% 	  Давайте в классе Map объявим пару констант, раз мы не изучали с вами перечисления. GAME_MODE_H_V_A = 0, GAME_MODE_H_V_H = 1; и в классе в котором работаем создадим новую переменную инт game_mode; 
-% 	  пишем if(rb_hva.isSelected()) значит если кнопка выделена - game_mode = Map.HVA иначе rb_hvh.isSelected() game_mode = Map.HVH; ну и совсем иначе генерим исключение. мало-ли мы через пол года захотим ещё режимов надобавлять, батон добавим, а сюда забудем дописать, или пользователю не отобразится радиобатон, throw new RuntimeException(“No Buttons Selected”); и программа нам подскажет где искать. 
-% 	  также с размером поля, которое пока что у нас будет квадратным, хоть мы и архитектурно заложили, что оно может быть не квадратным. эти показания мы просто снимем со слайдеров и передадим в конструктор slider.getValue(); ну и перед тем как закончить обработчик нам надо наше окошко спрятать от глаз пользователя до следующего раза, setVisible(false);
-% 	  ну вот мы выполнили план на сегодня, хоть мы и немного отошли от методички, но мы сделали хороший задел для нашего последнего занятия, нам там надо будет только написать логику, и расчертить полянку
-% ***** Домашняя работа
-%   1. Полностью разобраться с кодом (попробовать полностью самостоятельно переписать одно из окон)
-%   2. Составить список вопросов и приложить в виде комментария к домашней работе
-%   3. * Раcчертить панель Map на поле для игры, согласно fieldSize

pics/jd-02-derived-interfaces.svg

@@ -1,259 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-
-<svg
-   width="210mm"
-   height="297mm"
-   viewBox="0 0 210 297"
-   version="1.1"
-   id="svg5"
-   inkscape:version="1.2.1 (9c6d41e4, 2022-07-14)"
-   sodipodi:docname="jd-02-derived-interfaces.svg"
-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
-   xmlns="http://www.w3.org/2000/svg"
-   xmlns:svg="http://www.w3.org/2000/svg">
-  <sodipodi:namedview
-     id="namedview7"
-     pagecolor="#ffffff"
-     bordercolor="#000000"
-     borderopacity="0.25"
-     inkscape:showpageshadow="2"
-     inkscape:pageopacity="0.0"
-     inkscape:pagecheckerboard="0"
-     inkscape:deskcolor="#d1d1d1"
-     inkscape:document-units="mm"
-     showgrid="true"
-     inkscape:zoom="2.4712112"
-     inkscape:cx="230.4538"
-     inkscape:cy="357.31467"
-     inkscape:window-width="1534"
-     inkscape:window-height="894"
-     inkscape:window-x="0"
-     inkscape:window-y="25"
-     inkscape:window-maximized="0"
-     inkscape:current-layer="layer1">
-    <inkscape:grid
-       type="xygrid"
-       id="grid1775" />
-  </sodipodi:namedview>
-  <defs
-     id="defs2">
-    <inkscape:path-effect
-       effect="bspline"
-       id="path-effect4248"
-       is_visible="true"
-       lpeversion="1"
-       weight="33.333333"
-       steps="2"
-       helper_size="0"
-       apply_no_weight="true"
-       apply_with_weight="true"
-       only_selected="false" />
-  </defs>
-  <g
-     inkscape:label="Слой 1"
-     inkscape:groupmode="layer"
-     id="layer1">
-    <text
-       xml:space="preserve"
-       style="font-size:4.9389px;font-family:'PT Astra Serif';-inkscape-font-specification:'PT Astra Serif';fill:#000000;stroke-width:0.264999;stroke-linecap:square"
-       x="38.364582"
-       y="80.697914"
-       id="text2244"><tspan
-         sodipodi:role="line"
-         style="stroke-width:0.265"
-         id="tspan2246"
-         x="38.364582"
-         y="80.697914" /></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Mono';-inkscape-font-specification:'IBM Plex Mono';fill:#000000;stroke-width:0.264999;stroke-linecap:square"
-       x="52.916668"
-       y="71.4375"
-       id="text2252"><tspan
-         sodipodi:role="line"
-         id="tspan2250"
-         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'IBM Plex Mono';-inkscape-font-specification:'IBM Plex Mono';stroke-width:0.265"
-         x="52.916668"
-         y="71.4375">Animal</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Mono';-inkscape-font-specification:'IBM Plex Mono';fill:#000000;stroke-width:0.264999;stroke-linecap:square"
-       x="54.239582"
-       y="85.989586"
-       id="text2306"><tspan
-         sodipodi:role="line"
-         id="tspan2304"
-         style="stroke-width:0.265"
-         x="54.239582"
-         y="85.989586">Human</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Mono';-inkscape-font-specification:'IBM Plex Mono';fill:#000000;stroke-width:0.264999;stroke-linecap:square"
-       x="82.020836"
-       y="85.989586"
-       id="text2310"><tspan
-         sodipodi:role="line"
-         id="tspan2308"
-         style="stroke-width:0.265"
-         x="82.020836"
-         y="85.989586">Bull</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Mono';-inkscape-font-specification:'IBM Plex Mono';fill:#000000;stroke-width:0.264999;stroke-linecap:square"
-       x="76.729164"
-       y="116.41667"
-       id="text2314"><tspan
-         sodipodi:role="line"
-         id="tspan2312"
-         style="stroke-width:0.265"
-         x="76.729164"
-         y="116.41667">Minotaurus</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Mono';-inkscape-font-specification:'IBM Plex Mono';fill:#000000;stroke-width:0.264999;stroke-linecap:square"
-       x="29.104166"
-       y="85.989586"
-       id="text3268"><tspan
-         sodipodi:role="line"
-         id="tspan3266"
-         style="stroke-width:0.265"
-         x="29.104166"
-         y="85.989586">Wolf</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Mono';-inkscape-font-specification:'IBM Plex Mono';fill:#000000;stroke-width:0.264999;stroke-linecap:square"
-       x="36.380207"
-       y="103.18753"
-       id="text3272"><tspan
-         sodipodi:role="line"
-         id="tspan3270"
-         style="stroke-width:0.265"
-         x="36.380207"
-         y="103.18753">Werewolf</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Mono';-inkscape-font-specification:'IBM Plex Mono';fill:#000000;stroke-width:0.264999;stroke-linecap:square"
-       x="9.260417"
-       y="103.1875"
-       id="text4002"><tspan
-         sodipodi:role="line"
-         id="tspan4000"
-         style="stroke-width:0.265"
-         x="9.260417"
-         y="103.1875">Jackal</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Mono';-inkscape-font-specification:'IBM Plex Mono';fill:#000000;stroke-width:0.264999;stroke-linecap:square"
-       x="38.364582"
-       y="124.35419"
-       id="text4006"><tspan
-         sodipodi:role="line"
-         id="tspan4004"
-         style="stroke-width:0.265"
-         x="38.364582"
-         y="124.35419">Anubis</tspan></text>
-    <rect
-       style="fill:none;stroke-width:0.264999;stroke-linecap:square;stroke:#000000;stroke-opacity:1"
-       id="rect4114"
-       width="23.8125"
-       height="7.9375"
-       x="50.270832"
-       y="66.145836" />
-    <rect
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect4116"
-       width="18.520834"
-       height="7.9375"
-       x="26.458332"
-       y="80.697914" />
-    <rect
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect4118"
-       width="21.166666"
-       height="7.9375"
-       x="51.59375"
-       y="80.697914" />
-    <rect
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect4120"
-       width="18.520834"
-       height="7.9375"
-       x="79.375"
-       y="80.697914" />
-    <rect
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect4122"
-       width="23.8125"
-       height="7.9375"
-       x="6.614583"
-       y="97.895836" />
-    <rect
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect4124"
-       width="37.041668"
-       height="7.9375"
-       x="74.083328"
-       y="111.125" />
-    <rect
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect4126"
-       width="23.8125"
-       height="7.9375"
-       x="35.71875"
-       y="119.0625" />
-    <rect
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect4128"
-       width="30.427082"
-       height="7.9375"
-       x="33.734375"
-       y="97.895836" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       d="M 55.562499,74.083332 37.041666,80.697916"
-       id="path4130" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       d="m 62.177083,74.083332 v 6.614584"
-       id="path4132" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       d="m 68.791666,74.083332 19.84375,6.614584"
-       id="path4134" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       d="M 68.791667,88.635417 84.666664,111.125"
-       id="path4136"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       d="M 89.958333,88.635417 96.572911,111.125"
-       id="path4138"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       d="M 30.427083,88.635416 17.197916,97.895832"
-       id="path4140" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       d="M 15.875,105.83333 42.333333,119.0625"
-       id="path4142"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       d="m 56.885416,88.635416 -9.260417,9.260416"
-       id="path4240" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       d="m 37.041666,88.635416 5.291667,9.260416"
-       id="path4244" />
-    <path
-       style="fill:none;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       d="m 63.499999,88.635416 c 3.527956,6.173923 7.055733,12.347534 5.071244,17.418574 -1.98449,5.07104 -9.480867,9.03971 -16.977494,13.00851"
-       id="path4246"
-       inkscape:path-effect="#path-effect4248"
-       inkscape:original-d="m 63.499999,88.635416 c 3.528042,6.173874 7.055821,12.347484 10.583333,18.520834 -7.496413,3.96909 -14.992791,7.93776 -22.489583,11.90625" />
-  </g>
-</svg>

pics/jd-02-interfaces-use.svg

@@ -1,325 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-
-<svg
-   width="210mm"
-   height="297mm"
-   viewBox="0 0 210 297"
-   version="1.1"
-   id="svg5"
-   inkscape:version="1.2.1 (9c6d41e4, 2022-07-14)"
-   sodipodi:docname="jd-02-interfaces-use.svg"
-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
-   xmlns="http://www.w3.org/2000/svg"
-   xmlns:svg="http://www.w3.org/2000/svg">
-  <sodipodi:namedview
-     id="namedview7"
-     pagecolor="#ffffff"
-     bordercolor="#000000"
-     borderopacity="0.25"
-     inkscape:showpageshadow="2"
-     inkscape:pageopacity="0.0"
-     inkscape:pagecheckerboard="0"
-     inkscape:deskcolor="#d1d1d1"
-     inkscape:document-units="mm"
-     showgrid="true"
-     inkscape:zoom="1.0579349"
-     inkscape:cx="290.6606"
-     inkscape:cy="384.71176"
-     inkscape:window-width="1534"
-     inkscape:window-height="876"
-     inkscape:window-x="0"
-     inkscape:window-y="25"
-     inkscape:window-maximized="0"
-     inkscape:current-layer="layer1">
-    <inkscape:grid
-       type="xygrid"
-       id="grid1049" />
-  </sodipodi:namedview>
-  <defs
-     id="defs2" />
-  <g
-     inkscape:label="Слой 1"
-     inkscape:groupmode="layer"
-     id="layer1">
-    <text
-       xml:space="preserve"
-       style="font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square;font-weight:normal;font-style:normal;font-stretch:normal;font-variant:normal"
-       x="31.75"
-       y="71.4375"
-       id="text1468"><tspan
-         sodipodi:role="line"
-         id="tspan1466"
-         style="fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.265;-inkscape-font-specification:'IBM Plex Sans';font-family:'IBM Plex Sans';font-weight:normal;font-style:normal;font-stretch:normal;font-variant:normal"
-         x="31.75"
-         y="71.4375" /></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="23.8125"
-       y="66.145836"
-       id="text1724"><tspan
-         sodipodi:role="line"
-         id="tspan1722"
-         style="stroke-width:0.265"
-         x="23.8125"
-         y="66.145836">Привет, мир</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="71.4375"
-       y="68.791664"
-       id="text1728"><tspan
-         sodipodi:role="line"
-         id="tspan1726"
-         style="stroke-width:0.265"
-         x="71.4375"
-         y="68.791664">Котики</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="66.145836"
-       y="79.375"
-       id="text1782"><tspan
-         sodipodi:role="line"
-         id="tspan1780"
-         style="stroke-width:0.265"
-         x="66.145836"
-         y="79.375">Собачки</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="29.104166"
-       y="58.208332"
-       id="text1786"><tspan
-         sodipodi:role="line"
-         id="tspan1784"
-         style="stroke-width:0.265"
-         x="29.104166"
-         y="58.208332">Методы</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="68.791664"
-       y="50.270832"
-       id="text1790"><tspan
-         sodipodi:role="line"
-         id="tspan1788"
-         style="stroke-width:0.265"
-         x="68.791664"
-         y="50.270832">Классы</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="100.54166"
-       y="42.333332"
-       id="text1794"><tspan
-         sodipodi:role="line"
-         id="tspan1792"
-         style="stroke-width:0.265"
-         x="100.54166"
-         y="42.333332">Пакеты</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="97.895836"
-       y="71.4375"
-       id="text1798"><tspan
-         sodipodi:role="line"
-         id="tspan1796"
-         style="stroke-width:0.265"
-         x="97.895836"
-         y="71.4375">java.io</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="95.25"
-       y="84.666664"
-       id="text1802"><tspan
-         sodipodi:role="line"
-         id="tspan1800"
-         style="stroke-width:0.265"
-         x="95.25"
-         y="84.666664">java.nio</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="71.4375"
-       y="92.604164"
-       id="text1806"><tspan
-         sodipodi:role="line"
-         id="tspan1804"
-         style="stroke-width:0.265"
-         x="71.4375"
-         y="92.604164">java.utils</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="55.5625"
-       y="-132.29167"
-       id="text1810"
-       transform="rotate(90)"><tspan
-         sodipodi:role="line"
-         id="tspan1808"
-         style="stroke-width:0.265"
-         x="55.5625"
-         y="-132.29167">Внешние файлы</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="35.71875"
-       y="101.86459"
-       id="text1814"><tspan
-         sodipodi:role="line"
-         id="tspan1812"
-         style="stroke-width:0.265"
-         x="35.71875"
-         y="101.86459">read</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="51.59375"
-       y="112.44791"
-       id="text1818"><tspan
-         sodipodi:role="line"
-         id="tspan1816"
-         style="stroke-width:0.265"
-         x="51.59375"
-         y="112.44791">write</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="66.145836"
-       y="105.83334"
-       id="text1822"><tspan
-         sodipodi:role="line"
-         id="tspan1820"
-         style="stroke-width:0.265"
-         x="66.145836"
-         y="105.83334">concatenate</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="103.1875"
-       y="113.77084"
-       id="text1826"><tspan
-         sodipodi:role="line"
-         id="tspan1824"
-         style="stroke-width:0.265"
-         x="103.1875"
-         y="113.77084">search</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="111.125"
-       y="100.54166"
-       id="text1830"><tspan
-         sodipodi:role="line"
-         id="tspan1828"
-         style="stroke-width:0.265"
-         x="111.125"
-         y="100.54166">copy</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="15.875"
-       y="128.32292"
-       id="text1834"><tspan
-         sodipodi:role="line"
-         id="tspan1832"
-         style="stroke-width:0.265"
-         x="15.875"
-         y="128.32292">Интерфейсы</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="10.583333"
-       y="115.09375"
-       id="text1834-1"><tspan
-         sodipodi:role="line"
-         id="tspan1832-4"
-         style="stroke-width:0.265"
-         x="10.583333"
-         y="115.09375">Интерфейсы</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="13.229167"
-       y="93.927086"
-       id="text1834-6"><tspan
-         sodipodi:role="line"
-         id="tspan1832-3"
-         style="stroke-width:0.265"
-         x="13.229167"
-         y="93.927086">Интерфейсы</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="15.875"
-       y="83.34375"
-       id="text1834-2"><tspan
-         sodipodi:role="line"
-         id="tspan1832-6"
-         style="stroke-width:0.265"
-         x="15.875"
-         y="83.34375">Интерфейсы</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="21.166666"
-       y="140.22917"
-       id="text1838"><tspan
-         sodipodi:role="line"
-         id="tspan1836"
-         style="stroke-width:0.265"
-         x="21.166666"
-         y="140.22917">Другие программы</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:4.9389px;font-family:'IBM Plex Sans';-inkscape-font-specification:'IBM Plex Sans';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264999;stroke-linecap:square"
-       x="18.520834"
-       y="71.4375"
-       id="text1842"><tspan
-         sodipodi:role="line"
-         id="tspan1840"
-         style="stroke-width:0.265"
-         x="18.520834"
-         y="71.4375">Поиск в массиве</tspan></text>
-    <rect
-       style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect2054"
-       width="47.625"
-       height="15.875"
-       x="15.875"
-       y="60.854164" />
-    <rect
-       style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect2056"
-       width="79.375"
-       height="39.6875"
-       x="13.229166"
-       y="44.979168" />
-    <rect
-       style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect2058"
-       width="113.77083"
-       height="58.208332"
-       x="10.583333"
-       y="37.041668" />
-    <rect
-       style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect2060"
-       width="132.29167"
-       height="82.020836"
-       x="7.9375"
-       y="34.395832" />
-    <rect
-       style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.264999;stroke-linecap:square;stroke-opacity:1"
-       id="rect2062"
-       width="60.854168"
-       height="18.520823"
-       x="13.229167"
-       y="129.64583" />
-  </g>
-</svg>

scenarios/jtd1-06b.tex

@@ -1,8 +1,5 @@
 \documentclass[../j-spec.tex]{subfiles}
 
-\usepackage{tikz}
-\usepackage{aeguill}
-
 \begin{document}
 \section{GUI: Графический интерфейс пользователя}
 \begin{longtable}{|p{35mm}|p{135mm}|} 
@@ -23,19 +20,19 @@
 отбивка окно JFrame & Ну что, приобщаемся к прекрасному по порядку, создадим первое окошко? для этого нам понадобится то, что в терминах свинга называется джейфрейм.\\ \hline
 
 06-02 & Прежде чем мы начнём, ещё раз хочу вас успокоить: мы не изучаем фреймворк свинг, поэтому не надо зазубривать названия вообще всех классов и компонентов. Мы изучаем программирование и ООП, на примере и с использованием свинга, поэтому сосредоточьтесь, пожалуйста, на объектах, их свойствах и взаимосвязях. Создадим новый класс для нашей программы, и поскольку интереснее всего писать игры, а не какие-то сложные корпоративные программы, то мы назовём наш класс GameWindow, и приступим. Окошки мы будем рисовать при помощи библиотеки swing, основной для рисования в Java.
-%% 2
+%% 
 
 Для того чтобы начать, надо получить доступ к методам, содержащимся в библиотеке, а для этого, наш класс игрового окна должен быть наследником класса JFrame.
-%% 3
+%%
 
 Сразу на будущее - все модификаторы видимости будем делать публичными и дефолтными, потому что будем сегодня работать в одном пакете и не очень думать об инкапсуляции. Создадим конструктор.
-%% 4
+%%
 
 А в мэйн классе просто создадим новый объект нашего новоиспечённого класса с окошком. Пока ничего значительно отличающегося от котиков и пёсиков мы не сделали, страшно быть не должно. Если прямо сейчас запустить приложение, оно должно запуститься, и не подав никаких внешних признаков жизни завершиться, это признак того, что мы всё сделали верно, главное, что нет ошибок, а что именно произошло - пойдём выяснять.\\ \hline
 
 06-03 & Самое интересное это то, каким будет создано наше окно и где. большая часть свойств окна неизменна и задаётся в конструкторе, то есть окно при создании будет наделено какими-то свойствами, которые в некоторых случаях можно будет поменять во время работы этого окна. Самое не очевидное на первый взгляд, но очень логичное, когда окон в программе больше одного - это то, что в библиотеке свинг при нажатии на крестик в углу окна программа не завершается. По умолчанию, все создаваемые окна, как вы могли заметить, если запустили программу с нашим пустым окном,  невидимые. Это сделано потому что мы можем создавать сколько угодно окон для нашего приложения, и, согласитесь, было бы не слишком приятно, если бы наша программа закрывалась при закрытии первого попавшегося всплывающего окна, да и окна постоянно лезли бы в глаза пользователю не в нужные моменты, а в момент создания в программе.
 
-Для того, чтобы программа всё-же когда-нибудь закрылась, нужно придумать для неё основное окошко, и в нашем случае, на данный момент, оно будет единственным. Чтобы программа завершалась при закрытии этого только что созданного игрового окна (и это первое, что нужно делать при создании одно оконных приложений) мы установим нашему экземпляру JFrame такое свойство, как setDefaultCloseOperation, то есть установим, что нужно сделать, когда это окно закроется. Мы передадим туда константу EXIT\_ON\_CLOSE, чтобы программа завершалась вместе с закрытием окна. А если этого не сделать, то по умолчанию, окно просто снова сделается невидимым, и приложение не завершится. \\ \hline
+Для того, чтобы программа всё-же когда-нибудь закрылась, нужно придумать для неё основное окошко, и в нашем случае, на данный момент, оно будет единственным. Чтобы программа завершалась при закрытии этого только что созданного игрового окна (и это первое, что нужно делать при создании одно оконных приложений) мы установим нашему экземпляру JFrame такое свойство, как setDefaultCloseOperation, то есть установим, что нужно сделать, когда это окно закроется. Мы передадим туда константу EXIT_ON_CLOSE, чтобы программа завершалась вместе с закрытием окна. А если этого не сделать, то по умолчанию, окно просто снова сделается невидимым, и приложение не завершится. \\ \hline
 
 06-04 & Естественно, теперь очень сильно хочется, чтобы окно стало видимым, но не спешите, сначала мы припомним, почему мы можем просто брать и вызывать методы, которые никогда не видели из конструктора нашего окна не обращаясь даже ни к каким объектам через точку? из-за устройства фреймворка Swing, из-за наследования от JFrame, из-за импорта классов Swing
 
@@ -44,10 +41,10 @@
 конечно же это происходит из-за наследования, наше окно теперь не просто использует жфрейм, а само является жфреймом. это и есть то самое применение ООП в жизни.\\ \hline
 
 06-05 & Быстро добавим всяких констант для нашего окошка. Как мы помним, считается хорошим тоном не держать в коде никаких магических цифр, чтобы не думать, что они значат и почему они именно такие, и что будет если их поменять, поэтому объявим ширину и высоту окошка в виде вынесенной константы. Я уже говорил, что принято константы писать большими буквами, или оставил вас в жестоком неведении? пишем высота = 555, ширина = 507, положение окна по оси икс = 800, положение окна по оси игрек = 300.
-%% 2
+%%
 
 соответственно и настроим размеры окна в конструкторе, настроим позицию на экране стандартными методами. Ну и давайте наконец на него взглянем. По-умолчанию наше окошко невидимое, а мы сделаем его видимым setVisible true.
-%% 3
+%%
 
 Короткая справка, пока мы наслаждаемся видом нашего первого окна. Окно -- это всегда отдельный поток программы, и окно крутится в бесконечном цикле, в этом бесконечном цикле есть очередь сообщений, которые цикл опрашивает и выполняет. \\ \hline
 
@@ -63,148 +60,238 @@
 
 вызовом методов в конструкторе окна, потому что наше окно теперь наследует все свойства и методы окна в библиотеке \\ \hline
 
-отбивка Компоненты и менеджеры размещений & Пустое окно - это скучно, поэтому на него обязательно надо что-то добавить и как-то это расположить. поговорим об этом, начнём сразу писать графическую оболочку для игры крестики-нолики. \\ \hline
+отбивка Компоненты и менеджеры размещений & Пустое окно - это скучно, поэтому на него обязательно надо что-то добавить и как-то это расположить. поговорим об этом. \\ \hline
 
-06-08 & для того, чтобы точно ничего не перепутать в процессе разработки, напишем заголовок setTitle, запретим пользователю изменять размеры нашего окна, для крестиков-ноликов это будет важно, чтобы всё красиво отображалось и никуда не уплывало пишем setResizeable. И начнём говорить об элементах графического интерфейса. Элементы это всем нам знакомые кнопочки, текстовые поля, лейблы, и всякое остальное. Начнём с кнопки «новая игра».
-%% 2
+ & \\ \hline
+ & \\ \hline
+ & \\ \hline
+ & \\ \hline
+ & \\ \hline
 
-За кнопки отвечает класс JButton, его экземпляр мы и создадим, JButton btnStart = new JButton(); можно сразу в конструкторе задать надпись, которая будет отображаться на кнопке пишем надпись «New Game». и сразу напишем ещё одну кнопку, например, «выход».
-%% 3
-
-Одну из них добавим на окошко. для этого воспользуемся внутри конструктора методом с достаточно понятным для окна названием add(), который просит в сигнатуре передать ему какой-то компонент. Все кнопки-лейблы - это наследники класса Component. Можем взять любой компонент и проследить по иерархии, дойдём до класса Компонент.
-%% 4
-
-Итак вот мы в конструкторе добавили кнопку, и можем запустить, увидеть, что она заняла всё окно нашего приложения. Если убрать вызов метода setResizeable, то увидим, что если мы решим поменять размер окна, размер кнопки также будет меняться. Такой, адаптивный дизайн получается. \\ \hline
-
-06-09 & При попытке добавить вторую кнопку на это окно, увидим, что вторая кнопка полностью перекрыла первую. Тут приходит пора поговорить о компоновщиках, или, как их ещё называют, менеджерах размещений. Менеджеры размещений нужны для того, чтобы не думать каждый раз о том, как изменится размер и координаты конкретного элемента, скажем, при изменении окна и не писать сложное поведение вложенных компонентов чтобы достаточно просто отобразить то, что привычно пользователю. Компоновщики активно используются в любом программировании графических интерфейсов в любых языках программирования, от С++ до джаваскрипта, просто потому что это достаточно удобный механизм, берущий на себя значительный пласт работы. \\ \hline
-
-06-10 & Менеджер размещения или компоновщик, как следует из названия -- это специальный объект, который помещается на некоторые компоненты и осуществляет автоматическую расстановку добавляемых к нему, компоненту, согласно каким-то прописанным внутри данного менеджера размещения правилам. Чуть забегая вперёд можно сказать, что это контейнеры, реализующие программный интерфейс под названием RootPaneContainer, но это так, шестерёнки, которые заучивать не нужно. Важно понимать, что именно делают компоновщики -- размещают компоненты. Список менеджеров можно увидеть на слайде. Все их можно создать, так сказать пощупать, попробовать в работе и это достаточно сильно зависит от задачи -- какой именно выбрать для использования на том или ином экране. О трёх самых популярных сейчас поговорим.\\ \hline
-
-06-11 & По умолчанию в библиотеке swing используется компоновщик borderLayout. Он располагает всё, что вы ему передаёте в центре, но также у него есть ещё четыре положения. маленькие области по краям. Если мы не занимаем какую-то область компонентом, она схломывается до нулевых размеров, оставляя место другим компонентам. Поэтому, если мы хотим какой-то наш компонент расположить где-то не в центре, мы должны это явно указать при добавлении. Тут немного неочевидно, поэтому запомните, пожалуйста, что при добавлении надо указать ещё один параметр, константу, например, BorderLayout.SOUTH. вот так неожиданно сюда сторона света приплелась, юг. Или вот, например, FlowLayout() будет располагать элементы друг за другом в том порядке, как мы пишем, слева направо, сверху вниз, как мы привыкли писать рукой на бумаге. Компоновщик-сетка при создании принимает на вход число строк и столбцов и располагает компоненты в получившейся сетке. Ну и так далее всякие ГридБэгЛэйауты и прочие. Ещё раз, основная идея, которую надо понять, это не названия компоновщиков, а то, что в свинге вся работа происходит через компоновщики - вот эти вот самые лэйауты, которые как-то по-своему располагают элементы в окошке. Кстати, если это ещё не стало очевидным, кнопки расположились одна поверх другой потому что по умолчанию к фрейму применён БодэЛэйаут, который всё располагает по-умолчанию в центре. \\ \hline
-
-06-12 & Одними лэйаутами сыт не будешь, так что разработчики джавы придумали использовать не только компоненты сами по себе, но ещё и группы элементов, группы элементов складывают на так называемые JPanel. И внутри каждой панели мы можем использовать свой лэйаут. Jpanel - это по умолчанию невидимый прямоугольник, основным свойством которого для нас в данный момент является то, что на нём может находиться собственный компоновщик, что открывает для нас близкие к бесконечным возможности по расстановке компонентов на экране. Например, мы можем создать для нашего окна некую панель с кнопками внизу (или вверху, не важно), а всё остальное пространство оставить под другие важные вещи. На слайде можно увидеть код панели, добавление её в нижнюю часть основного экрана, расположение внутри панели компоновщика и двух кнопок. И, соответственно, результат. Обратите особенное внимание на 25ю строку, на экран мы добавляем не кнопки по отдельности, а компонент, на который предварительно добавили кнопки. \\ \hline
-
-06-13 & ЖПэнел настолько хорош и полезен, что мы не можем посвятить ему всего один слайд. Основые графические интерактивности мы будем делать именно на панели, поэтому надо как минимум создать класс с основной игровой панелью. Назовём её как-нибудь хорошо, например, Мэп, потому что это будет карта поля сражения в крестики-нолики. Опишем конструктор, и пока что нашу новенькую панельку просто сделаем чёрной, чтобы увидеть её на белом окне. Для этого в конструкторе воспользуемся сеттером цвета фона и цветовой константой setBackground(Color.BLACK).
-%% 2
-
-Естественно, чтобы панелька не висела в воздухе, нужно создать её объект как на 22й строке и поместить куда-нибудь на основной экран, как на 28й строке. и вот она, нарядная, чёрная, как мы и задумали, заняла вообще всё место на окне, кроме юга, где уютно расположилась панель с кнопками. \\ \hline
-
-06-14 & Внутри панели, кстати, раз уж это поле боя, сразу предлагаю написать метод, который будет начинать этот самый бой, назовём этот метод как-нибудь необычно, например, startNewGame(). А что метод будет принимать, давайте подумаем: например, у нас будут два режима игры, компьютер против игрока и игрок против игрока, первый мы напишем сразу, второй на семинаре, значит нужен int mode, дальше, что естественно, размер поля, и давайте сразу не будем привязываться к квадратному полю 3х3, поэтому сделаем int fieldsizex, int fieldsizey. и соответственно для полей больше, чем 3х3 нам понадобится выигрышная длина, то есть число крестиков или ноликов, расположенных подряд на одной прямой для победы той или иной стороны, да что я вам объясняю, знаете сами. сейчас, на всякий случай, поставим здесь так называемые заглушки, чтобы мы знали, что метод вызывается и всё у него хорошо, напишем sout(mode, sizes, winlen). \\ \hline
-
-06-15 & Сразу давайте всю архитектуру опишем, чтобы потом было несложно её расширять и наполнять. наше приложение будет работать в двух окнах, первое будет стартовое, где мы зададим настройки поля и выберем режим игры, и основное, где будет происходить собственно игра. Основное окно у нас есть, и при его закрытии мы выйдем из программы, давайте опишем стартовое окно, для этого создадим ещё один класс, назовём его как-нибудь умно, SettingsWindow, унаследуем от JFrame, делаем конструктор, который, смотрите-ка принимает экземпляр игрового окна. Вспомогательному окошку понадобится основное, чтобы красиво отцентрировать его относительно основного, а не лишь-бы куда пихнуть.
-%% 02
-
-в нашем GameWindow нам понадобится две константы, одна класса StartNewGameWindow чтобы мы могли это окошко показывать когда захотим и вторая это наша панелька для Map. В основном окне вызовем сеттингсВиндоу = new сеттингсвиндоу(this), обратите внимание, вот ещё один способ применять this, когда нам надо передать методу объект, который вызывает этот метод, фактически, основное окно передаёт себя. ну и сразу для удобства разработки сделаем окно настроек видимым.
-%% 03
-
-На слайде мы видим то, что можно с очень большой натяжкой назвать диаграммой классов, моей целью было не создание идеальной диаграммы, а более-менее понятное объяснение того, что мы тут напрограммировали. Буквами Ф обозначены экземпляры ЖФрейм, буквой П ЖПанель, а А это эппликейшн, то есть приложение. Итак у нас есть самый скучный в мире Мейн, который ничего не делает, а только создаёт новое игровое окно. окно на котором лежит мэп с игрой и которое время от времени будет обращаться к сеттингсам за настройками новой игры. \\ \hline
- 
-06-16 & окно с настройками игры. у меня было очень большое желание сделать тут кучу компонентов как-нибудь интересно связать их, но я понял, что в этом случае чрезвычайно скучно будет сидеть на семинаре, поэтому окно настроек игры у нас будет представлено одной кнопкой старта игры, вызывающей метод старта игры с одним зафиксированным набором настроек -- игра с компом, поле 3х3, чтобы выиграть надо собрать 3 крестика (или нолика) подряд. О веселье на семинаре подумали, давайте придумаем что-то, чтобы было не скучно прямо сейчас и сделаем относительное позиционирование. В данный момент окно создаётся в координатах 0-0 и имеет размер 0-0, то есть в левом верхнем углу экрана мы просто увидим кнопки свернуть-развернуть-закрыть. нас это не очень устраивает, тем более, что мы передали этому окну настроек ссылку на объект игрового окна, поверх которого мы и хотим отобразить окно настроек. Поэтому создадим нашему окну какие-нибудь размеры и скажем, что его местоположение должно быть относительным главному окну. Уже знакомым способом бросим на всё окно кнопку подтверждения правильности настроек и старта игры. \\ \hline
-
-06-17 & Дальше совсем никак не получится продолжить беседу без небольшого количества магии. Нам нужно оживить кнопки на окнах, это делается специальной конструкцией, синтаксис которой мы будем понимать уже на следующем уроке, но пока что вынуждены просто запомнить. Есть хорошая новость, идея нам хорошо подсказывает какие скобочки где должны стоять, чтобы всё работало.
-%% 2
-
-Хорошая новость, кстати в том, что синтаксически вы уже можете понять что именно здесь написано -- у объекта кнопки батонЕксит вызывается метод добавления к этому объекту некоторого слушателя действия. а какое может у кнопки быть самое очевидное действие? на неё нажали. в аргумент метода добавления передаётся некоторый новый объект класса слушатель действия, у которого переопределяется метод действие произошло. как видите, все кусочки этого паззла вам по отдельности знакомы.
-%% 3
-
-добавим действие при нажатии на кнопку выхода - заставим приложение выйти и создадим аналогичный слушатель для кнопки старта новой игры. Эта кнопка будет вызывать наше стильное окно с настройками, которое пока что без настроек, как мы помним. ну, как вызывать... просто делать его видимым, потому что оно уже создано и только этого и ждёт. тут то нам и пригодится то, что закрытие окна не убивает программу, а только окно уходит в невидимость \\ \hline
-
-06-18 & теперь возьмёмся за описание последовательности выполнения нашей программы. в основном окне нам понадобится метод, инициализирующий новую карту, то есть мы не будем напрямую вызывать по кнопке старта новой игры на окне настроек метод в панели основного окна. Зачем мы так делаем, казалось бы усложняем, но нет, смотрите, панелька находится на основном окне. а кнопка начала игры будет находиться на другом окошке, которое вообще не в курсе, какие у нас там панельки, или может там вообще дальше нет никакого интерфейса. В этом и есть суть ООП, когда один объект максимально отделён от другого, и каждому из них вообще наплевать, как реализован другой. Соответсвенно, мы в настроечном окошке нажали кнопку начать игру, и оно главному окну говорит - давай, начинай новую игру, а главное окно уже знает, что оно разделено на панельки, и говорит мэпу, мол, давай, пора начинать. понимаете для чего вот этот промежуточный метод? Чтобы не делать лишних связей между классами. это логично с точки зрения абстракций. Одно окно не должно никак управлять панелькой на другом окне.
-% 02
-
-В окне настроек, пишем обработчик для единственной кнопки, и из этого обработчика вызываем единственный доступный нам метод старта новой игры - на основном окне. и спрячем окно настроек вызвав метод сетВизибл с аргументом фолс.  а startNewGame() класса мэп, вызываем из метода основного класса через map.startNewGame. Ещё раз цепочка вызовов - основное окно делает окно настроек видимым, окно настроек говорит основному, что пора начинать игру, основное окно уже в свою очередь знает, как именно надо эту игру начинать и просит панельку стартовать. Если всё сделано верно, видим в терминале вывод из нашей заглушки на панели мэп. \\ \hline
-
-06-19 & Значительная часть сложностей сегодняшней лекции позади, давайте попробуем вспомнить, о чём мы вообще тут говорили. Менеджер размещений - это 1. сотрудник, занимающийся разработкой интерфейса 2. объект, выполняющий расстановку компонентов на окне приложения 3. механизм, проверяющий возможность отображения окна в ОС
-
-... 30 сек ...
-
-Конечно же второе, объект, выполняющий расстановку компонентов на окне приложения. Экземпляр JPanel позволяет 1. применять комбинации из компоновщиков 2. добавить к интерфейсу больше компонентов 3. создавать группы компонентов 4. всё вышеперечисленное
-
-... 30 сек ...
-
-и да, все ответы верны, панель - это вообще довольно интересное изобретение, дальше мы вообще будем на ней рисовать. Для выполнения кода по нажатию кнопки на интерфейсе нужно 1. создать обработчик кнопки и вписать код в него 2. переопределить метод нажатия у компонента кнопки 3. использовать специальный класс “слушателя” кнопок
-
-... 30 сек ...
-
-и здесь правильным ответом будет первый, естественно, сам компонент нам переопределять не нужно, у нас инкапсуляция, да и никаких общих слушателей вообще всех кнопок не существует. \\ \hline
-
-06-20 & К сложному и интересному. мы же хотим, чтобы было очень красиво, а не просто как-то средне, поэтому будем учиться рисовать. да и лекция всё таки про графический интерфейс, совсем не сказать про рисование графики было бы неправильно. \\ \hline
-
-06-21 & Итак, всё что будет происходить дальше - будет происходить на панели с картой. первое, что мы хотим с ней сделать - это перестать раскрашивать её в чёрный. Нам надо научиться на этой самой панели рисовать. для этого фреймворком свинг определён метод панели paintComponent(). он вызывается фреймворком когда что-то происходит, например, когда мы перекрываем наше окно каким-то другим, или двигаем само окно на другой экран, или, например сворачиваем-разворачиваем окно, но в любом случае вызывается он гораздо реже, чем нам нужно. А нужно нам перерисовывать компонент по каждому клику мышкой, например.
-
-Важно помнить, что мы не должны непосредственно этот метод вызывать из кода. этот метод должен вызываться только фреймворком, для того чтобы очень сильно попросить фреймворк тоже есть специальный метод, но сейчас нам важно не это, сейчас нам важно отделить стандартный метод рисования компонента от собственно нашего рисования на этом компоненте, так сказать, бизнес-логику. давайте создадим ещё один метод void render(Graphics g) и будем его вызывать из переопределённого paintComponent(); из самого пэинткомпонента супер вызов удалять не будем, потому что наверняка там происходит что-то очень важное, а мы точно не хотим ничего сломать. Опять же если копнуть немного вглубь, мы когда-нибудь скажем фреймворку что надо перерисовать панельку, он поставит метод пэйнтКомпонент куда-то в очередь сообщений окна, и когда очередь до этого метода дойдёт - окно выполнит перерисовку. то есть действие полностью асинхронно и не напрямую зависит от наших вызовов \\ \hline
-
-06-22 & Итак чтобы рисовать нужен как ни странно объект графики, который умеет, внезапно, рисовать всякие геометрические фигуры, линии и прочие штуки. Вот например линия из координат 0-0 в координаты 100-100, длиной, получается, примерно в 141,5 пиксель, теорему пифагора же все помнят? А чтобы нарисовать сеточку нам понадобится не только прямая линия, но также ширина и высота нашего поля в пикселях. Как их узнать? у панельки есть свойства ширина и высота, ими и воспользуемся, создав две дополнительные переменные int panelWidth = getWidth(); int panelHeight = getHeight();
-%% 2
-
-всё, что связано с размерами, наверное, лучше вынести в переменные объекта, просто потому, что они нам, скорее всего, понадобятся в каких-нибудь ещё методах, не находить же их заново. А помимо ширины и высоты нам понадобятся переменные, в которых мы будем хранить высоту и ширину каждой ячейки. размеры каждой ячейки пригодятся, например, для создания отступа одной линии от другой, так что заведём две переменные cellW, cellH. на семинаре мы будем их формировать как-то умно, а пока что мы возьмём ширину и высоту панели и поделим на три;
-%% 3
-
-и в методе который рендерит разлинуем. идём циклом от 0 до меньше либо равно 3 потому что высота поля равна трём ячейкам и рисуем горизонтальные линии, пишем (y = i * cellH; g.drawLine от 0, y до panelWidth, y). аналогичный цикл делаем по ширине от 0 до 3 и рисуем аналогично вертикальные линии
-
-у многих после запуска этого кода не полностью рисуется или вовсе не рисуется разлиновка, это происходит из-за асинхронности рисования, упомянутой парой минут ранее, так уж устроена отрисовка в свинге, чтобы не жрать много ресурсов, скорее всего наш метод с линиями отработал уже после того, как свинг нарисовал панельку. мы должны заставить наш компонент полностью перерисоваться. сделаем это вызвав метод repaint(); из метода startNewGame; то есть в методе старта игры мы в перспективе все переменные инициализировали и попросили панель перерисоваться. \\ \hline
-
-06-23 & Теперь сделаем ещё одну магию, которая будет очень похожа на ту, что мы уже изучили, добавим слушателя на мышку. В конструкторе панели пишем addMouseListener(new MouseAdapter() {}) нам понадобится переопределить метод mouseReleased(), то есть нам важно когда пользователь отпустит кнопку (для сенсорных экранов андроида это метод touchUp()) и снова чтобы не заполнять конструктор огромным количеством кода, создадим отдельный метод update(MouseEvent e) и вызовем его из обработчика мышки. В нем мы тоже принудительно вызовем репэйнт, чтобы получился некий игровой цикл, старт - отрисовка, клик мыши, отрисовка, клик-отрисовка. На самом деле это делается ещё и для того чтобы мы саму логику, например, могли портировать куда-то ещё. не обязательно же мышка должна вызывать у нас изменения игрового поля, а например тап по тачскрину или вызов по сети.
-%% 2
-
-Теперь в методе update из класса MouseEvent вытаскиваем координаты клика, делим на размер ячейки и тем самым получаем номер ячейки, в которую мы кликнули. пишем: int cellX = e.getX/cellW; int cellY = e.getY/cellH. для верности можем их вывести на экран, чтобы посмотреть как это работает и работает-ли. на слайде видно, как я прокликал каждую ячейку слева направо сверху вниз. \\ \hline
-
-06-24 & далее мы очень быстро пробежимся по логике игры в крестики-нолики просто потому что лекция всё таки больше про графические интерфейсы и ООП, чем про алгоритм игры. \\ \hline
-
-06-25 & Итак нам понадобится генератор псевдослучайных чисел, потому что мы не будем на лекции создавать очень умного противника, символы, которыми мы будем обозначать на поле игрока, компьютер и пустую ячейку, собственно поле и его размеры. Размеры - на будущее.
-%% 2
-
-Метод инициализации поля - просто создаём новый массив и заполняем его пустотой. Его вызов будет логично сразу разместить в метод старта новой игры.
-%% 3
-
-Когда кто-то, мы или компьютер, будет совершать ход, нам будет важно, попал ли игрок ввобще в какую-то ячейку поля и пустота ли там, потому что, насколько я помню, нельзя ставить крестик поверх нолика и наоборот
-%% 4
-
-Компьютер, как я и сказал, будем делать очень примитивный, он просто будет делать ход в случайные места на карте. Перед тем, как я покажу следующий слайд я прошу слабонервных удалиться от экранов и напоминаю, что мы делаем программу в учебных целях
-%% 5
-
-как вы видите, учебные цели предполагают не только демонстрацию того, как надо делать, но также и демонстрацию того как делать не надо. все трюки выполнены профессионалами, ни один тимлид после ревью кода не пострадал. на работе никогда так не делайте, всегда пишите с помощью циклов, потому что стоит нам захотеть поиграть на поле 4х4 или 5х5 - этот метод будет расти в геометрической прогрессии. метод принимает на вход символ, который нужно проверить и проверяет - не победил ли он.
-%% 6
-
-а вот, например, достаточно хороший метод проверки поля на состояние ничьей. напомню, ничья в крестиках ноликах - это когда никто не победил и пустых клеток не осталось. \\ \hline
-
-06-26 & Итак, теперь наша программа не просто умеет быть красивым окошком, но и может понять ряд интересных вещей, таких как, верный ли сделан ход, наступила ли ничья или кто-то победил. Всё, что мы будем делать дальше, будет сконцентрировано на методах обновления игрового состояния и отрисовки игрового поля. Ну что, нашли мы кликнутую ячейку, давайте в неё ходить, только нам для начала надо проверить, валидная-ли ячейка, и можно-ли туда ходить, вот и проверим: (если не валидная ячейка по координатам (cellX, cellY) или не пустая ячейка по тем же координатам) return; то есть если что-то пошло не так, игнорим клик, выходим из метода, ну а если всё хорошо - просто ходим филд[селХ][селУ] = humandot;
-%% 2
-
-И добавим в метод отрисовки ещё немного логики. сделаем обход всех ячеек поля и внутри пишем, если ячейка пустая - просто идём дальше, ничего не делаем, дальше пишем маленькую заготовку: если в ячейке крестик - что-то сделаем, если нолик - сделаем что-то другое и в противном случае выбросим новый рантайм эксепшн с текстом (не пойму что в ячейке + и,ж), мало ли что мы там перекодили и допилили, может решили сделать баттл для трёх игроков?
-%% 3
-
-И теперь пришли к отрисовке. хотите, можете сюда картинку вставлять, хотите закрашенные квадратики, хотите рисуйте крестики-нолики, я для простоты буду пользоваться методом объекта графики g.fillOval() и буду рисовать кружки. ему в сигнатуре передаётся левая верхняя координата прямоугольника, в который потом будет вписан овал, и его ширина и высота соответственно. тем, кто хоть раз рисовал в пэинте - знакома эта техника рисования кружков. ну и чтобы придать ему цвета - перед тем как рисовать изменим цвет объекта graphics, g.setColor(Color.BLUE); Итак я предлагаю для человека рисовать синие кружки, а для компа красные. и чтобы сделать небольшой отступ от границ ячейки сделаем следующее, заведём константу DOTSPADDING = 5 пикселя. и первые координаты смещаем на + пэддинг вторые на - 2 пэддинга. Так посимпатичнее.
-%% 4
-
-по сути, нам осталось сделать две вещи - прикрутить так называемую бизнес логику, то есть в правильном порядке повызывать методы с логикой игры, избавиться от пары выпадающих исключений и нарисовать сообщение об окончании игры. начнём с конца. с конца игры. для того чтобы вывести результат, мы не будем придумывать ещё одно окно, это не слишком интересно, лучше напишем поверх игрового поля сообщение, а для этого нам надо как-то передать информацию о том, что игра завершена, для этого придумаем состояние окончания игры и опишем его вариации. \\ \hline
-
-06-27 & Получается, теперь осталось это только оживить и нарисовать. Идём в метод апдейт и уточняем, что когда пользователь поставил точку, надо проверить состояние поля на наличие победы или ничьей, дать возможность компу поставить точку и сделать тоже самое
-%% 2
-
-дальше в принципе нам только и надо что нарисовать все красотульки. значит идём в метод рендер и думаем там. как только мы вывели поле, и если игра закончилась нам надо вывести сообщение с одним из вариантов исхода. так и запишем if (gameOver) шоуМессаджГеймовер(g); вот просто перевели наши слова на английский. теперь смотрим, чего у нас для этого не хватает в коде, как минимум метода шоумессаджгеймовер() и переменной признака конца игры. да не вопрос, мыжпрограммисты, напишем войд шоумессаджгеймовер(Graphics g), и где-то там вверху private boolean окончена ли игра. и поехали наполнять эти штуки смыслом. метод окончания игры рисует тёмно серый прямоугольник с жёлтой надписью о победе одного из игроков или ничьей в зависимости от геймоверстейта. если вдруг не поняли какой стейт у геймовера - кинули исключение.
-%% 3
-
-Осталось куда-то деть булево с окончанием игры и понять что за исключение у нас возникает при старте приложения. Почитав текст исключения мы понимаем, что оно возникает, когда программа не может что-то поделить на ноль. А что и когда она не может поделить на ноль? размеры поля до их инициализации, поэтому нам понадобиться ещё одна булева переменная - инициализирована ли игра.
-
-В конструкторе панели, очевидно, поле ещё не инициализировано
-
-В апдейте, очевидно, что нет смысла обрабатывать клики по неинициализированному полю или полю на котором закончилась игра
-
-В старте новой игры, очевидно, игра перестаёт быть законченой, а поле становится инициализированным
-
-Рендерить на неинициализированном поле нам тоже ничего не нужно.
-
-А вот там, где мы проверяли не победил ли кто, нужно добавить истинность булевой с геймовером. \\ \hline
-
-06-28 & Результат наших трудов вы можете видеть на экране, мне кажется, что получилось неплохо, да и с графическими интерфейсами короткое знакомство провели. \\ \hline
-
-06-29 & На этой лекции мы познакомились с тем, как создавать окна, поговорили о менеджерах размещений, элементах графического интерфейса, и обработчиках событий. Многое осталось за границей этой лекции, во многом из-за того, что мы ещё не изучили такие интересные темы, как многопоточность и программные интерфейсы, но обязательно изучим. Изучение графических фреймворков не должно становиться для вас целью, если не хотите связать своё будущее с фронтенд разработкой, а раз уж вы здесь, думаю, вы уже сделали свой выбор. Разработка графического интерфейса подобного рода должна стать утилитарной задачей, то есть, решаться по мере поступления каких-то вопросов, поэтому мы оставим вопрос разработки графических интерфейсов на будущее самостоятельное изучение или даже лучше - просто периодически будем к ним возвращаться и делать наши приложения более привлекательными визуально. \\ \hline
-
-06-30 & В качестве домашнего задания именно по графическим интерфейсам нужно будет полностью и досконально разобраться с кодом. Не бойтесь записывать свои вопросы и задавать их на семинарах и наставникам. А чтобы попрактиковаться в программировании нужно переделать метод проверки победы, чтобы на него не было больно смотреть. Будет классно, если получится сделать метод проверки победы для поля любого размера и любого числа крестиков-ноликов для победы, то есть, например, чтобы победить на поле 5х5 нужно собрать линию из 4х крестиков. Ну и если останется время, я отметил это задание аж двумя звёздочками, подумайте, как сделать компьютер немного умнее, чем просто случайным. специально отмечу в формулировке задания слово примитивно, потому что никто не ожидает от вас каких-то разборов графовых алгоритмов, минимакса и прочей теории игр. \\ \hline
-
-06-31 & На сегодня это всё. Напоследок соглашусь с Иоганном Вольфгангом фон Гёте, если не очень нравится что-то делать, научиться этому будет довольно трудно. а если трудно, то правильно ли выбрано направление? Любите то, чему учитесь, знания будут сами собой оставаться в голове, без усилий. \\ \hline
 \end{longtable}
-
 \end{document}
 
+
+***** Давайте начнём сразу писать графическую оболочку
+	  для игры крестики-нолики, для этого напишем заголовок setTitle, запретим пользователю изменять размеры нашего окна, для крестиков-ноликов это будет важно, чтобы всё красиво отображалось и никуда не уплывало пишем setResizeable. И начнём говорить об элементах графического интерфейса. Элементы это всем нам знакомые кнопочки, текстовые поля, лейблы, и всякое остальное. Начнём с кнопки «новая игра». 
+	  За кнопки отвечает класс JButton, его экземпляр мы и создадим, JButton btnNewGame = new JButton(); можно сразу в конструкторе задать надпись, которая будет отображаться на кнопке пишем надпись «New Game». и сразу напишем ещё одну кнопку, например, «выход». Давайте одну из них добавим на окошко. для этого воспользуемся методом add(), который просит в сигнатуре передать ему какой-то компонент. 
+	  Все кнопки-лейблы - это наследники класса Component. Можем проследить по иерархии, дойдём до класса Компонент. Итак вот мы в конструкторе её добавили, и можем запустить, увидеть, что наша кнопка заняла всё окно нашего приложения. давайте уберём вызов метода setResizeable, и увидим, что если мы решим поменять размер окна, размер кнопки также будет меняться. Такой, адаптивный дизайн получается. 
+	  Теперь попробуем добавить вторую кнопку, и видим, что вторая кнопка полностью перекрыла первую. 
+***** Пришла пора поговорить о компоновщиках, 
+	  или как их ещё называют, менеджерах размещений. Очень рекомендую погуглить какого нибудь дополнительного материала на эту тему, она не очень простая
+	  =======рисовать===========
+	  По умолчанию в библиотеке swing используется компоновщик borderLayout. Он располагает всё, что вы ему передаёте в центре, но также у него есть ещё четыре положения. маленькие области по краям. Поэтому, если мы хотим какой-то наш компонент расположить где-то не в центре, мы должны это явно указать при добавлении. Тут немного неочевидно, поэтому запомните, пожалуйста, что при добавлении надо указать ещё один параметр, константу BorderLayout.SOUTH. вот так неожиданно сторона света приплелась сюда, юг. 
+	  Давайте попробуем поиграться, добавим какой-то другой лэйаут, например, setLayout(new FlowLayout()); он будет располагать элементы друг за другом в том порядке, как мы пишем, слева направо, сверху вниз. Ну и так далее 
+	  всякие ГридЛэйауты и прочие, некоторые рассмотрены в методичке, некоторые можно увидеть на вышеупомянутых вебинарах, давайте лучше сегодня побольше поговорим о коде нашего приложения. Если каких-то принципиальных вопросов по компоновщикам нет, давайте продолжим. Основная идея, которую надо понять, что в свинге вся работа происходит через компоновщики - вот эти вот самые лэйауты, которые как-то по-своему располагают элементы в окошке. 
+***** Одними лэйаутами сыт не будешь, 
+	  так что джависты придумали использовать не только компоненты сами по себе, но ещё и группы элементов, группы элементов складывают на так называемые JPanel. И внутри каждой панели мы можем использовать свой лэйаут. (рисуем окно и две панельки, большую и под ней маленькую)
+	  Внутри нижней панели у нас будет грид лэйаут, а на верхней мы будем ручками рисовать наше поле. Ну и от слов к делу, создадим ещё один класс, назовём его Map, и он у нас в программе будет отвечать за поле для игры, унаследуем его от JPanel, опишем конструктор, и пока что её просто сделаем чёрной, чтобы увидеть её на окне. для этого воспользуемся вот такой константой setBackground(Color.BLACK). ну и создадим для неё метод startNewGame(), который на вход должен что то принимать. 
+	  А что принимать, давайте подумаем: у нас будут два режима игры, компьютер против игрока и игрок против игрока, первый мы напишем, второй будет домашним заданием, но пишем, int mode, дальше, что естественно, размер поля, и давайте сразу не будем привязываться к квадратному полю, поэтому сделаем int field_size_x, int field_size_y. и соответственно для нашей логики из третьего занятия, нам понадобится выигрышная длина. давайте сейчас на всякий случай поставим здесь так называемые заглушки, чтобы мы знали, что метод вызывается и всё у него хорошо, напишем sout(mode, sizes, win_len)
+***** Сразу давайте всю архитектуру опишем, 
+	  наше приложение будет работать в двух окнах, первое будет стартовое, где мы зададим настройки поля и выберем режим игры, и основное, где будет происходить собственно игра. Основное окно у нас есть, и при его закрытии мы выйдем из программы, давайте опишем стартовое окно, для этого создадим ещё один класс, назовём его StartNewGameWindow, унаследуем от JFrame, делаем конструктор. в нашем GameWindow нам понадобится две константы, одна класса StartNewGameWindow чтобы мы могли это окошко показывать когда захотим и вторая это наша панелька для Map. 
+	  Сразу скажу, что нашему вспомогательному окошку понадобится основное, поэтому в конструктор мы его передадим, ну чтобы красиво отцентрировать его относительно основного, а не лишь-бы куда пихнуть. в основном окне вызовем startNewGameWindow = new SNGW(this), вот, кстати, ещё один способ применять this, когда нам надо передать методу объект, который вызывает этот метод.
+	  Теперь создадим панельку для кнопочек в основном окне, для панелей у нас есть класс Jpanel, пишем JPanel pBottom = new JPanel(); в ней как мы помним из чудо картинки мы можем поставить любой лэйаут, и будем использовать setLayout(newGridLayout); который на вход будет у нас требовать два параметра, количество строк и количество столбцов на которые он будет стараться всё поделить. для нас это будет 1 и 2. и на неё мы добавим наши кнопки. pBottom.add(btnNewGame); и pBottom.add(btnExitGame); Создадим нашу карту, map = new Map; и добавим все эти чудные элементы управления на окошко add(map, borderLayout.CENTER), add(pBottom, BL,SOUTH); и вот после всего того что мы описали наше приветственное второе окно должно стать видимым, чтоб мы выбрали с вами параметры для нашей новой игры, startNewGameWindow.setVisible(true);
+***** Переварили? 
+	  теперь возьмёмся за описание последовательности выполнения нашей программы. в основном окне нам понадобится метод, инициализирующий новую карту, помните мы там для панельки конструктор писали? вот вызывать мы его будем отсюда. копипастим void startNewGame() из класса мэп, и вызываем из метода основного класса метод из панельки map.startNewGame. 
+	  Зачем мы так делаем, казалось бы усложняем, но нет, смотрите, панелька находится на основном окне. а кнопка начала игры будет находиться на другом окошке, которое вообще не в курсе, какие у нас там панельки, или может там вообще дальше нет никакого интерфейса. В этом и есть суть ООП, когда один объект максимально отделён от другого, и каждому из них вообще наплевать, как реализован другой. Соответсвенно, мы в стартовом окошке нажали кнопку начать игру, и оно главному окну говорит - давай, начинай новую игру, а главное окно уже знает, что оно разделено на панельки, и говорит мэпу, мол, давай, пора начинать. понимаете для чего вот этот промежуточный метод?
+	  Чтобы не делать лишних связей между классами. это логично с точки зрения абстракций. Одно окно не должно никак управлять панелькой на другом окне. И таким образом мы уже прям почти закончили с классом GameWindow. 
+	  осталось только поговорить здесь о последней на сегодня теме - об обработчиках событий. Тут на данный момент для вас будет магия. Потому что чтобы полноценно объяснить как повесить листнер, который будет отслеживать нажатия кнопки, для этого нужно как минимум объяснить интерфейсы и анонимные классы, а это мягко говоря не на пять минут. Так вот, давайте определимся, что это магия и это надо просто запомнить. 
+***** Итак, как повесить листнер
+	  и заставить нашу кнопку реагировать на нажатия? Давайте опишем кнопку выхода, она попроще, у кнопок есть такой метод как addActionListener() и ему на вход нужно передать переменную типа экшнЛистнер. Которая требует на вход интерфейсы, а их мы на J1 не проходим, поэтому просто запомните конструкцию, пожалуйста, и не забивайте себе пока что голову. пишем в метод new ActionListener, жмём энтер и среда сама вставляет вам вот такой страшный шаблон, в который надо писать что должно происходить при нажатии на кнопку. Здесь мы будем пользоваться методом exit класса System, которому передадим стандартное для корректного завершения программы число 0. Систем.Экзит полностью грохнет нашу программу и освободит от неё все ресурсы, так что это самый простой и гарантированный способ убить процес. Что называется, топором. Так вот создание обработчиков - это единственная магия, которая есть на J1. Если разобраться в ситуации - то мы создаём экземпляр анонимного класса, который реализует интерфейс. Вот оно вам сейчас надо, в подробностях? по моему для первого уровня сложновато. 
+	  Кнопка newGame оживляется таким же образом. пишем новый листнер, и внутри мы делаем ни что иное, как показываем наше моднное второе окошко с настройками новой игры. startNewGameWindow.setVisible(true); тут то нам и пригодится то, что закрытие окна не убивает программу, а уходит в невидимость
+	  вот на этом таки создание нашего класса основного окна заканчивается.
+***** Давайте пилить стартовое окно. 
+	  Объявим константы, заботливо подобранные заранее, ширина окна 350 высота 230, минимальная выигрышная длина 3, минимальный размер поля 3, и максимальные размеры 10, 10. эти значения нам нужны будут для создания слайдеров. И давайте сразу объявим переменную типа GameWindow gameWindow, и зададим ей значение из конструктора. this.gameWindow = gameWindow. установим ширину и длину. Теперь давайте, чтобы сделать красиво и ровно посередине, воспользуемся ещё одним новым на сегодня классом, Rectangle, который представляет собой абстрактный прямоугольник. назовём его gameWindowBounds и создадим, = gameWindow.getBounds(), сразу передав в него значения границ нашего окна. у окон есть и такой метод, getBounds(), да. В общем это просто удобный класс для работы с прямоугольниками, то есть с окнами например. И теперь делаем немного математики, задаём переменную 
+	  int pos_x = (int)gameWindowBounds.getCenterX() - WIN_WIDTH / 2;
+	  int pos_y = (int)gameWindowBounds.getCenterY() - WIN_HEIGHT / 2;
+	  setLocation(pos_x, pos_y);
+	  setResizeable(false);
+  setBorder(new EmptyBorder(3, 3, 6, 3));
+	  Сделаем заголовок, СОЗДАНИЕ НОВОЙ ИГРЫ. расположение сделаем сеткой setLayout(new GridLayout(10, 1)); Дальше нам надо добавить сюда много-много разных управляшек, и эти однотипные по сути действия мы для удобства вынесем в отдельный метод void addGameControlsMode(){}; 
+	  Для начала добавим надпись, для этого существует класс JLabel, пишем add(new JLabel(“Choose gaming mode”)); в конструктор можем передать собственно надпись, а можем ничего не передавать и задать её потом, но для этого надо будет поместить надпись в какой-то именованный контейнер, для нас сейчас это, понятно, лишнее. 
+	  Дальше нужны будут две радиокнопки, которые пригодятся не только в этом методе, поэтому объявление вынесем вверх, а присваивание значений сделаем в нашем методе, который всё добавляет. выносим 
+	  private JRadioButton humVSAI; 
+	  private JRadioButton humVShum;
+	  и присвоим humVSAI = new JRadioButton(“Play VS Computer”); с надписью переданной в конструктор, и вторую также. добавим на наше окно и увидим что всё неправильно работает. add(hva); add(hvh); 
+	  Чтобы всё заработало как мы ожидаем есть класс который связывает радиобатоны в группы, что видно из его названия ButtonGroup gameMode = newBG(); gmode.add(hvm); gmode.add(hvh); и саму радиогруппу никуда класть не надо, она просто объединит. и чтобы одна из них была выбрана по умолчанию, используем перегруженный конструктор радио кнопки, (“play vs comp”, true); 
+***** Слайдеры 
+	  пишем следующий метод addGameControlsFieldWinLen(){} в котором будем описывать наши слайдеры, то есть понятно, что это всё ещё конструктор, просто мы делаем его чисто внешне менее жирным. Ну и чтобы логически разграничить, потому что код уже получается достаточно непростой. 
+	  Напишем некий подзаголовок  add(new JLabel(“Выбери длину”)); и пишем новенький лейбл на котором будем писать выигрышную длину 
+	  JLabel lbl_win_len = new JLabel(“WIN_LEN” + WIN_LEN)); 
+	  add(lbl_win_len); этот видите мы создаём в два действия, потому что цифру на нём мы будем менять, а не задавать из программы. Давайте объявим слайдеры где-то рядом с JRadioButton'ами. 
+	  private JSlider sField_size; 
+	  JSlider sWin_len; и в методе также создадим. в конструкторе слайдеру можно передать три значения, мин, макс и текущее пишем 
+	  sWin_len = new Slider(MIN_WIN,  MIN_FIELD, MIN_WIN); 
+	  на слайдер мы тоже вешаем слушателя изменений, только тут он называется ChangeListener пишем sWin_len.addChangeListener(new ChangeListener)); и в нём делаем изменение текста для нашего лейбла лбл_вин_лен.сетТекст(“WIN_LEN” + sWin_len.getValue); 
+	  и добавим его на окно после лейбла. add(sWin_len); дальше создаём такой-же лейбл с размерами поля и аналогично ставим ему текст, добавим на окно. Теперь поинтереснее, создаём слайдер для поля, тоже аналогично, пишем чендж листнер и начинаем прикалываться, введём ещё одну переменную, current_field_size = sField_size.getValue() и будем использовать его в двух местах, во первых нам надо значения на лейбле менять, а во вторых, максимальное значение выигрышной длины тоже менять. лейбл.сетТекст(ФИЛД + каррент); и сВинЛен.сетМаксимум(каррент); и давайте аккуратно по порядку добавим слайдеры и надписи. Вот теперь вы никак не сможете ошибиться и сделать выигрышную длину больше чем размер поля.
+***** И осталась нам только кнопочка “начать игру” 
+	  в конце конструктора пишем JButton btnStartGame = new JButton(“New Game”); add(btnSG); вот у нас и получился один столбец и десять строчек. Осталось только оживить кнопочку, для этого напишем последний на сегодня метод назову его btnStart_onClick(), 
+	  в кнопке пишем btnSG.addActionListener(new ActionListener()); и внутри любезно предоставленного шаблона просто вызовем наш метод, чтобы много не писать. А обработчик очень интересный, в нём нам надо вызвать метод startNewGame из основного окошка, но чтобы сделать это нам надо наполнить сигнатуру разными параметрами, которые мы возьмём с наших управляшек. 
+	  Давайте в классе Map объявим пару констант, раз мы не изучали с вами перечисления. GAME_MODE_H_V_A = 0, GAME_MODE_H_V_H = 1; и в классе в котором работаем создадим новую переменную инт game_mode; 
+	  пишем if(rb_hva.isSelected()) значит если кнопка выделена - game_mode = Map.HVA иначе rb_hvh.isSelected() game_mode = Map.HVH; ну и совсем иначе генерим исключение. мало-ли мы через пол года захотим ещё режимов надобавлять, батон добавим, а сюда забудем дописать, или пользователю не отобразится радиобатон, throw new RuntimeException(“No Buttons Selected”); и программа нам подскажет где искать. 
+	  также с размером поля, которое пока что у нас будет квадратным, хоть мы и архитектурно заложили, что оно может быть не квадратным. эти показания мы просто снимем со слайдеров и передадим в конструктор slider.getValue(); ну и перед тем как закончить обработчик нам надо наше окошко спрятать от глаз пользователя до следующего раза, setVisible(false);
+	  ну вот мы выполнили план на сегодня, хоть мы и немного отошли от методички, но мы сделали хороший задел для нашего последнего занятия, нам там надо будет только написать логику, и расчертить полянку
+***** Домашняя работа
+  1. Полностью разобраться с кодом (попробовать полностью самостоятельно переписать одно из окон)
+  2. Составить список вопросов и приложить в виде комментария к домашней работе
+  3. * Раcчертить панель Map на поле для игры, согласно fieldSize
+
+  
+***** К сложному и интересному: 
+	  метод paintComponent() вызывается фреймворком когда что-то происходит, например, когда мы перекрываем наше окно каким-то другим, или двигаем само окно, но в любом случае вызывается он гораздо реже, чем нам нужно. Но важно помнить, что мы не должны непосредственно этот метод вызывать из кода. этот метод должен вызываться только фреймворком, но сейчас нам важно не это, сейчас нам важно отделить этот метод от собственно нашего рендеринга. давайте создадим ещё один метод void render(Graphics g) и будем его вызывать из нашего paintComponent(); 
+	  Итак чтобы нарисовать сеточку нам понадобится ширина и высота нашего поля в пикселях, как это сделать: у панельки есть свойства ширина и высота, ими и воспользуемся, создав две дополнительные переменные int panelWidth = getWidth(); int panelHeight = getHeight(); можем вывести в консоль для отладочных нужд, и заодно посмотреть сколько раз и когда вызовется метод перерисовки sout(w, h);
+	  помимо этого нам понадобятся переменные, в которых мы будем хранить высоту и ширину каждой ячейки. размеры каждой ячейки нам пригодятся, так что заведём две классовые переменные cellW, cellH = panelW/fsx, panelH/fsy; и в методе который рендерит разлинуем. идём циклом от 0 до <= fieldSizeY и рисуем горизонтальные линии, пишем int y = i * cellH; g.drawLine(0, y, panelWidth, y); и у многих сейчас не полностью нарисовалось, это происходит потому, что перерисовалась только часть компонента, так уж устроена отрисовка в свинге, чтобы не жрать много ресурсов. мы должны заставить наш компонент полностью перерисоваться. сделаем это вызвав метод repaint(); из метода startNewGame; то есть в методе СНГ мы все переменные инициализировали и попросили панель перерисоваться после этого. 
+	  Опять же если копнуть немного вглубь, мы сказали фреймворку что надо перерисоваться, он поставил метод пэйнтКомпонент куда-то в очередь сообщений окна, и когда очередь дошла - выполнил его. то есть это действует асинхронно и не напрямую. Отвлеклись, продолжим. отрисуем вертикальные линии fori(<=fsX){int x=i*cellW; g.drawLine(x, 0, x,  panelHeight)}.
+***** Теперь давайте сделаем ещё одну магию, 
+	  добавим слушателя на мышку, в конструкторе пишем addMouseListener(new MouseAdapter() {}) нам понадобится заоверрайдить метод mouseReleased(), то есть нам важно когда пользователь отпустит кнопку (метод touchUp()) и снова чтобы не заполнять конструктор огромным количеством кода, создадим отдельный метод update(MouseEvent e) и вызовем его из обработчика мышки. и тут мы тоже принудительно вызовем репэйнт, вот собственно и получается наш игровой цикл, клик мыши, отрисовка, клик-отрисовка. 
+	  На самом деле это делается ещё и для того чтобы мы нашу логику могли портировать куда-то ещё. не обязательно же мышка должна вызывать у нас изменения игрового поля, а например тап по тачскрину. Теперь мы в нашем методе update из класса MouseEvent вытаскиваем координаты клика, делим на размер ячейки и тем самым получаем номер ячейки, в которую мы кликнули. пишем: int cellX = e.getX/cellW; int cellY = e.getY/cellH. для верности можем их sout чтобы посмотреть как это работает и работает-ли.
+***** берём наш код от крестиков-ноликов с третьего занятия
+	  свой я вам выкладывал, так что если не готовы воспользоваться своим - возьмите мой. и копипастим его от мэйна до метода humanTurn(). всё, где логика и нет работы с консолью. вот вам пример необходимости писать методы, которые ничего лишнего не выводят. код не переписываем, а приложение уже совсем другое. Ну и видим, что нам не хватает кое каких констант. объявим private static final int EMPTY_DOT = 0, HUMAN_DOT = 1, AI_DOT = 2; убираем статики из методов, и чиним наш проект дальше. 
+	  В методе checkLine меняем чары на инты, для того чтобы переименовать все переменные в данной области видимости надо навести на неё курсор и нажать шифт-ф6. переименуем на dot.
+	  в checkWin() делаем точно также.
+	  для aiTurn() после того как убрали статик видим, что не хватает только рандомайзера, создадим классовую переменную pr fin Random random = new R();
+	  статики мы тогда создавали потому что не знали ООП, и не создавали объекты, и не знали, кто такие поля объектов. Напомню, что в статические методы нельзя передавать ссылки на объекты, и из статических методов можно обращаться только к статическим переменным и методам.
+***** Ну что, нашли мы кликнутую ячейку, давайте в неё ходить, 
+	  только нам для начала надо проверить, валидная-ли ячейка, и можно-ли туда ходить, вот и проверим: (!isValid(cellX, cellY) || !isEmptyCell(cellX, cellY)) return; игнорим клик, выходим из метода
+	  ну а если всё хорошо - просто ходим филд[селХ][селУ] = hum_dot;
+	  И добавить в наш метод отрисовки ещё немного логики. сделаем двойной массив по всем ячейкам нашего поля фори(филдСайзУ) фори(филдСайзХ) и внутри пишем 
+	  if(isEmptyCell(ж, и)) continue; то есть если ячейка пустая - просто идём дальше, ничего не делаем, дальше пишем маленькую заготовку:
+	  if(field[i][j] == H_D) {} else if (field[i][j] == A_D) {} else throw new RTE (не пойму что в ячейке + и,ж) мало ли что мы там перекодили и допилили, может решили сделать баттл для трёх игроков?
+	  И теперь пришли к отрисовке. хотите, можете сюда картинку вставлять, хотите закрашенные квадратики, хотите рисуйте крестики-нолики, я для простоты буду пользоваться методом g.fillOval() и буду рисовать кружки. ему в сигнатуре передаётся левая верхняя координата прямоугольника, в который потом будет вписан овал, и его ширина и высота соответственно. тем, кто хоть раз рисовал в пэинте - знакома эта техника рисования кружков. ну и чтобы придать ему цвета - перед тем как рисовать изменим цвет объекта graphics, g.setColor(Color.BLUE); или задать интами от 0 до 255 в формате РГБ new Color(RGB); 
+	  Итак я предлагаю для человека рисовать синие кружки, а для компа красные. и после проверки собственно его рисовать, в проверках пишем setColor(); а после проверок пишем g.fillOval(j*CellW, i*CellH, CW, CH); и чтобы сделать небольшой отступ сделаем следующее, заведём классовую константу DOTS_PAGGING = 5 пикселя. и первые координаты смещаем на + пэддинга вторые на - 2 пэддинга.
+	  Так посимпатичнее. 
+***** Давайте завязывать с этим безумием
+	  объявим константы которые будут содержать исходы игры, псфи DRAW = 0; HUM_WIN = 1; AI_WIN = 2; и нужна переменная stateGameOver в которой будет храниться статус. 
+	  Значит теперь в методе апдейт мы поставили точку, перерисовали и жедаем по старому сценарию 
+	  if(checkWin(H_D)) stGO = H_W; return; 
+	  if (isMapFull()) stGO = DR; return; 
+	  aiTurn(); 
+	  repaint();
+	  if(checkWin(A_D)) stGO = A_W; return; 
+	  if (isMapFull()) stGO = DR;
+***** дальше в принципе нам только и надо что нарисовать все красотульки. 
+	  значит идём в метод рендер и думаем там. как только мы вывели поле, и если игра закончилась нам надо вывести сообщение с одним из вариантов исхода. так и запишем if (gameOver) showOverMessage(g); вот просто перевели наши слова на английский. теперь смотрим, чего у нас для этого не хватает в коде, как минимум метода showOverMessage() и переменной признака конца игры. да не вопрос, мыжпрограммисты, напишем войд sOW(Graphics g), private boolean gameOver. и поехали наполнять эти штуки смыслом: 
+	  в методе начала новой игры нам, очевидно, надо сказать что геймовер = фолс. и закончим на этом метод СНГ. 
+	  идём в метод апдейт и в самом начале пишем, что if(gameover) return; очевидно, что если геймовер случился - надо игнорировать вообще все клики. ну а если кто-то выиграл или ничья - геймовер также становится тру. и на этом закончим с методом апдейт и останется только дописать собственно метод показывающий, что у нас закончилась игра. 
+	  Ну и для того чтобы нарисовать в классе графики какой-то текст есть метод g.drawString() с выводимой строкой и координатами по х и по у, внимание, координата по у это координата нижней части букв, как строчка в тетради. Ну и для того чтобы этот текст кастомизировать да и вообще для работы со шрифтами есть класс не поверите Font. создадим классовый private final Font который назовём не поверите font = new Font( и на вход конструктор внезапно принимает название шрифта, стиль и размер “Times new roman”, Font.BOLD, 48); 
+	  будьте осторожны при работе с такими неочевидными классами. и теперь наш метод с отрисовкой строки немного дополняем, setColor(); setFont(font). вот так он и выводится. Давайте создадим классовые константы, в которых будем хранить наши сообщения о победах. psfS MSG_DRAW= “DRAW”; MSG_HW; MSG_AW;
+***** в showGameOver 
+	  пишем свич (стейтГеймОвер) и кейсы ДРО, Х_В, А_В. дефолт throw new RTE(unexpected GO message);
+	  теперь если дро, g.drawString(MSG_DRAW, 180, getHeight/2);
+	  если H_W, g.drawString(HW, 70, gH/2);
+	  если A_W (20);
+	  и перед ним пишем setColor(YELLOW) setFont(font); 
+	  ну и чтобы было виднее, я предлагаю рисовать тёмно серый прямоугольник в качестве фона работает он также как fillOval только рисует прямоугольник пишем fillRect(0, 200, getWidth, 70); естественно надо все магические цифры либо вывести в константы, либо как-то динамически считать). и БУМ! всё классно, мы закончили.
+
+
+**** 3: Крестики-нолики
+***** public class TicTacToe {
+      private static final char HUMAN_DOT = 'X';
+      private static final char AI_DOT = 'O';
+      private static final char EMPTY_DOT = '.';
+      private static final Scanner SCANNER = new Scanner(System.in);
+      private static final Random RANDOM = new Random();
+      private static int fieldSizeY;
+      private static int fieldSizeX;
+      private static char[][] field;
+***** Инициализация игрового поля
+      private static void initMap() {
+          fieldSizeY = 3;
+          fieldSizeX = 3;
+          field = new char[fieldSizeY][fieldSizeX];
+          for (int i = 0; i < fieldSizeY; i++) {
+              for (int j = 0; j < fieldSizeX; j++) {
+                  field[i][j] = EMPTY_DOT;
+              }
+          }
+      }
+***** Вывели поле с любыми украшениями вокруг него
+      private static void printMap() {
+          System.out.print("+");
+          for (int i = 0; i < fieldSizeX * 2 + 1; i++)
+              System.out.print((i % 2 == 0) ? "-" : i / 2 + 1);
+          System.out.println();
+	
+          for (int i = 0; i < fieldSizeY; i++) {
+              System.out.print(i + 1 + "|");
+              for (int j = 0; j < fieldSizeX; j++)
+                  System.out.print(field[i][j] + "|");
+              System.out.println();
+          }
+	
+          for (int i = 0; i <= fieldSizeX * 2 + 1; i++)
+              System.out.print("-");
+          System.out.println();
+      }
+***** Ход игрока
+      private static void humanTurn() {
+          int x, y;
+          do {
+              System.out.print("Введите координаты X и Y через пробел>> ");
+              x = SCANNER.nextInt() - 1;
+              y = SCANNER.nextInt() - 1;
+          } while (!isValidCell(x, y) || !isEmptyCell(x, y));
+          field[y][x] = HUMAN_DOT;
+      }
+***** ячейка-то вообще правильная?
+      private static boolean isValidCell(int x, int y) { return x >= 0 && x < fieldSizeX && y >= 0 && y < fieldSizeY; }
+***** а пустая?
+      private static boolean isEmptyCell(int x, int y) { return field[y][x] == EMPTY_DOT; }
+***** Ход компьютера
+      private static void aiTurn() {
+          int x, y;
+          do {
+              x = RANDOM.nextInt(fieldSizeX);
+              y = RANDOM.nextInt(fieldSizeY);
+          } while (!isEmptyCell(x, y));
+          field[y][x] = AI_DOT;
+      }
+***** проверка на победу
+      private static boolean checkWin(char c) {
+	      if (field[0][0]==c && field[0][1]==c && field[0][2]==c) return true;
+	      if (field[1][0]==c && field[1][1]==c && field[1][2]==c) return true;
+	      if (field[2][0]==c && field[2][1]==c && field[2][2]==c) return true;
+		  //.......
+	  }
+***** ничья?
+      private static boolean isMapFull() {
+          for (int i = 0; i < fieldSizeY; i++) {
+              for (int j = 0; j < fieldSizeX; j++) {
+                  if (field[i][j] == EMPTY_DOT) return false;
+              }
+          }
+          return true;
+      }
+***** Игровой цикл
+	  public static void main(String[] args) {
+          initMap(7, 5, 4);
+          printMap();
+          while (true) {
+              humanTurn();
+              printMap();
+              if (checkWin(HUMAN_DOT)) {
+                  System.out.println("Выиграл игрок!!!");
+				  break;
+			  }
+			  if (isMapFull()) {
+			      System.out.println("Ничья!!!");
+				  break;
+			  }
+			  aiTurn();
+			  printMap();
+			  if (checkWin(AI_DOT)) {
+			      System.out.println("Выиграл компьютер!!!");
+				  break;
+			  }
+			  if (isMapFull()) {
+			      System.out.println("Ничья!!!");
+				  break;
+			  }
+		  }
+		  SCANNER.close();
+	  }
+***** Домашнее задание
+  1. Полностью разобраться с кодом;
+  2. Переделать проверку победы, чтобы она не была реализована просто набором условий.
+  3. * Попробовать переписать логику проверки победы, чтобы она работала для поля 5х5 и количества фишек 4.
+  4. *** Доработать искусственный интеллект, чтобы он мог блокировать ходы игрока, и пытаться выиграть сам.

scenarios/jtd2-07b.tex

@@ -11,109 +11,64 @@
 
 Отбивка & и сегодня на повестке дня у нас интерфейсы, но не те интерфейсы, что графические, а те, что программные. \\ \hline
 
-На прошлом уроке & На прошлом уроке мы поговорили как раз о графических интерфейсах пользователя. создали немного окон, разместили немного компонентов, порисовали. Поговорили о графических интерфейсах через призму создания и взаимодействия объектов, нарисовали пару-тройку диаграмм, чтобы лучше запомнить, что как и с чем связывается, кто кого вызывает и зачем. \\ \hline
+На прошлом уроке & На прошлом уроке мы поговорили о файловых системах и представлении данных в запоминающих устройствах; Поверхностно посмотрели на популярные пакеты ввода-вывода. Подробно разобрали один из самых популярных ссылочных типов данных String и разные механики вокруг него, такие как стрингбилдер и стрингпул. \\ \hline
 
 На этом уроке & Поговорим об интерфейсах, рассмотрим понятие и принцип работы, поговорим о ключевом слове implements; Наследование и множественное наследование интерфейсов, реализация, значения по умолчанию и частичная реализация интерфейсов. Естественно, что говоря об интерфейсах нельзя не сказать о функциональных интерфейсах и анонимных классах. Коротко рассмотрим модификаторы доступа при использовании интерфейсов и немного подробнее поговорим о глубинных процессах, таких как раннее и позднее связывание в объектно-ориентированном программировании.  \\ \hline
 
 06-01 & Разговор об интерфейсах хотелось бы построить не так, как мы это делали на лекциях обычно, а от некоторой практической составляющей, чтобы где-то в середине лекции у вас сложилось явное впечатление, что что-то тут явно можно улучшить, а когда мы применим интерфейсы, вы подумали «ааааа так вот зачем оно нужно и как применяется», а потом уже поговорим о теоретической составляющей и особенностях. \\ \hline
 
+Отбивка & Приложение для примера \\ \hline
+
 06-02 & Итак начнём с преамбулы, здесь я призываю вас не особенно обращать внимание на то, какие именно классы и методы используются, а внимательно следить за взаимодействием и отношениями объектов, потому что интерфейсы, о которых мы сегодня планируем поговорить - это как раз механизм упрощающий и универсализирующий взаимодействия объектов. Код может показаться непростым, но зато задачу мы поставим таким образом, что если делать нормально, то без интерфейсов не обойтись, и когда мы закончим - у вас, как я только что и сказал, должно появиться ощущение что «о, так вот зачем они нужны». Почему будет сложно? потому что несмотря на то что вы уже знаете принципы ооп - надо уметь их применять.\\ \hline
  
-06-03 & Итак, что мы будем делать? мы сделаем некий небольшой набросок своего собственного игрового 2д движка, без физики и прочего, а просто с объектами и анимацией, чисто демонстрационный. На его основе можно что угодно запилить, и будет отлично работать. На слайде вы видите окно, кружки летают (имейте ввиду, они перемещаются плавно, если у кого-то что-то дёргается, это интернет с низким ФПС передаёт, а не приложение). пока что ничего тут не обрабатывается, ничего толком не происходит. Итак, самое главное, что нам понадобится, это окно, которое будет как-то взаимодействовать с операционной системой, на окне будет канва, на которой мы будем всё рисовать, и собственно объекты, которые мы будем рисовать. \\ \hline
+06-03 & Итак, что мы будем делать? мы сделаем некий небольшой набросок своего собственного игрового 2д движка, без физики и прочего, а просто с объектами и анимацией, чисто демонстрационный. на его основе можно что угодно запилить, и будет отлично работать. На слайде вы видите окно, кружки летают (имейте ввиду, они перемещаются плавно, если у кого-то что-то дёргается, это интернет с низким ФПС передаёт, а не приложение). пока что ничего тут не обрабатывается, ничего толком не происходит. Итак, самое главное, что нам понадобится, это окно, которое будет как-то взаимодействовать с операционной системой, на окне будет канва, на которой мы будем всё рисовать, и собственно объекты, которые мы будем рисовать. \\ \hline
  
-06-04 & Быстро создаём окно, буквально константы с размерами, координатами, и конструктор окна прямо здесь же вместе с методом мейн, не вдаваясь в подробности того, как работает фреймворк свинг на котором мы всё это пишем, на эту тему у нас был отдельный урок, на котором уже закрепили информацию об ООП. Самое важное для нас сейчас - это то, что окно - это объект с какими-то свойствами и каким-то поведением. Если коротко, стартуем программу, создаём объект окна, говорим, что окно с каким-то заголовком, какого-то размера и находится по каким-то координатам, а когда мы нажмём на крестик, то закрыть нужно будет не только окно, но и программу целиком. \\ \hline
+06-04 & Быстро создаём окно, буквально константы с размерами, координатами, и конструктор окна прямо здесь же вместе с методом мейн, не вдаваясь в подробности того, как работает фреймворк свинг на котором мы всё это пишем, на эту тему у нас будет отдельный урок, на котором мы закрепим информацию об ООП, многопоточности и отлову исключений в графических интерфейсах. Самое важное для нас сейчас - это то, что окно - это объект с какими-то свойствами и каким-то поведением. Если коротко, стартуем программу, создаём объект окна, говорим, что окно с каким-то заголовком, какого-то размера и находится по каким-то координатам, а когда мы нажмём на крестик, то закрыть нужно будет не только окно, но и программу целиком. \\ \hline
 
-06-05 & Припоминаем, что есть такой компонент JPanel, с ним можно много что делать но самое интересное, что можно на нём рисовать. Итак создали наследника Jpanel с названием MainCanvas. Что умеет любой компонент в свинге? правильно, он умеет перерисовываться, посредством вызова метода paintComponent. Применяем полиморфизм. Из документации мы знаем, что метод пэинтКомпонент вызывается тогда, когда фреймворку надо перерисовать панельку. Мы этот метод переопределим и напишем свою собственную реализацию перерисовки. Давайте сделаем так: создадим конструктор панельки, и будем в конструкторе делать что то незначительное, например, менять цвет фона на синий. Заоверрайдили пэинтКомпонент и тут-же вызвали родительский метод. То есть по сути мы говорим, что нас вполне устраивает то, как перерисовывается панелька, но мы потом захотим туда что-то добавить. Ну и добавим четыре метода, возвращающие границы нашей канвы, левую, правую, верхнюю, нижнюю, для удобства дальнейшего взаимодействия с получившейся канвой.\\ \hline
+06-05 & Итак есть такой компонент JPanel, с ним можно много что делать но самое интересное, что можно на нём рисовать. Итак создали наследника Jpanel с названием GameCanvas. Что умеет любой компонент в свинге? он умеет перерисовываться, посредством вызова метода paintComponent. Применим полиморфизм. Из документации мы знаем, что метод пэинтКомпонент вызывается тогда, когда фреймворку надо перерисовать панельку. Мы этот метод переопределим и напишем свою собственную реализацию перерисовки. Давайте сделаем так: создадим конструктор этой пенльки, и будем в конструкторе делать что то незначительное, например, менять цвет фона на синий. Заоверрайдили пэинтКомпонент и тут-же вызвали родительский метод. То есть по сути мы говорим, что нас вполне устраивает то, как перерисовывается панелька, но мы потом захотим туда что-то добавить. Ну и добавим четыре метода, возвращающие границы нашей канвы, левую, правую, верхнюю, нижнюю.\\ \hline
 
-06-06 & Наладим взаимодействие компонентов и привяжем все действия нашего игрушечного движка ко времени физического мира. В основном окошке, в конструкторе, создали переменную класса MainCanvas и расположили её на окне прям в центре, пусть на окне будет только она. Пока что всё понятно и хорошо. Всё работает. В принципе можно начать писать логику игры прям здесь, в классе канвы, но это архитектурно не очень хорошо, ведь это же канва на которой мы рисуем, значит здесь мы должны по логике только рисованием заниматься. Давайте примем архитектурное решение писать логику игры в нашем классе с кружками, а MainCanvas будет универсальным, чтобы иметь возможность в дальнейшем рисовать вообще всё что угодно. Для этого описали в нашем основном окошке метод, назвали его как-нибудь нормально onDrawFrame и в нём будем описывать реализацию цикла для нашего модного приложения, то есть так называемую бизнес-логику. На данный момент это будут два метода - апдейт который будет как то изменять состояние нашего приложения, и рендер, который будет отдавать команды всяким рисующим компонентам. То есть получается, что канва время от времени будет говорить, что она нарисовалась, а основное окно по этому событию будет что-то умное предпринимать \\ \hline
+06-06 & Наладим взаимодействие компонентов и привяжем все действия нашего игрушечного движка ко времени физического мира. В нашем основном окошке, в конструкторе, создали переменную класса GameCanvas и расположили её на окне прям в центре. Пока что всё понятно и хорошо. Всё работает. В принципе можно начать писать логику игры прям здесь, в классе панельки, но это архитектурно не очень хорошо, ведь это же канва на которой мы рисуем, значит здесь мы должны по логике только рисованием заниматься. Давайте примем архитектурное решение писать логику игры в нашем классе с кружками, а GameCanvas будет универсальным, чтобы рисовать вообще всё что угодно. Для этого описали в нашем основном окошке метод, назвали его как-нибудь нормально onDrawFrame и в нём будем описывать реализацию цикла для нашего модного приложения, то есть так называемую бизнес-логику. На данный момент это будут два метода - апдейт который будет как то изменять состояние нашего приложения, и рендер, который будет отдавать команды всяким рисующим компонентам. \\ \hline
 
-06-07 & Теперь надо чтобы при перерисовке наш с вами MainCanvas этот метод дёргал, и тем самым изображение как-то менялось. Для этого канве надо знать как минимум чей метод она будет дёргать, то есть ей нужно знать на каком окне она находится. создаём в классе канвы локальную переменную, которая умеет хранить объекты класса MainWindow и передадим значение этой переменной в конструкторе. А в пэинтКомпоненте будем вызывать нужный метод controller.onDrawFrame();
-%% 2
+06-07 & Теперь нам надо чтобы при перерисовке наш с вами GameCanvas этот метод дёргал, и тем самым изображение как-то менялось. Для этого нашей канве надо знать как минимум чей метод она будет дёргать, то есть ей нужно знать на каком окне она находится. создаём в классе канвы локальную переменную, которая умеет хранить объекты класса MainCircles и передадим значение этой переменной в конструкторе. И в пэинтКомпоненте будем вызывать controller.onDrawFrame(); Далее, чтобы зациклить это действие мы можем пойти несколькими путями: самый простой - создать постоянно обновляющуюся канву, то есть в методе пэинтКомпонент взять и написать repaint() но это вариант прямо скажем "так себе", он полностью нагрузит одно из ядер процессора только отрисовкой окна - не самое лучшее применение одного из ядер. Второй путь - это применение магии из занятия по потокам. мы можем заставить наш поток какое-то время поспать, начиная с 20-й строки вы видите некоторую конструкцию, смысл которой вам будет понятен немного позже Thread.sleep(16); это даст нам фпс близкий к 60, приемлемо для условной игры, не надо ни больше ни меньше, пожалуй. Получится, что мы отрисовали компонент, посчитали что там изменится апдейтом, отправили обратно на отрисовку рендером, отрисовали пэинтКомпонентом.\\ \hline
 
-Далее, чтобы зациклить это действие мы можем пойти несколькими путями: самый простой - создать постоянно обновляющуюся канву, то есть в методе пэинтКомпонент взять и написать repaint() но это вариант прямо скажем "так себе", он полностью нагрузит одно из ядер процессора только отрисовкой окна - не самое лучшее применение одного из ядер.
-%% 3
+06-08 & Довольно интересно, кстати, как при этом изменился код, вызывающий конструктор канвы, ведь мы из основного класса с окном теперь как-то должны в канву передать это самое основное окно, как вы могли догадаться, для этой цели мы применяем указатель на текущий объект класса this, то есть в конструкторе основного окна мы передали ссылку на экземпляр этого окна канве. немного ломает привычное использование для обращения к полям в конструкторе, но, поверьте, то ли ещё будет. Предлагаю запомнить такой способ применения ключевого слова this, он нам сегодня ещё пригодится. \\ \hline
 
-Второй путь - это применение магии из занятия по потокам. мы можем заставить наш поток какое-то время поспать, поэтому мы вызываем статический метод класса Трэд, он называется слип и принимает на вход количество миллисекунд, которое поток должен обязательно поспать. это даст нам фпс близкий к 60, приемлемо для условной игры, не надо ни больше ни меньше, пожалуй.
-%% 4
+06-09 & Закончим с отрисовкой и методом onDrawFrame. Он будет обновлять сцену и рендерить её. Для обновления сцены было бы очень неплохо знать дельту времени, которая прошла с предыдущего кадра, чтобы обновлять физику. Конечно можно писать физику, опираясь на частоту кадра, или на то что мы там спим 16миллисекунд, но это всё очень сомнительная опора, потому что мы гарантированно спим 16миллисекунд, но сколько именно мы будем спать неизвестно, потому что отрисовка происходит не через фиксированные промежутки времени и ещё куча факторов. Лучше всего точно знать сколько времени прошло с предыдущего кадра. поэтому сделаем так чтобы метод onDrawFrame эту самую дельту у канвы получал и отдавал методу обновления. Соответственно считаем дельту в канве. Вот, собственно и вся физика, которая нам понадобится. Теперь посмотрим вот на что - у нас в пэинтКомпонент прилетает объект класса графикс, который отвечает, как это ни удивительно, за графику, то есть за рисование. Это же то, что нам нужно. Давайте этот самый объект отдадим нашему методу onDrawFrame, пусть он что-нибудь рисует. а где рисует? на канве, значит нам надо будет как минимум знать её размеры. какой канвы размеры получаем? нашей, той самой. себя и отдадим. onDrawFrame будет распределять - апдейту отдаст дельту и канву, а рендеру - канву и графику. Для универсальности. Все изменения канвы вы видите на слайде, все изменения основного окна ему соответствуют, изменена сигнатура метода онДроФрейм, на неё мы посмотрим через несколько секунд. Пока самое главное, что нам нужно понять об этих двух объектах - канва считает для нас время и постоянно перерисовывает себя, сообщая об этом факте основному окну, а основное окно на этот факт как-то реагирует. Ну и ООП вокруг этого тоже было бы хорошо понимать, объекты передают ссылки друг на друга и вызывают друг у друга всякие интересные методы. \\ \hline
 
-Получится, что мы создали внутри этого метода некий бесконечный цикл отрисовки, своеобразный ду-вайл, который сам себя заставляет крутиться дальше с некоторой периодичностью и на каждой своей итерации сообщает контроллеру, что прошло около одной шестидесятой секунды. \\ \hline
+06-10 & Давайте попробуем что нибудь нарисовать при помощи нашего с вами игрового цикла, например прямую белую линию. Видим, что отлично получается, теперь мы умеем рисовать и наша канва умеет это отображать. Отлично. Наше приложение будет рисовать какие-то объекты, будут это кружки, квадратики, картинки, человечки или какие-то другие объекты - не важно. Важно, чтобы у программы было описан механизм и поведение этих объектов. Это как раз то, о чём я говорил и говорю - применение архитектуры, применение ООП. Мало просто посмотреть уроки, почитать книжки, посидеть на семинаре. Надо сидеть и думать в рамках парадигмы ООП. Это ещё простенькая архитектура. Я понимаю вас, вы смотрите сейчас, и вроде всё понятно, а сами в жизни бы такое не написали. Я сам несколько лет назад такое в жизни не написал бы, так что не переживайте, всё придёт с опытом. Главное, не путайте понятия уметь программировать и знать язык программирования. В какой-то момент вы поймаете себя на мысли, что вы не думаете о циклах и условиях, а думаете на следующем уровне абстракции, думаете о взаимосвязях, об архитектуре, а пальцы сами набирают какие-то языковые конструкции. \\ \hline
 
-06-08 & Довольно интересно, кстати, как при этом изменился код, вызывающий конструктор канвы, ведь мы из основного класса с окном теперь как-то должны в канву передать это самое основное окно, как вы могли догадаться, для этой цели мы применяем указатель на текущий объект класса this, то есть в конструкторе основного окна мы передали ссылку на экземпляр этого окна канве. немного ломает привычное использование для обращения к полям в конструкторе, но, поверьте, то ли ещё будет. Предлагаю запомнить такой способ применения ключевого слова this, он нам сегодня ещё пригодится. Ещё раз: создавая экземпляр основного окна мы передаём ссылку на этот создаваемый экземпляр канве, чтобы она знала, у какого окна дёргать метод обновления. \\ \hline
+06-11 & Соответственно, рисовать просто линии круги и прочее - довольно скучно, поэтому будем рисовать объекты, Создадим класс Спрайт. Ни от чего наследоваться не будем. Просто опишем общее для всех рисуемых объектов в нашей программе поведение. Что может быть у всех объектов в приложении общего? размеры, местоположение. Обычно, когда вы начинаете изучать какой-то графический фреймворк вы замечаете, что начало координат у этого фреймворка находится в верхнем левом или нижнем левом углу. Однако очень часто, когда пишутся какие-то игры или другие приложения с использованием графики в качестве координат используется центр объекта. То есть надо условиться - что х и у - это центр любого визуального объекта на нашей канве. И соответственно удобно хранить не длину-ширину, а половину длины и половину ширины. А границы объекта соответственно будем отдавать через геттеры и сеттеры. Дополнительно научим наш спрайт рисоваться. Ну как научим, просто скажем, что он умеет обновляться и рендериться, а его наследники пусть уже решают, как именно они хотят это делать. Но спрайты лишены логики, они ничего не знают о том, как именно будут меняться их свойства. \\ \hline
 
-06-09 & Закончим с отрисовкой и методом onDrawFrame. Он будет обновлять сцену и рендерить её. Для обновления сцены было бы очень неплохо знать дельту времени, которая прошла с предыдущего кадра, чтобы обновлять мир. Конечно можно писать, опираясь на частоту кадра, или на то что мы там спим 16миллисекунд, но это очень сомнительная опора, потому что мы гарантированно спим 16миллисекунд, но сколько именно мы будем выполнять остальные действия - неизвестно, потому что отрисовка происходит не через фиксированные промежутки времени а по очереди сообщений окна и ещё куча факторов, поэтому, лучше всего точно знать сколько времени прошло с предыдущего кадра. Сделаем так чтобы метод onDrawFrame эту самую дельту у канвы получал и отдавал методу обновления. Возможно, метод ещё захочет знать, какая именно канва отрисовалась, вдруг их будет несколько, да и вдруг нам для логики понадобится узнавать размеры канвы... и нам нужен будет объект графики с канвы, чтобы отдавать ей команды на рисование.
-%% 2
+06-12 & Поэтому естественно нужно создать класс собственно шарика, который будет по нашему экрану прыгать, а то непорядок какой-то. В конструкторе задаём ему рэндомные размеры. Давайте придумаем ему какие-нибудь глобальные свойства. Можно конечно придумать класс, который будет направлять наш спрайт и вообще задавать ему скорость и прочие физические величины, но мы ж с вами пример пишем, так что придумаем ему просто - скорость по осям х и у соответственно и цвет. для цвета есть совершенно неожиданно называющийся класс Color которому можно задать величины в формате РГБ в диапазоне от 0 до 255. Для шарика переопределяем апдейт и рендер. суперы нам не нужны, они всё равно пустые. Самый простой рендер - мы объекту графики зададим цвет текущего шарика и сделаем fillOval, которому передадим лево, верх, ширину и высоту. Несмотря на то что наши объекты содержат поля типа флоут, мы работаем с пиксельной системой координат (что конечно же не подходит для реальных проектов, там нужно всё сразу переводить в мировые координаты (например принять центр экрана за 0, верх и лево за -1 низ и право за 1, как это делает OpenGL) чтобы рендерить экраны). Но это нам и пяти лекций не хватит чтобы вникнуть так что не будем. А в методе апдейт мы просто прибавляем к нашим текущим координатам нашу скорость, умноженную на дельту времени, то есть как в третьем классе. Расстояние, которое должен был преодолеть наш шарик за то время пока наш поток спал и наша канва рендерилась. ну и обрабатываем отскоки, то есть описываем 4 условия, что при достижении границы мы меняем направление вектора. \\ \hline
 
-Соответственно считаем дельту в канве. Важно, чтобы привести всё к привычному времени, например, пиксель-в-секунду, отдавать время в секундах, поэтому дополнительно переводим из наносекунд в секунды. Вот, собственно и вся физика, которая нам понадобится. отдадим себя и отдадим свой объект графики, чтобы основная логика могла узнать наши размеры и на нас же рисовать. Все изменения канвы вы видите на слайде, все изменения основного окна ему соответствуют. Пока самое главное, что нам нужно понять об этих двух объектах - канва считает для нас время в физическом мире и постоянно перерисовывает себя, сообщая об этом факте основному окну, а основное окно на этот факт как-то реагирует. Ну и ООП вокруг этого тоже было бы хорошо понимать, объекты передают ссылки друг на друга и вызывают друг у друга всякие интересные методы. \\ \hline
+06-13 & давайте быстренько допилим основной класс и будем переходить к беседе об интерфейсах уже, а то чувствую вы подустали от вступлений. В основном классе мы делаем очень прямолинейно - создаём классовый массив из спрайтов и называться он будет sprites и мы говорим что будет у нас допустим 1 кружчек. В методе апдейт мы пробежимся по всем спрайтам и скажем каждому из них - апдейться так как ты умеешь. В методе рендер мы сделаем тоже самое - пробежимся по всем спрайтам и скажем - отрисуйся так, как ты хочешь. И всё, реализацию обновления и отрисовки мы оставили самим объектам, то есть инкапсулировали в них, только каждый объект сам по себе знает, как именно ему обновляться с течением времени, и как рисоваться, а основной экран уже управляет - на какой канве, когда и кого рисовать. Итак инициализировали наше приложение одним новым шариком и напишем небольшую магию по добавлению новых шариков в динамически расширяемый массив. Как известно, в джава все массивы имеют неизменяемую размерность. Это накладывает некоторые архитектурные ограничения на программиста, но мы ж с вами крутые программисты, вон сколько лекций и семинаров позади, можем обмануть систему. Код не сложный, когда старый массив заполнился, просто увеличиваем его в два раза и переносим шарики из старого в новый. \\ \hline
 
-06-10 & Рисовать несложные штуки мы научились буквально на прошлой лекции. Наше приложение будет рисовать какие-то объекты, будут это кружки, квадратики, картинки, человечки или какие-то другие объекты - не важно. Важно, чтобы у программы было описан механизм и поведение этих объектов. Это как раз то, о чём я говорил и говорю - применение архитектуры, применение ООП. Мало просто посмотреть уроки, почитать книжки, посидеть на семинаре. Надо сидеть и думать в рамках парадигмы ООП. Это ещё простенькая архитектура. Я догадываюсь, что вы смотрите сейчас, и вроде всё понятно, а сами в жизни бы такое не написали. Я сам несколько лет назад такое в жизни не написал бы, так что не переживайте, всё придёт с опытом. Главное, не путайте понятия уметь программировать и знать язык программирования. В какой-то момент вы поймаете себя на мысли, что вы не думаете о циклах и условиях, а думаете на следующем уровне абстракции, думаете о взаимосвязях, об архитектуре, а пальцы сами набирают какие-то языковые конструкции. \\ \hline
+06-14 & И осталось эти методы откуда-то вызывать. Мы на нашу канву в конструкторе вешаем слушателя мышки, который нам рассказывает когда произоши какие-то события. Сегодня как раз будем анонимные классы проходить, поговорим об этом явлении подробнее. И по этому произошедшему событию мы говорим - добавь нам спрайт с новым мячиком, у которого будут координаты этого события. Для этого конечно пришлось немного модифицировать класс шарика, добавив в него ещё один конструктор, который сразу задаёт начальные координаты. На правую кнопку мышки повесим удаление спрайта из списков обновления и отрисовки. \\ \hline
 
-06-11 & Соответственно, рисовать просто линии круги и прочее - довольно скучно, поэтому будем рисовать объекты, Создадим класс Спрайт. Ни от чего наследоваться не будем. Просто опишем общее для всех рисуемых объектов в нашей программе поведение. Что может быть у всех объектов в приложении общего? размеры, местоположение. Обычно, когда вы начинаете изучать какой-то графический фреймворк вы замечаете, что начало координат у этого фреймворка находится в верхнем левом или нижнем левом углу. Однако очень часто, когда пишутся какие-то игры или другие приложения с использованием графики в качестве координат используется центр объекта. То есть надо условиться - что икс и игрек - это центр любого визуального объекта на нашей канве. И соответственно удобно хранить не длину-ширину, а половину длины и половину ширины. А границы объекта соответственно будем отдавать через геттеры и сеттеры. Дополнительно научим наш спрайт рисоваться. Ну как научим, просто скажем, что он умеет обновляться и рендериться, а его наследники пусть уже решают, как именно они хотят это делать. Но спрайты лишены логики, они ничего не знают о том, как именно будут меняться их свойства. \\ \hline
+06-15 & Получается, мы меньше чем за полчаса написали довольно простое и очень хорошо расширяемое приложение, которое не только рисует вещи, но и на действия пользователя реагирует, кажется, неплохо. Напомню, что самое главное, что мы должны из этого приложения извлечь - это взаимодействия и взаимовлияния объектов. Наследование, полиморфизм, инкапсуляция поведений и свойств. Если честно, я слегка устал от синего цвета нашего фона и решил создать отдельный класс фона, но сразу столкнулся с необходимостью думать головой. Логично было бы предположить, что фон - это спрайт, имеющий прямоугольную форму и всегда рисующийся первым. но вот беда, при изменении размеров окна фон тоже желательно изменить в размерах. Поэтому в отрисовке я просто говорю канве, что она должна изменить свой цвет фона, а что, ссылка то на канву у меня есть. Цвет фона я меняю синусоидально по каждому из трёх компонент цвета, поэтому изменение происходит довольно плавно. В общем, получается, что от спрайта нам фактически нужно только поведение, а свойства не нужны. Но и отказаться от наследования нам бы не хотелось, потому что тогда мы не сможем фон единообразно в составе массива спрайтов обновлять. Это наталкивает нас на мысль об унификации поведения, на мысль об интерфейсе. \\ \hline
 
-06-12 & Поэтому естественно нужно создать класс собственно шарика, который будет по нашему экрану прыгать, а то непорядок какой-то. В конструкторе задаём мячику рэндомные размеры. Давайте придумаем ему какие-нибудь глобальные свойства. Можно конечно придумать класс, который будет направлять наш спрайт и вообще задавать ему скорость и прочие физические величины, но мы ж с вами пример пишем, так что придумаем ему просто - скорость по осям х и у соответственно и цвет.
-%% 2
+Отбивка Понятие интерфейса & Механизм наследования очень удобен, но он имеет свои ограничения. В частности мы можем наследовать только от одного класса, в отличие, например, от языка С++, где имеется множественное наследование \\ \hline
 
-Для шарика переопределяем апдейт и рендер. суперы здесь не нужны, они всё равно пустые. Самый простой рендер - мы объекту графики зададим цвет текущего шарика и сделаем fillOval, которому передадим лево, верх, ширину и высоту. Несмотря на то что наши объекты содержат поля типа флоут, мы работаем с пиксельной системой координат, а значит надо переводить в целые числа, (что конечно же не подходит для реальных проектов, там нужно всё сразу переводить в мировые координаты (например принять центр экрана за 0, верх и лево за -1 низ и право за 1, как это делает OpenGL) чтобы рендерить экраны). Но это нам и пяти лекций не хватит чтобы вникнуть так что не будем.
-%% 3
+интерфейс - это описание способов взаимодействия с объектом. фото руля-педалей-коробки, фото юсб, фото клавиатуры-мышки-монитора & В языке Java эту проблему частично позволяют решить интерфейсы. Интерфейсы определяют некоторый функционал, не имеющий конкретной реализации, который затем реализуют классы, применяющие эти интерфейсы. И один класс может применить к себе множество интерфейсов. Правильно говорить реализовать интерфейс, будем сразу говорить правильно. Если сказать проще, интерфейс можно очень-очень грубо представить как очень-очень абстрактный класс. До седьмой джавы это был просто набор методов без реализации. Начиная с восьмой наделали много тонкостей, с ними и будем разбираться. Итак интерфейс - это описание методов. Примером интерфейса в реальной жизни может быть интерфейс управления автомобилем, интерфейс взаимодействия с компьютером или даже интерфейс USB, так, компьютеру не важно, что именно находится по ту сторону провода, флешка, веб-камера или мобильный телефон, а важно, что компьютер умеет работать с интерфейсом USB, отправлять туда байты или получать. Потоки ввода-вывода, которые мы проходили чуть раньше - это тоже своего рода интерфейс, соединяющий не важно какой программный код и не важно какой, например, файл. Все методы во всех интерфейсах всегда публичные, и в классическом варианте не имеют реализации. Ну и поскольку все методы всегда паблик то этот модификатор принято просто не писать. Для новичка это неочевидно и сбивает с толку, может показаться что модификатор дефолтный, а на самом деле он публичный, поблагодарим разработчиков джавы и пойдём дальше. \\ \hline
 
-А в методе апдейт мы просто прибавляем к текущим координатам шарика его скорость, умноженную на дельту времени, то есть как в третьем классе. Расстояние, которое должен был преодолеть шарик за то время пока канва спала и рендерилась. ну и обрабатываем отскоки, то есть описываем 4 условия, что при достижении границы мы меняем направление вектора. \\ \hline
+06-16 & Интерфейсы объявляются также, как классы, и вообще могут иметь очень похожую на класс структуру, то есть быть вложенным или внутренним, но чаще всего интерфейсы описывают в отдельном файле, также как класс, но используя ключевое слово интерфейс. Создадим пару интерфейсов, например, человек и бык, опишем в них методы, например, ходить и издавать звуки. \\ \hline
 
-06-13 & быстренько допилим основной класс и будем переходить к беседе об интерфейсах уже, а то чувствую вы под-устали от вступлений. В основном классе мы делаем очень прямолинейно - создаём массив из спрайтов и называться он будет sprites и мы говорим что будет у нас допустим 10 кружчков. В методе апдейт мы пробежимся по всем спрайтам и скажем каждому из них - апдейться так как ты умеешь. В методе рендер мы сделаем тоже самое - пробежимся по всем спрайтам и скажем - отрисуйся так, как ты хочешь. И всё, реализацию обновления и отрисовки мы оставили самим объектам, то есть инкапсулировали в них, только каждый объект сам по себе знает, как именно ему обновляться с течением времени, и как рисоваться, а основной экран уже управляет - на какой канве, когда и кого рисовать. В конструкторе же добавим простой цикл инициализирующий приложение десятью шариками. \\ \hline
+06-17 & Для чего мы так сделали? Продолжим пример, создадим пару классов, класс мужчина и класс был. Класс мужчины будет у нас реализовывать интерфейс человека. То есть множественного наследования нет, но мы можем реализовать сколько угодно интерфейсов. Для того, чтобы реализовать интерфейс - мы должны переопределить все его методы, либо сделать класс абстрактным. Вот, статический анализатор кода в идее нам об этом явно говорит. Выведем модное сообщение о том что это классы мужчины или быка. 
+И теперь самая соль - мы можем в мэйне объявлять не только классы и создавать объекты, но и создать переменную, которая реализовывает интерфейс. То есть тут могут лежать абсолютно никак не связанные между собой объекты, главное, чтобы они реализовывали интерфейсА. И мы можем работать с методами интерфейса, которые могут быть для разных классов вообще по-разному реализованы. Такой вот полиморфизм. Понимаете насколько сильно это отличается от наследования, когда мы с вами создавали общий абстрактный класс животное и от него наследовали наших котиков? \\ \hline
 
-06-14 & Получается, мы меньше чем за час, с учётом того что этот код надо как-то набрать, написали довольно простое и очень хорошо расширяемое приложение, которое рисует штуки. Напомню, что самое главное, что мы должны из этого приложения извлечь - это взаимодействия и взаимовлияния объектов. Наследование, полиморфизм, инкапсуляция поведений и свойств. Если честно, я слегка устал от синего цвета фона, а внимательный зритель мог заметить, что в одном из последних снимков с кодом я убрал строку, изменяющую цвет фона из конструктора. Начать разговор об интерфейсах я решил с создания отдельного класса фона, но сразу столкнулся с необходимостью думать головой. \\ \hline
+06-18 & Чтобы стало сильно понятнее, создадим класс минотавра, кто плохо помнит греческую мифологию, это такой товарищ, который с телом человека и головой быка скучно сидел в лабиринте и ждал заблудившихся путников. соответственно, реализовывал интерфейсы человека и быка своим способом, ходил на ногах человека, но не мычал, как бык, а загадки загадывал. Интересно то, что в программе мы можем к минотавру обратиться не только как к человеку, но и как к быку, то есть гипотетически, можно создать некоторого Тесея, погонщика минотавровых стад. Но это уже, так сказать, полёт фантазии, нас интересует только техническая часть вопроса - классы не связаны между собой наследованием, а обращение к ним единообразное. \\ \hline
 
-06-15 & Логично было бы предположить, что фон - это спрайт, имеющий прямоугольную форму и всегда рисующийся первым. Но, вот беда, при изменении размеров окна фон тоже желательно изменить в размерах, а это лишние слушатели и десятки строк кода, поэтому в отрисовке класса Фон я просто говорю канве, что она должна изменить свой цвет фона. А что, ссылка то на канву у меня есть, имею право. Цвет фона я меняю синусоидально по каждому из трёх компонент цвета, поэтому изменение происходит плавно. В общем, получается, что от спрайта, фактически, нужно только поведение, а свойства не нужны. Но и отказаться от наследования нам бы не хотелось, потому что тогда мы не сможем фон единообразно в составе массива спрайтов обновлять. Это наталкивает нас на мысль об унификации поведения, на мысль об интерфейсе. \\ \hline
+06-19 & Также важно, что в интерфейсах разрешено наследование. То есть у нас интерфейс может наследоваться от другого интерфейса, соответственно при реализации интерфейса мы должны переопределить методы всех родителей нашего интерфейса, то есть тут картина очень похожа на наследование классов, но внимание не запутайтесь, в интерфейсах разрешено множественное наследование. \\ \hline
 
-06-16 & Механизм наследования очень удобен, но он имеет свои ограничения. В частности мы можем наследовать только от одного класса, в отличие, например, от языка С++, где имеется множественное наследование \\ \hline
+06-20 & На несколько минут вернёмся к бэкграунду, пока мы его не забыли, применим наши новые интерфейсные знания на практике. Фон наследуется от спрайта, но ему от спрайта вообще ничего не надо, кроме двух методов. в которых он полностью пишет собственную реализацию, которая никак не коррелирует с тем, как ведут себя остальные спрайты. И вот сложилась ситуация в которой нам надо хранить в одном массиве очень похожие объекты но наследовать их друг от друга не логично. Как поправить?  \\ \hline
 
-06-17 & В языке Java эту проблему частично позволяют решить интерфейсы. Интерфейсы определяют некоторый функционал, не имеющий конкретной реализации, который затем реализуют классы, применяющие эти интерфейсы. И один класс может применить к себе множество интерфейсов. Правильно говорить реализовать интерфейс, будем сразу говорить правильно. Если сказать проще, интерфейс можно очень-очень грубо представить как очень-очень абстрактный класс. До седьмой джавы это был просто набор методов без реализации. Начиная с восьмой наделали много тонкостей, с ними и будем разбираться. Итак интерфейс - это описание методов. Примером интерфейса в реальной жизни может быть интерфейс управления автомобилем, интерфейс взаимодействия с компьютером или даже интерфейс USB, так, компьютеру не важно, что именно находится по ту сторону провода, флешка, веб-камера или мобильный телефон, а важно, что компьютер умеет работать с интерфейсом USB, отправлять туда байты или получать. Потоки ввода-вывода, которые мы проходили чуть раньше - это тоже своего рода интерфейс, соединяющий не важно какой программный код и не важно какой, например, файл. \\ \hline
+06-21 & Напишем некий интерфейс, назовём его GameObject и скажем, что у него есть методы апдейт и рендер, без реализации. То есть это будут некие объекты которые должны уметь рисоваться и обновляться. Идём в спрайт, и говорим, что мы реализуем интерфейс гейм объекта. Смотрим, что сломалось, кто навскидку скажет, почему? Не нужно судорожно хвататься за клавиатуру, но мысль правильная - модификатор должен быть паблик. И Фон тоже теперь у нас реализует интерфейс гейм объекта. При этом получается, то фон вообще никак не связан со спрайтом, у них даже набор полей разный. Но оба умеют рисоваться и апдейтиться, благодаря интерфейсу. Быстро поправив основное окно и логику, сменив массив спрайтов на массив геймОбъектов запускаем и видим как бодро летают наши шарики. \\ \hline
 
-06-18 & Интерфейсы объявляются также, как классы, и вообще могут иметь очень похожую на класс структуру, то есть быть вложенным или внутренним, но чаще всего каждый отдельный интерфейс описывают в отдельном файле, также как класс, но используя ключевое слово интерфейс. Создадим пару интерфейсов, например, человек и бык, опишем в них методы, например, ходить и издавать звуки.  Все методы во всех интерфейсах всегда публичные, и в классическом варианте не имеют реализации. Ну и поскольку все методы всегда паблик то этот модификатор принято просто не писать. Для новичка это неочевидно и сбивает с толку, может показаться что модификатор дефолтный, а на самом деле он публичный, видите, среда разработки отметила ключевое слово паблик как лишнее? поблагодарим разработчиков джавы и пойдём дальше. \\ \hline
+06-22 & И вот мы подошли к самому главному, той гибкости, которую даёт нам работа с интерфейсами. Если вы обратите внимание, как развивается наше повествование по курсу, вы заметите, что сначала мы выходили за пределы одного метода, потом за пределы одного класса, затем за пределы одного пакета, за пределы программного кода, а теперь вовсе хотим написать код, который возможно будет использовать несколькими программами. Посмотрим со стороны, что мы тут понаписали. У наших классов канвы и спрайта, а также у интерфейса нет никакой специфики, их можно применить где угодно. Универсальные получились штуковины. Создадим какую-то условную вторую игру: новый пакет, новый класс, скопипастим немного кода, чтобы всё запускалось. И не писать же нам по новой спрайты и интерфейсы. сделаем правильное дробление по пакетам. то есть получается, что у нас есть некий библиотечный пакет, и какие-то игры с конкретными реализациями. создадим пакет КОММОН и переносим туда канву, спрайт и геймобъект, и ща будем всё чинить. Структура же понятна, только что её всесторонне обговорили? \\ \hline
 
-06-19 & Для чего мы так сделали? Продолжим пример, создадим пару классов, класс мужчина и класс бык. Класс мужчины будет реализовывать интерфейс человека, а класс быка внезапно быка. Для того, чтобы реализовать интерфейс - мы должны переопределить все его методы, либо сделать класс абстрактным. Статический анализатор кода в идее нам об этом явно скажет. Выведем модное сообщение о том что это методы мужчины или быка. То есть множественного наследования нет, но мы можем реализовать сколько угодно интерфейсов.
-%% 2
+06-23 &  Гейм объект это интерфейс, ему вообще на всё плевать, только импорты лишние выкинем. Спрайт тоже не сломался, модификаторы доступа поправим на публичные и защищённые, где это возможно. Второе главное окно также инитим конструктор, размеры, положение. И вот хотим воспользоваться нашей канвой. Но не даёт же. почему, мы ж так классно всё придумали, никакой специфики. Но нет, канва то может принимать в конструкторе mainCircles. и канва уже у этого класса вызывает метод onDrawFrame(). Как это решается? это решается интерфейсом. нам надо написать какой-то интерфейс вроде canvasPaintListener, который будет уметь ждать от канвы вызов метода и как-то по своему его реализовывать. А то у нас получается катастрофа - игры зависят от общего пакета, а по хорошему общий пакет вообще ничего не должен знать о том, какие игры он помогает создать. Создаём в общем пакете интерфейс с одним методом, который имеет сигнатуру из нашего mainCircles. И перепишем канву, чтобы она не какой-то класс с шариками на вход принимала, а canvasPaintListener, назовём переменную листнер. и везде используем слушателя через интерфейс. В главном окне мы говорим что классы вы конечно хорошие, с прекрасным наследованием от фреймворка, но только ещё будете реализовывать интерфейс слушателя канвы. а метод у нас уже правильно написан, с верной сигнатурой. Чтобы подчеркнуть, что это реализация интерфейса, напишем аннотацию оверрайд. \\ \hline
 
-И теперь получается самая соль - мы можем в объявлять не только классы и создавать объекты, но и создать переменную, которая реализовывает интерфейс. То есть тут могут лежать абсолютно никак не связанные между собой объекты, главное, чтобы они реализовывали интерфейс. И мы можем работать с методами интерфейса, которые могут быть для разных классов вообще по-разному реализованы. Такой вот полиморфизм. Понимаете насколько сильно это отличается от наследования, когда мы с вами создавали общий абстрактный класс животное и от него наследовали наших котиков? \\ \hline
-
-06-20 & Чтобы стало сильно понятнее, создадим класс минотавра. Для тех, кто не застал античную грецию, напоминаю это такой товарищ, который с телом человека и головой быка скучно сидел в лабиринте и ждал заблудившихся путников. Соответственно, реализовывал интерфейсы человека и быка каким-то своим способом, а именно, ходил на ногах человека, но не мычал, как бык, а загадки загадывал. Интересно то, что в программе мы можем к минотавру обратиться не только как к человеку, но и как к быку, то есть гипотетически, можно создать некоторого Тесея, погонщика минотавровых стад. Но это уже, так сказать, полёт фантазии, нас интересует только техническая часть вопроса - классы не связаны между собой наследованием, а обращение к ним единообразное. \\ \hline
-
-06-21 & Также важно, что в интерфейсах разрешено наследование. То есть у нас интерфейс может наследоваться от другого интерфейса, соответственно при реализации такого, наследующего интерфейса, мы должны переопределять не только методы интерфейса, но и методы всех его родителей, то есть тут картина очень похожа на наследование классов, но внимание не запутайтесь, в интерфейсах разрешено множественное наследование. То есть ваш милый домашний пушистый котик может быть также одновременно сумасшедшим ночным тыгыдыком и хищником-убийцей из дикой природы. Ну или вот, как на слайде, много разной мифологии. Это у меня сюда ещё химера не поместилась. \\ \hline
-
-06-22 & Давно я не задавал никаких вопросов, уже устали, наверное. Давайте отвлечёмся и ответим на пару вопросов. 1. Программный интерфейс - это: 1. окно приложения в ОС; 2. реализация методов объекта; 3. объявление методов, реализуемых в классах.
-
-... 30сек ...
-это объявление методов, которые потом будут реализованы каждым классом по-своему. Далее... Интерфейсы нужны для: 1. компенсации отсутствия множественного наследования; 2. отделения API и реализации; 3. оба варианта верны.
-
-... 30 сек...
-оба варианта верны, интерфейсы это достаточно гибкий инструмент, который выступает в роли безопасной замены множественного наследования и позволяет отделить АПИ от реализации. И последнее в этом подразделе. Интерфейсы позволяют: 1. удобно создавать новые объекты, не связанные наследованием; 2. единообразно обращаться к методам объектов, не связанных наследованием; 3. полностью заменить наследование.
-
-... 30 сек ...
-Конечно, полностью заменить наследование не получится, и ни о каком удобстве создания объектов речи не идёт, интерфейсы действительно позволяют единообразно обращаться к объектам, не связанным наследованием, но реализующим один интерфейс. как флешки-мышки и прочая ЮЗБи периферия, помните? \\ \hline
-
-06-23 & На несколько минут вернёмся к фону, пока мы его полностью не забыли, применим наши новые интерфейсные знания на практике. Фон наследуется от спрайта, но ему от спрайта вообще ничего не нужно, кроме двух методов, в которых он реализует своё собственное поведение, которое в свою очередь никак не коррелирует с тем, как ведут и что хранят в себе остальные спрайты. И вот сложилась ситуация в которой нам надо хранить в одном массиве спрайтов в основной программе очень похожие объекты но наследовать их друг от друга не совсем логично. Как поправить?  \\ \hline
-
-06-24 & Напишем некий интерфейс, назовём его Interactable и скажем, что у него есть методы апдейт и рендер, без реализации. Вообще, если по хорошему, нужно было создавать два интерфейса, Updatable и Renderable, Чтобы иметь возможность отделить рисуемые объекты от обновляемых, но у нас же с вами пример, поэтому мы создадим единый интерфейс. То есть это будут некие объекты которые должны уметь рисоваться и обновляться. Идём в спрайт, и говорим, что мы реализуем интерфейс взаимодействуемого. Смотрим, что сломалось, кто навскидку скажет, почему? Не нужно судорожно хвататься за клавиатуру, но мысль правильная - модификатор должен быть паблик, потому что интерфейс по умолчанию содержит публичные методы, а сужать область видимости запрещено.
-%% 2
-
-И Фон тоже теперь у нас реализует интерфейс Interactable. При этом получается, то фон вообще никак не связан со спрайтом, у них даже набор полей разный. Но при этом, оба умеют рисоваться и апдейтиться, благодаря интерфейсу. Быстро поправив основное окно и логику, сменив массив спрайтов на массив интерактивностей можем запустить и увидеть, как снова весьма бодро по экрану летают наши шарики. \\ \hline
-
-06-25 & И вот мы подошли к самому главному, той гибкости, которую даёт нам работа с интерфейсами. Если вы обратите внимание, как развивается наше повествование по курсу, вы заметите, что сначала мы выходили за пределы одного метода, потом за пределы одного класса, затем за пределы одного пакета, за пределы программного кода, а теперь вовсе хотим написать код, который возможно будет использовать несколькими программами.
-%% 2
-
-Посмотрим со стороны, что мы тут написали. У классов канвы и спрайта, а также у интерфейса нет никакой специфики, их можно применять, по сути, где угодно, не только в этой конкретной программе с этими конкретными классами. Универсальные получились штуковины. Создадим какую-то условную вторую игру: новый пакет, новый класс, скопипастим туда немного кода от мячиков. И не писать же нам по новой спрайты и интерфейсы. сделаем правильное дробление по пакетам и станет очевидно, что у нас есть некий общий библиотечный пакет, и какие-то игры с конкретными реализациями. создадим пакет common, переносим туда канву, спрайт и геймобъект, и будем всё чинить. \\ \hline
-
-06-26 &  Те кто делает это прямо сейчас, смотря эту лекцию в записи, могут обратить внимание, что общий пакет перенёсся вовсе без проблем, шарики перенеслись с минимальными изменениями, только публичные модификаторы понадобились. Во втором главном окне создали такой же конструктор, размеры, положение. И вот хотим воспользоваться общей канвой. Но не даёт же. Почему? мы же так классно всё придумали, никакой специфики. Но нет, канва то может принимать в конструкторе только мэйн окна из пакета кружочков. и канва уже у этого класса вызывает метод onDrawFrame(). Привязались к классу, связали себя по рукам и ногам сразу.
-%% 2
-
-Как это решается? это решается интерфейсом. нам надо написать какой-то интерфейс вроде canvasRepaintListener, который будет уметь ждать от канвы вызов метода и как-то по своему его реализовывать. А то у нас получается катастрофа - игры зависят от общего пакета, а по хорошему общий пакет вообще ничего не должен знать о том, какие игры он помогает создать. Создаём в общем пакете интерфейс с одним методом, который имеет сигнатуру из mainWindow. И переписываем канву так, чтобы она не какой-то класс с шариками на вход принимала, а canvasRepaintListener. и везде используем слушателя через интерфейс.
-%% 3
-
-Внимательно смотрите на ещё один фокус. Мы помним, что интерфейс может быть реализован классом, а наши окна - это тоже классы. И вот они наследуются от ДжейФрейма. Привычные нам наследование и полиморфизм утверждают, что это всё, что мы можем сделать. А мы нашим классам внезапно говорим что классы вы конечно хорошие, с прекрасным наследованием от фреймворка, но теперь ещё будете реализовывать интерфейс слушателя канвы. Следовательно, можете продолжать передавать себя в конструктор, а метод интерфейса у нас уже правильно реализован, с верной сигнатурой. Чтобы подчеркнуть, что это реализация интерфейса, допишем аннотацию оверрайд. \\ \hline
-
-06-27 & Насладимся летающими шариками в одном приложении, и летающими квадратиками в другом. Теперь на основе нашего очень хорошо отделённого интерфейсами общего пакета можно штамповать такие приложения практически без усилий. Понимаете, как разработчики в игровых студиях делают по сотне очень похожих игр в год? \\ \hline
-
-06-28 & Дефолтная реализация интерфейса \\ \hline
- & \\ \hline
- & \\ \hline
+06-24 & Насладимся летающими шариками в одном приложении, и летающими квадратиками в другом. Теперь на основе нашего очень хорошо отделённого интерфейсами общего пакета можно штамповать такие приложения практически без усилий. Понимаете, как разработчики в игровых студиях делают по сотне очень похожих игр в год? \\ \hline
 
 отбивка Анонимные классы & Программные интерфейсы открывают перед разработчиком широчайшие возможности по написанию более выразительного кода. Одна из наиболее часто используемых возможностей - анонимные классы. \\ \hline
 
@@ -129,68 +84,12 @@
 	   Понятен-ли этот синтаксис? Это создание объекта анонимного класса, никак не называющегося, реализующего интерфейс.
 	   Тут можно поговорить о лямбдах, для того чтобы сократить синтаксис мы можем просто убрать то что неизменно для этого анонимного класса - название интерфейса, название метода и класс аргумента. \\ \hline
 
-
  & \\ \hline
  & \\ \hline
  & \\ \hline
 
 \end{longtable}
-
-\begin{figure}[H]
-  \centering
-  \fontsize{12}{1}\selectfont
-  \includesvg[scale=1.01]{pics/jd-02-interfaces-use.svg}
-\end{figure}
-
-%\scalebox{.45}{\input{pics/jd-02-bkg-sine.pgf}}
-
-  \begin{forest}
-    for tree={
-      font=\ttfamily, grow'=0, child anchor=west,
-      parent anchor=south, anchor=west, calign=first,
-      edge path={
-        \noexpand\path [draw, \forestoption{edge}]
-        (!u.south west) +(7.5pt,0) |- node[fill,inner sep=1.5pt]
-        {} (.child anchor)\forestoption{edge label};
-      }, before typesetting nodes={
-        if n=1 {insert before={[,phantom]}} {} },
-      fit=band, before computing xy={l=20pt},
-    }
-    [JDKit
-     [src/ru.gb.jdk.two.online
-      [bricks
-       [Brick]
-       [MainWindow]
-      ]
-      [circles
-       [Background]
-       [Ball]
-       [MainWindow]
-      ]
-      [common
-       [Interactable]
-       [MainCanvas]
-       [Sprite]
-      ]
-     ]
-     [README.md]
-    ]
-  \end{forest}
-  
 \end{document}
 
-
-дз -- динамичкески расширяемый массив и слушатели кнопок. подводка: Как известно, в джава все массивы имеют неизменяемую размерность. Это накладывает некоторые архитектурные ограничения на программиста, но мы ж с вами крутые программисты, вон сколько лекций и семинаров позади, можем обмануть систему. Код не сложный, когда старый массив заполнился, просто увеличиваем его в два раза и переносим шарики из старого в новый
-
-
 ****** Вернёмся к нашим кружочкам
 	   Смотрим прям первый метод, invokeLater() он принимает на вход какой-то Runnable. Идём в Runnable и видим, что это интерфейс, который реализует один единственный метод run(). Получается, что мы в invokeLater передаём новый экземпляр анонимного класса который РЕАЛИЗУЕТ ИНТЕРФЕЙС Runnable, вот описание этого класса, мы в нём переопределяем метод run. Вот так это читается. Ровно тоже самое мы сделали с mouseListener. Здесь немного сложнее. Есть интерфейс MouseListener в котором описаны вот эти все методы. И есть специальный класс MouseAdapter в котором все эти методы уже реализованы. Реализации пустые, но они есть, поэтому мы можем не все методы оверрайдить, а только те, которые посчитаем нужными. И когда мы этот MouseAdapter отдаём нашему методу, мы говорим: создай нам новый экземпляр анонимного класса, который НАСЛЕДУЕТСЯ ОТ КЛАССА MouseAdapter и переопредели вот этот метод. Остальные оставляй пустыми. Чувствуете разницу? Как можно избежать таких конструкций и при этом получить понятный код без лишних заморочек? Очень просто. Скажем, что наш класс - реализует тот или иной интерфейс, и переопределим все методы. В некоторые из них даже напишем реализацию, и туда, где требуется интерфейс - передадим себя. Мы же теперь MouseListener, да и Runnable.
-
-
-       исключения
-       06-29 & Осталось коротко поговорить о некоторых особенностях работы приложений, использующих графические интерфейсы. \\ \hline 
-
-06-30 & Поскольку графический оконный интерфейс - это всегда многопоточность, да и привычного нам терминала под рукой нет, то тут сразу возникают особенности с обработкой исключений. Как ловить? Как показывать? Вот, например, есть у нас какое-то окно, на котором есть кнопка. У кнопки есть обработчик, в котором что-то идёт не так, скажем, выход за пределы массива. достаточно типичная ситуация. Как
-
-
-Аннотации?