Уж вы укажите явно на апломб и некорректные примеры. Я, честно говоря, таковых не нахожу, но если я совершаю ошибки, хотелось бы знать где, иначе я буду продолжать в том же духе.


Да нет, я пытался точно ответить на вопрос "вы считаете". Я не считаю примитивные типы недопустимыми. 


Если мы начнем считать все методы, возвращающие некоторое значение свойством (о которых я говорил), то далеко уйдем. Я имел в виду именно свойства java-бинов или подобных классов, то есть с getter'ом и setter'ом.

В свойствах я вижу три беды (это навскидку, возможно я что-нибудь забыл).
Во-первых, навязывается существование того или иного свойства объекту (а также его тип - пользователю объекта), тогда как в процессе "эволюции" это свойство может поменять тип или вообще стать ненужным. То есть, как я говорю - лишняя связь, которую придется поддерживать.
Во-вторых, свойство навязывает структурный подход к взаимодействию с объектом: получить значение свойства, произвести некоторые вычисления, результат поместить обратно или передать другому объекту. Что происходит? Логика, свойственная объекту, вынесена из него. Например, часто повторяющийся во всех GUI-фреймворках приём с компонентом и контейнером: допустим, произошло событие, которое контейнеру необходимо передать своим компонентам. Контейнер получает свойства компонент, анализирует их (может ли компонент обработать данное событие) и передает событие на обработку. По объектной идеологии компонент просто должен получить событие. Дальше он либо его обработает (если может), либо вернет контейнеру или остальным компонентам; в этом случае нет необходимости в свойстве state компонента, а логика контейнера значительно более проста.
В-третьих, мы даем право пользователю объекта интерпретировать свойство так, как он того хочет, что не есть правильно. Ведь тогда никто не помешает отобразить размеры ящиков в апельсинах или что-нибудь в этом роде.

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


Точнее, нечто_в_чем_можно_отобразить_текстовую_информацию. Я это уже писал.


Вот, мы наконец-то подобрались к источнику беспокойства участников обсуждения. Я не призываю отказаться от существующих подходов! Я призываю отделить мух от котлет. И это я тоже уже писал. 

Ну уж нет. Давайте разберемся. Не с геометрией, которую я упомянул только в том смысле, что речь не идет о чем-нить вроде точки временного отсчета, а вы полезли в какие-то дебри. Я знать не знаю каких-то точных определений, я пытался передать суть.

Я писал:

• Модель классов в конкретном проекте не должно быть проекцией объектов реального мира. Потому что отягощает. Если у меня в проекте используется иерархия из двух классов, но в реальном мире эта иерархия насчитывает сотни и сотни классов, зачем они все мне? Обобщение имеет смысл только в том случае, когда это где-то используется. В примере в контактом и компанией вы указывали на возможные проблемы при расширении данных контакта. Так если по стеклу молотком ударить - оно разобьется. Без всяких проблем в этом случае создается еще один наследник контакта (персона, например) и никаких изменений в существющем коде не потребуется. Если мне потребуется обобщить - опять же, надстройку над иерархией в никто не заметит. Потому что кода, рассчитанного на новую модель еще нет. 
• Отношение is-a (из наличия которого мы делаем вывод о корректности наследования) определяется свойственностью полей [B]и методов родителя наследнику.[/B] Что означает слово свойственный? Я вкладываю в это понятие отнюдь не совпадение в названии или типе. И уж точно не принципиальную возможность разместить какую-то информацию в участке памяти (NotGonnaGetUs), занимаемой полями. Теперь: точка, размер и квадрат. Поля и методы, принадлежащие точке, свойственны квадрату потому, что он тоже имеет координаты. То же самое с размером. Все методы, работающие с координатами, будучи примененными к квадрату, отработают корректно. То же самое с размером. Дальше, вы говорили, что вызывая метод paint() точки пользователь получит квадрат и сильно будет этим ошарашен. Во-первых, пользователь, конструирующий точку получит точку. Во-вторых, методы, работающие с массивами точек получат то, что сконструировал пользователь. В-третьих, я могу пожелать, чтобы точки у меня отображались, как квадраты 10х10. В-четвертых, методам, работающим с верхним в иерархии классом всё равно.

Что касается примеров NotGonnaGetUs (и вашей позиции, кстати), человек просто решил для себя, что я не прав. Отреагировал на некое ключевое слово (фразу), вырванное из контекста повествования. И примеры его никак не проистекают из моих слов.
 

Этого никто и не утверждает. Объект есть модель некоей сущности реального мира, отражение свойств, существенных в данном контексте. Объект класса Company соответствует к-л реальной кампании, ну, возможно является базовым классом если важно разделить кампании на типы. 


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

