Тем не менее вы в данный момент пытаетесь выдать свои формулировки за абсолютную истину. Если нет, то я не понимаю вообще смысла этого спора.

Ждем с нетерпением. 

я бы уже после этого закрыл спор   

Асилил   Особо улыбнуло следующее: квадрат - суть точка, точка имеет размер(Si!), а квадрат имеет координаты(впервые слышу, честно говоря... координаты имеет каждая из вершин квадарта, но не квадрат в целом). Конечно, это мелочи на фоне развёрнутых боевых действий   Так и не понял, в чём же свойства виноваты? Как уже было замечено(вполне справедливо) свойства, в отличии от публичных полей, просто замаскированный синтаксисом вызов методов - где тут нарушение инкапсуляции? 

Господин NotGonnaGetUs имел смелость предположить, что незнание мною известной ему формулировки говорит о моем незнании формулируемого.  





Этого хватит. Да, если вы мне захотите сказать, что я сам был против возврата данных (как NotGonnaGetUs) - перечитайте мои посты.

Добавлено @ 00:05 

Как уже было замечено (вполне справедливо), свойства, в отличие от обычных публичных полей, просто замаскированы парой методов. Но при этом остаются публичными полями.   

Это сообщение отредактировал(а) w1nd - 19.5.2006, 08:46

Спорные аргументы приводите.

http://forum.vingrad.ru/index.php?showtopi...st&p=736064 

Я правильно понял? Вы против данных, связанных с конкретным экземплярам объекта, как таковых? Т.е. из связки код+данные просто выбрасываем вторую часть и оставляем только методы? А что же тогда методы будут обрабатывать? Скажем, для отрисовки чего-то надо будет не просто вызвать метод отрисовки, а и обьяснить, в каком месте рисовать и какого размера(ведь данные у нас в объекте не хранятся - надо передавать)?   

Нет, я против свободного доступа к данным объекта. 

w1nd, умница. 

Я бы сейчас с большой радостью поделился своими ошибками.. Как раз вроде наследования компании от контакта. И к чему это привело. Но ведь Вам всё равно плевать на других, лишь бы Вашу идею никто не смог оспорить. Да ну, с Вами неинтересно. Очень напоминает тема вот что:
http://forum.vingrad.ru/index.php?showtopi...44&view=all
Особенно мне нравится последний пост - "Усекли?". Видимо, с такой аргументацией, Ваше мышление тоже никто не "усечёт". 

Я никого здесь не просил поделиться со мной ошибками или "научить" меня что-то правильно делать. Это мне действительно не интересно. Я хотел увидеть ситуацию, когда пример с квадратом действительно работать не будет. Мне казалось - всё пучком.

Действительно интересно - такой пример долго не возникал, всё больше: "ты неуч, ты неумеха, ты пустозвон", да еще неподходящие примеры. А про аргументацию не надо - здесь все отличились нежеланием попросту читать.


   

Это сообщение отредактировал(а) w1nd - 20.5.2006, 01:15

w1nd, против свободного доступа к данным методам самого же объекта?! А кто ж их тогда будет обрабатывать?    

ОК.

Такое поведение нельзя назвать нормальным. 

Компоненты awt и компоненты swing находятся в различных иерархиях наследовния. 
Попробуйте, смеха ради, смешать те и другие компоненты.

Очередь событий не имеет никакого отношения к моделям обработки событий. 

На пальцах: 
awt: при движении мышкой создаётся событие. оно попадает в компонент над которым оно произошло. если компонент его не обработал, оно идёт к следующему компоненту и т.д.
swing: при движении мышкой создаётся событие, которое попадет именно в тот компонент, который на него зарегистировался.

Очередь событий служит для обеспечения доставки событий, но ни как не определяет способ их возникновения и адресатов.

-----



Хотелось бы читать, но приходится распознавать:

"объект сам управляет своими данными" (см. ниже новой термин)"  - так и не увидел, где это ниже...

"как вы управитесь с распределением прав на примере JFrame.getState() или JFrame.getExtendedState()."  -  прав на что и между кем их нужно распределять?

Насчёт чьих-то формулировок это круто  Оказывается "принцип подстановки Лисков" придумал я. Хочу премию за это.

Кстати о терминах:

У любого многоугольника (являющегося геометрическим объектом), который нельзя вписать в окружность, не будет "центра". 


Проекция не зависит от расстояния до плоскости. (с) учебник геометрии

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

-----



Я всегда полагал (со ссылкой на работы классиков "поднявшихся вверх по служебной лестнице" ),  что "структурный" это значит без использования операторов перехода (goto), а "процедурный" это когда есть процедуры/функции.

Вы творчески переосмыслили эти термины:


У вас противопоставляются "структурно-ориентированный" и "процедурно-орентированный" "подходы" между собой и с ООП.

Понять с каких позиций вы противопоставляете С-О и П-О, я так и не смог.
Разницу между ПО и ООП я вижу только в способе декомпозиции, о чём писал выше. 
"не ООП", как я представляю, это "процедурный код с объектами": процедуры помещённые случайным образом в классы (стиль C-шников насильно пересаженных на C++)...

Поскольку getter/setter (доступ к данным) по вашим словам "бредовое ООП", что равнозначно "не ООП", то получаем что получаем: вам придётся писать "процедурный код".

Ах, да. Доступ к данным (c позиций "ООП"): 

Перечитал одно:

другое:

третье:

четвёртое:


----



Во первых _объект_ сам себя создать в приципе не может. Объект всегда создаётся кем-то, посредством вызова конструктора.
Существуют ситуации, когда создатель объекта не может (не известно на момент написания кода) или не должен (из соображений инкапсуляции) знать объект какого класса он создаёт. Решения подобных проблем задокументированы в виде паттернов ООП.
Выходит паттерны ООП полностью "противоречат приципам ООП"?! 

----

Вы уже не считаете, что наследование от точки это хорошая идея, гуд, но, О УЖАС(!),  у класса Point публичные поля! Это же "структурное программирование"(с)w1nd!

А как же утверждение: 



Согласно ему должно быть написано такое:



Нет! Не то. setXAndY() может вызвать кто угодно! Надо сделать интерфейс!



Чёрт, а как же получить x и у  из метода setXAndY в методе вызвавшем plsGiveMeXAndY?
Сделать поля? А если нужно будет у разных точек узнать x и у? Значит нужны локальные переменные для хранения !
Хм. А этого добиться?  Сделаем MutableInteger!



Так, уже лучше..., но что-то не даёт покоя... Ах, да! У MutableInteger есть getter/setter 

Кажется мне, как и w1nd'у, не удалось написать правильную по w1nd ОО программу, не скатившись к структурному/процедруному/плохому ооп (нужное подчеркнуть) 
   

Это сообщение отредактировал(а) NotGonnaGetUs - 20.5.2006, 15:32

Ромб не всегда можно вписать в окружность, но тем не менее центр у него есть. Другое дело что не для всякой геометрической фигуры можно дать определение центра. 

Автор привёл определение "центра", как равноудалённой точки от вершин многоугольника. У робма такой точки нет.