у меня к сожалению классы не открываются ( программы нет нужной )
поэтому я не смогу код посмотреть и прокоментировать :(

Qawra, исходный код можно посмотреть в архиве который выкладывал Kakadu, файлы с расширением .java . Я выложил только саму программу - архив нужно как есть сохранить на компьютер, щелкнуть его второй кнопкой и выбрать "Открыть с помощью"->Java.
BlueJ кстати тоже умеет так упаковывать, программу вместе с исходными кодами и документацией, или без них.


_______________________________

Вот это я не совсем понял  Но тем не менее:
В жизни соединений происходит два важных события - это создание и отрисовка.
Поскольку новые соединения могут образоваться только после добавления новой точки, мы вызываем makeConnections() из mouseWasClicked(), когда известно что точка добавлена. Соединения обнаруживаются и сохраняются в точках.
Отрисовка соединений происходит вместе с отрисовкой точки, что в свою очередь происходит при отрисовке поля.

Попробую запутать вас совсем:
_____________________________
Этот цикл перебирает все точки вокруг проверяемой:

i и j меняют в цикле свои значения от -1 до 1; если i прибавлять к x-координате проверяемой точки, то мы получим х-координату точки слева от проверяемой( х+(-1)=х-1 ), потом с такой же координатой (х+0=х), потом координату точки справа (х+1). Аналогично для координаты y и переменной j.
Все вместе позволяет перебрать точки в таком порядке:
123
456
789
Красным отмечена проверяемая точка.

Внутри циклов выполняется несколько проверок - они необходимы чтобы определить две вещи: необходимость и возможность соединения.

Первое что мы проверяем, это не выпали ли наши координаты (x+i и y+j) за пределы поля; не рекомендуется работать с массивом за его пределами  Конечно, если соседняя точка за пределами поля, т.е. на самом деле не существует, с ней не может быть соединения, спокойно можно ее пропускать и искать дальше. Иначе - есть возможность соединения.

Здесь не совсем проверка. Просто, поскольку дальше мы несколько раз обращаемся к соседней точке, удобнее выложить ее во временную переменную, тогда нам не нужно будет дальше использовать страшное "points[px+i][py+j]" а вместо него использовать b. Разумеется, при каждом проходе цикла туда кладется очередная соседняя точка.

Если a и b - разные точки, и в то же время имеют одинаковый цвет - да, в таком случае соседняя и проверяемая точки принадлежат одному игроку; налицо необходимость соединения.
a!=b мы проверяем, потому что в процессе перебора соседних точек нам должна попасться и текущая точка. Такой уж у нас перебор  Естественно соединять точку саму с собой мы не хотим.

Последняя проверка - на наличие другого диагонального соединения в той же клетке. Если клетка уже перечеркнута по диагонали, мы не можем построить соединение по другой диагонали.
Для этого нам нужно сначала найти две другие точки в той же клетке. Очень удобно то, что для этого достаточно взять x от одной точки и y от другой.
Вот например у нас точки с такими координатами:
[px   py   ] [px+i py   ]
[px   py+j] [px+i py+j]
[px py] это точка a, [px+i py+j] - соответственно точка b.
Тогда две другие точки - это [px+i py] и [px py+j].
Остается проверить, НЕ-соединена ли одна из них с другой - для этого там используется метод isConnectedTo().

Kakadu, код я ваш читал но не вникал сильно  Общий смысл во всяком случае понятен.
Кстати, почему не используются Player1Dead и Player2Dead? Как вы собираетесь подсчитывать очки игроков?

спасибо.. многое стало понятней .
А линии то всё равно не рисуются   

У Kakadu игра на захват вражеских точек идет. Так что контур обводится только если внутри него есть вражеская точка.

Rpahut , мне ваша версия так понравилась что я даже картинку прикрепила с почерневшей точкой попавшей в плен 



Исправьте меня если я не права   ,  мы не использовали полиморфизм но мы 
использовали точно  три принципа обьектно-ориентированного программирования :  encapsulation , inheriance , modylarity .
Data  abstraction мы где-то наверно тоже использовали .... Пытаюсь её отыскать ..



Это сообщение отредактировал(а) Qawra - 13.2.2009, 21:32

Модульность - это не один из Китов ООП. Полиморфизм - да (но вроде его ни у вас, ни у меня нет). Модульность - вообще ерунда какая-то  

P.S. Можете выложить ваши исходники? Просто по всем страницам мне их собирать несколько лень=)
P.P.S. Кстати, наследования у вас вроде тоже нет=)