наследникам, но отрицаете что слово является(есть) должно быть фактором в построении иерархии наследования. По какому принципу тогда вы делаете вывод о свойственности полей/методов? 
Такой выбор наследования не может быть правильным, тк свойственность методов или полей вы можете определить лишь на данный момент. Завтра или через год требования к продукту изменятся, и ваш базовый класс получит те методы, которые несвойственны наследникам.
Почему-то вы хоть и говорите о том,  что вроде как строго придерживаетесь ООП в рассуждениях, но все-таки забываете любой учебник по ООП говорит о том, что наследование есть специализация, уточнение существующего класса; базовый класс является более общим случаем наследников. Вы-то можете как угодно определять наследование, но в таком случае и разговор ни о чем - речь ведь идет об общепринятых понятиях.
Для меня и Company, и Contact отражают некоторые свойства реальных компаний и контактов, и исходя из реальных объектов я понимаю, что компания не есть контакт, а квадрат не есть точка. Это немного более высокий уровень абстракции, чем свойственность методов и полей, и потому правильный, тк позволяет отразить отношение данных классов более полно. Потому здесь и не будет ошибки такой как


Добавлено @ 15:08 

Метод - точно такая же связь. Никаких отличий нет.


Если так рассуждать, то должны существовать только void методы.



Почему? Ну проедположим метод что-то возвратил  и соответственно возвращенное значение можно интрерпретировать как угодно. В чем разница? 


Ну и отделите на здоровье. Напишите свой небольшой фреймворк, построенный на вашем толкоании ООП. А дальше и посмотрите, насколько правильны ваши рассуждения. Коммунизм тоже был правилен в теории но на практике оказалось совсем иначе. 

В идеале - да.


Снова одно и то же. Вы читаете именно то, что выделили как цитату? Да, я могу определить поля и методы лишь на данный момент, но базовый класс в дальнейшем менять я не собираюсь! Я могу сколько угодно обобщать, могу создавать новых наследников - нет необходимости менять базовый класс. Или приведите пример (отличный от того, что вы приводили с добавлением пола в контакт, ибо в том случае я показал, как следовало это сделать).
А классы отражают свойства не реальных объектов, а объектов данной модели. Ничего больше. В такой модели состав и содержание полей той же компании может полностью отличаться от реального "прототипа". 


В программе, предназначенной для каталогизации контактов, например, все объекты - контакты. Никаких других не может возникнуть никогда. Объекты внутри данной программы - и есть самые что ни есть реальные объекты.


Между чем нет никакой разницы в случае компонента, обладающего свойством size (Dimension) и компонентом без доступа к этому свойству, но методом resize(int, int)?

      

Это сообщение отредактировал(а) w1nd - 17.5.2006, 16:37

Признайтесь, делали ли вы реальные проекты или нет  Или все ваши рассуждения построены только на теории?  

Реальные проекты целиком на ООП - никогда. Только отдельные модули. Но цитата к данному вопросу не подходит. 

Это сообщение отредактировал(а) w1nd - 17.5.2006, 16:40

Раз вы так любите разделять мух, давайте поразделяем.


Вызов _любого_ метода связывает вызывающий класс с вызываемым.
Если метод возвращает какое-либо значение или требует каких-либо параметров, то происходит и связь по "типу"(с).

Здесь нет ничего спецефического для getter/setter. 

Пример с Date и String прозвучавший из ваших уст не решает эту проблему.
Он приводит только к невозможности воспользоваться статической типзацией для контроля типов. 
Вместо того, чтобы при смене формата хранения даты внести исправления в зависимные классы (т.к. они перестанут компилироваться), придётся в ручную искать все использования String, что далеко не тривиальная задача.
Альтернатива - поставлять вместе со String парсер для разбора этой строки и превращения её в date. 
Спрашивается, чем это лучше простого возврата Date?


Кому навязывает структурный подход? Мне нет. Вам?

"во всех GUI-фреймворках". В Swing компонент получает те события на которые он подписался. Никакой анализ контейнер не выполняет.

"По объектной идеологии компонент просто должен". Вы пытаетесь описать chain of responsibility. Данный подход с большим натягом применим к GUI. AWT хорошо показало недостататки такого решения. 
Возможно оно делает логику контейнера более простой, но чертовски усложняет налаживание взаимодействия между _большим_ количеством компонент.
 
Вы вообще представляете какая цель приследовалась при создании спецификации на java beans? Или для вас java bean это просто "класс данных"?
Без javabeans не было бы визуальных конструкторов gui для кастомных компонент, о чём так сильно мечатли в конце 90х.


Мы? Я не даю такого права. Вы даёте? Зря.

А сам пользователь может не правильно интерпретировать любой компонент класса, начиная от назначения параметров и кончая назначением методов. 

Н-р, можно использовать String как счётчик.
String x = "";
...
x += " ";
...
int count = x.length();

Объявим String вне закона?

Способов заставить человека правильно "понимать" два и оба не совершенны.
Первый, описать правильное понимание в javaDoc'e к классу. (Всегда найдётся тот, кто не станет ничего читать, т.к. он уже "перестал учиться" и ему теперь всё можно).
Второй, ввести в код как можно больше проверок и бить по руками за "неверное" использование. (Реализуемо только для тривиальных случаев, н-р, проверок диапазонов значений, asserts).


Все три ваши пункта относятся в равной степени к любым методам класса, а не только getter/setter...



Java bean не всегда плохой дизайн, плохой дизайн не всегда java bean.
Вам знакомо понятие data transfer object? 

Наличие setter'ов и getter'ов (в том или ином виде) неизбежно в классах со сложной процедурой инициализации.
Шаблоны factory, builder, inversion of control бессмысленно называть "процедурными извращениями", они неотъемлемая часть мира объектов.

Злосчастный JFrame, которому вы запрещаете иметь get/set Title, ещё один пример, когда объект не должен управлять своим аттрибутом.
Он должен отобразить title в нужном месте окна, но он не может знать какое у него должно быть значение. 

Вы держите в голове тривиальный пример data object'a (попались на этом что ли?) и развиваете целую концепцию о пагубности getter/setter, прибегая при этом к сомнительной терминологии. Это не серьёзно.

------



Модель классов никогда не является моделью объектов реального мира. 
Кстати, вы не считаете случайно геометричекие объекты объектами реального мира? )

Прицип подстановки говорит: B is-a A если в любой программе A можно заменить на B и программа будет работать точно также.
Всё просто и не надо изобретать "свойственность".

Определите операции над классами Point, Size и Square  и тогда можно будет судить о том, правомерно наследование или нет.

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

Поптайтесь-ка вычислить расстояние между двумя произвольными объектами(расстояние - длинна кратчайшего отрезка соединяющего два объекта): 
1. (point, point)
2. (point, square)
3. (square, square)
4. (yyy, xxx) // другие объекты.

Особенно интересен случай 2, и варианты, когда в метод вычислитель будет попадать класс Square приведённый к Point.

Нет, честное слово, очень интересно увидеть "идеалогически" верное решение этой проблемы в вашем исполнении.
Общий каркас, без математики.   

Почему?  

Это просто не нужно в текущих задачах. Кроме того, как я упомянул, я защищаю ОБЩЕПРИНЯТУЮ методику а для того чтобы сбить эту методику с её позиции нужно ВАМ привести аргументы pro.
Т.е. к примеру я прихожу куда-нибудь и говорю, - Солнце крутится вокруг Земли, попробуйте доказать что это не так! Ага, нормально, а аргументы есть? В том плане что никто-же не будет мне доказывать что Земля крутится вокруг Солнца потому-что это проходят в школе с другой стороны мне придется привести кучу доказательств того что Солнце крутится вокруг Земли.

Ну. Ещё квадрат может быть представлен как набор описаний молекул хлорида натрия с детализацией до кварков. И ч0?  

Замечательно. Ну и зачем тогда был нужен этот спор о терминах, бессмысленнный и беспощадный? Неужели вопрос, что нужно понимать под якобы правильным ООП, стоил обсуждения на семи страницах, если правильное ООП оказывается вовсе не эквивалентно правильному дизайну?

ОК. Напишем на знаменах: «Stateful — это наше все». Чем это поможет в реальных задачах идеального мира, где каким-то чудом все программное окружение оказалось выдержано в таком духе?

А эту проблему надо решать строгой типизацией, а не отказом от свойств. Вы предлагаете решить проблему введением черного ящика, который обладает исключительным знанием о назначении своего содержимого. А почему не значение, обладающее структурным (а не identity) равенством, и лишь описывающее, что с ним надо делать, оставляя окончательное решение на откуп пользователю?
В погоне за foolproof дизайном вы теряете расширяемость. 

Несомненно. А вся программа - суть трудноподдающийся учету набор связей. Но, наверное, есть разница между типом, определенным в некоторой библиотеке и стандартным типом? Или двумя библиотечными типами и тремя (или более)? Чем больше свойств - тем больше типов, которые доступны пользователю и должны поддерживаться. А ведь свойства эти при подходе "объект сам управляет своими данными" (см. ниже новой термин) просто не нужны.