Ну для полиморфизма маловат проект. А наследуются у нас по меньшей мере JFrame и JPanel, может и что-то еще.

Modularity это не ерунда . Это " the physical and logical decomposition of large and complex things into smaller and manageable   components ". 
У нас она присутствует там где сложные функции разбиты на маленькие методы .
Это она и есть , Modularity .... Мы её учим как принцип  обьектно-ориентированного программирования .

Data Abstruction  можно себе преставить на примере : Водитель водит машину и может не задумываться как двигаются детали внутри  двигателя. Он использует обьект зная только то что ему нужно знать как водителю .А  механик может и не уметь водить машину . Он должен знать все шестерёнки внутри двигателя и уметь их ремонтировать . Один и тот-же обьект  используется по разному .
Вот  этого  различного использования одного и того же обьекта в нашей программе я и не нахожу . 

Исходник большой потому что интерфейс увесистый получился . Ничего сделать не могу .Это мой первый интерфейс ... пускай такой и  будет .
http://rapidshare.com/files/198093947/Project2009.rar.html

26 метров?! Что там такое в архиве?

Ага понятно. Прикольно  

PS Qawra, если все переменные классов public, то это не инкапсуляция  

Это сообщение отредактировал(а) Rpahut - 15.2.2009, 00:46

Ну они же не все публик !







смущает меня то что некоторые из них повторяются в разных классах . Не знаю нормально ли это . 
Изначально так написала потому что иначе не компелировалось .
public Player first;
public Player second;  
и 
 public int rows=20;
 public int cols=20;
 public int cellSize=30 ;
 private Color color;
например   прописаны дважды ...

Под Data Abstruction я хочу подвести класс ColorChooser
  
Здесь делается то чего мы не знаем что и оно показывает нам диалог выбора цвета 
 Мы  ведём машину не зная  что происходит внутри двигателя .

Не удалось мне избавиться только от дублирования 
public int rows=20;
public int cols=20;
public int cellSize=30 ;
в двух классах    Grids   и  GridsCanvas

Это сообщение отредактировал(а) Qawra - 15.2.2009, 12:02

Qawra, почитайте еще про инкапсуляцию.
Каждый класс это отдельное пространство; если у нас два класса то в них хоть все переменные могут иметь одинаковые тип и имя. Как ни крути, а Grids.rows и GridsCanwas.rows отличаются полными именами, т.е. хотя и там и там rows, имена переменных все равно разные.

Момент второй - ключевое слово public применяется только если нужно сделать член класса доступным извне напрямую. Уверяю вас что мы нигде не работаем с переменными напрямую, только через методы классов, которые и помечаем как public.
Например у нас в DrawablePoint есть private переменная color и есть public метод setNewColor(). Программа не будет работать правильно, если записывать цвет прямо в переменную, поэтому мы ограничиваем доступ к ней. Если что компилятор даст нам по рукам - так исключается возможность оставить в программе ошибку.

_________
Если мы не знаем что делает JColorChooser.showDialog(), нам лучше им не пользоваться  . ОК, мы знаем что он делает, но не знаем как - если это и есть абстракция, то мы пользуемся ей сплошь и рядом.
Например тип Color можно считать абстрактным(?). Кто его знает что там у него внутри.

Добавлено через 8 минут и 26 секунд
Вот немного код почистил и добавил кое-что.

Присоединённый файл ( Кол-во скачиваний: 10 )
 tochki.rar 5,59 Kb

Огромное спасибо за кусочек 

у меня до него никак руки не доходили , хотя я чувствовала что он нужен .

В Grids я полностью убрала Serializable  и поменяла переменные на private ..
 в общем то нас как раз учили что по умолчанию всё public .. 
может  просто сделать FINAL  ?

Это сообщение отредактировал(а) Qawra - 16.2.2009, 21:14

Если не указывать модификатор доступа, члены классы доступны везде внутри пакета, почти как public.

В классе Grids

можно сделать константами или final, в классе GridsCanvas пускай будут private.

Так и сделаем ... К сороковой  странице документации я уже сдаюсь  на всё .. документацию я  тоже  уже  сдаю .. 
Что будем ещё привинчивать ? 
Можно сделать решётку resizable .  Но как это сделать в момент игры ... У нас же массив с точками создан до начала игры . Если игроки захотят изменить размер поля - массив придётся создавать заново . Значит  точки которые уже нарисованы игроками надо будет скопировать из одного массива в другой . Потдерживает ли Java такие копирования массивов  я не знаю .