Это с Исходников? Там говорится о формате хранения даты внутри класса Date или о самом Date, а не о шаблонах для парсинга или формате хранения в двоичных файлах. Хотя даже если бы речь шла именно об этом, весь код для исправления все равно сосредоточен в календаре, а не в строках или местах, где используются строки. Поясните, что вы имели в виду.


Мне, вам, всем остальным. Про Swing уж не рассказывайте - там этого навалом. Загляните в исходники java.awt.Container. Попробуйте переопределить processEvent() компонента и получить хоть одно событие, не разрешенное в eventMask.


Если вам так удобнее (chain of responsibility) - да. Это естественный шаблон для тех случаев, когда нельзя "залезть" в поля другого класса. И, кстати, почему вы считаете его малоприменимым для GUI?

AWT показал недостатки такого метода кому? Вам? И что же, вы перестали использовать Swing?


А это-то вы мне зачем говорите? Или мне нужно в двадцатый, тридцатый, сотый раз повторить, что я и не думаю осуждать этот подход? Он просто является сомнительным, бедовым с позиций ООП. Вы сразу скажите, сколько раз мне следует написать эту мантру, я копипастом для вас постараюсь набросать.


Наслышан  Я не мечтал, и никогда подобными конструкторами не пользовался.


А кто у вас спрашивает? Расскажите, как вы управитесь с распределением прав на примере JFrame.getState() или JFrame.getExtendedState(). Или на примере отображения размера ящиков в апельсинах.


Истинно не совершенны. Для JavaDoc нужно иметь время со стороны автора, и желание его читать со стороны пользователя. А ввести проверки не получится - свойство получено пользователем объекта, проанализировано, на основании анализа созданы некие классы, вызваны некие методы. Где и что проверять?


Только в том случае, когда кто-то эти методы не очень хорошо продумал. Но в случае с getter+setter - всегда.


Еще и еще раз обдумайте мой вопрос о послания для вас, состоящего из мантр "... я не собираюсь осуждать существующие подходы...". 

Про JFrame. Не нравится слово "управлять" - хорошо, пусть будет "распоряжаться". Титул JFrame может инициалиироваться из чего угодно и сколько угодно раз. Я не говорил, что нужно вообще выкорчевать оттуда этот атрибут. Достаточно удалить метод getTitle().

Не нравится терминология - предложите свою. Обсудим.
И снова напоминаю о мантрах: "я говорю о пагубности только в отношении ООП". Укажите нужное число повторений.


Этот вопрос не по адресу - спросите у Domestic Cat.


Спасибо за более простую формулировку. 


Наиболее очевидное использвание, говорите? Наиболее очевидным было бы решить, что Point содержит пару полей для координат, а Size - поле для размера. Этого достаточно. Наиболее очевидным было бы сказать: "не обязательно этот вариант наследования является верным на все случаи жизни; определите атрибуты и операции, тогда можно будет судить о правомерности наследования". 
НО.
Я только множество раз прочитал различные вариации на тему своей неправоты, но ни разу - попытку оценить эту связку, исходя из наиболее очевидной структуры или попытку уточнить эту самую структуру. Единственное, чего удалось добиться - точка не есть квадрат по букве геометрии, жизненным реалиям и потому, что "я туда такой метод/поле добавлю, что точно сломается". Так что вас можно поздравить - хоть и со второго поста, но вы первым пришли к дельной мысли. Определяем операции:

• Point(int x, int y) - void move(int deltaX, int deltaY)
• Size(int value) - void grow(int delta)
• Square

А вот для вычисления расстояний между объектами и точкой данная модель никак не подойдет из-за необходимости наделить класс Point несвойственным ему методом для поиска координаты, ближайшей к заданной. 

Уважаемый, стандартные операции, которые вы здесь преподносите как откровение - не есть стандартные если мы рассматриваем эти объекты как геометрические. Посмотрите хотя бы на класс Point в Java2D.
Здесь подойдет, тут не подойдет... Извините, но подойдет всегда если не наследовать квадрат от Point. Это не очевидно? Какие свойственно - несвойственно? В геометрии квадрат нельзя заменить словом точка, отсюда и следует что у точки есть методы, несвойственные квадрату и наоборот... "Дельная мысль". 


  Программный продукт в 100% случаев меняется в процессе разработки и саппорта, мало того, к меняются функциональные требования. Потому такой подход неприменим, тк вы не знаете какие требования к вам предъявят завтра. Потому это и не есть ООП - покажите хоть одну солидную книгу где проповедуется подобный подход...  

Тип String самый что не на есть стандартный.
Давайте все return value первратим в объекты типа String  содержащие "нужным" образом отформатированные данные.

Можно обойтись одним единственным типом на все случаи жизни!

Замечаете разницу? Дело не в количестве типов и их принадлежности к стандартным библиотекам, а в том какая им отведена роль в приложении.



Имя пакета java.awt ни на какие мысли не наводит?


И мне в том числе.  AWT уже никто не пользуется добрую сотню лет, пользуются Swing. Судя по последнему вашему вопросу вы не понимаете разницы между AWT и Swing и принятыми в них моделями обработки событий.



Затем, что вы пишите такие вещи, как те, что я выделил болдом.
Что вы собираетесь или не собираетесь делать меня занимает мало.

В java beans нет ничего бредового с позиций ООП. 

Рекомендую познакомиться со спецификациями, задачами и инструментами для их решения живущими вокруг java beans.
http://java.sun.com/products/javabeans/index.jsp

Мантра для медитации: "data object != javabeans".
Повторять до просветления.


С каким "распределением прав", ещё один "новый термин"? 
Повторяю медленно, по буквам.
_Любой_ метод можно использовать не верно. Ничего нового в эту проблему геттеры и сеттеры не вносят.
Медитировать на класс String.


Мне очень интересно было бы узнать, с каких позиций вы рассуждаете об ООП, если вам не знакомы основополагающие понятия связанные с оо-методом?


Ангел мой, что же вы такое говорите? 

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

Для вас не большое пояснение.

При функциональная декомпозиции задача разбивается на подзадачи. Если подзадача оказалась недостаточно проста, процесс разбиения продолжается.
Такой подход безусловно приводит к главное цели - решению конкретной задачи, но при этом есть два существенных недостатка.
Множесто методов созданных для решения задачи _зависит от способа разбиения задачи на подзадачи_, порядок вызвов методов строго регламентирован.
Как следствие, решая родственную задачу, мы не можем использовать уже существующий код. 

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

Что же получается у вас?

Невинное требование приводит к необходимости изменять или даже создавать параллельно новую иерархию классов, хотя данные не изменились: точка осталась точкой, квадрат - квадратом.
Почему? Да потому, что ваши ОО-познания всего лишь набор слов, а на практике всё таже функциональная декомпозиция и наличие у JFrame #getTitle и #setTitle в качестве оправдания.

Кстати, вернёмся к тому, о чём я говорил в первом сообщении.

Решить задачу вычисления расстояния между двумя объектами согласно вашей (новаторской) трактовке ООП нельзя вовсе, чтобы не скатиться к "процедурному коду" (с)w1nd.
Нельзя из-за того, что для решения этой задачи недостаточно информации ни у одного из объектов - они _должны_ взаимодействовать, а это приводит к необходимости выставить наружу данные, которые будут "получены пользователем объекта, проанализированы, на основании анализа будут созданы некие классы" (с)w1nd.   

Это сообщение отредактировал(а) NotGonnaGetUs - 18.5.2006, 14:39

А вас не смущает тот факт, что компоненты Swing - всё те же компоненты AWT? Никто не пользуется   Большая часть событий, поступающих Swing'овым компонентам - события AWT, очередь событий AWT никуда не делась. И способы взаимодействия компонент со времен AWT не изменились и вряд ли изменятся. 


Можно еще ошибаться в названии методов. Правда, компилятор не поймет.

Модератор: Оставляю, чтобы все видели. Будете переходить на личности - будет бан.
Термин? С какой высоты падали? 
Какие понятия? Чьи термины? Не надо выдавать чьи-то формулировки за "общепринятые".  Вы читаете или просто текст распознаёте?


Легко и непринужденно. Ни в чем не отступая от ООП. Да, кстати, укажите слова "процедурному коду", если найдёте. Вы просто НЕ ЧИТАЕТЕ того, что я пишу: "приводит к необходимости выставить наружу данные"  

Да, не утруждайтесь мне разъяснять, что есть ООП, JavaBeans, шаблоны, хороший тон в проектировании. Ваши усилия пропадают зря: вы не сообщите мне ничего нового или интересного, а ваше понимание этих вопросов - это только ваше понимание.


"Бедового". Свойства в JavaBeans противоречат ООП.

    

Это сообщение отредактировал(а) w1nd - 18.5.2006, 20:57

 

Не могу понять, почему вы в этом так уверены. Ну говорилось бы в учебниках по ооп что мол проперти плохо, но нужно идти на компромисс... Ну хоть бы на своем богатом опыте вы заработали подобное знание, чтобы можно было сказать - вот примеры моих ООП приложений, их объектная модель гораздо лучше того, что пишете вы... Но ведь ни то ни другое.