У большинства геом. фигур нету такой точки  

Во-первых, это не совсем так (про иерархию) - вспомните окна, посмотрите, что переопределяет JComponent. В-вторых, очередь событий как раз имеет отношение к тому, куда и как попадает событие. В-третьих, см. java.awt.Component.enableEvents(). В четвертых, на всё, что касается диспетчеризации событий ввода, компоненты Swing никак не влияют. 


"Распоряжается".


Это к тому, что число, возвращаемое этими методами, пользователь JFrame может интерпретировать как угодно.


Я такого (что вы что-то придумали) не говорил. Я говорил о том, что используемые вами термины не могут быть общеизвестными.


Геометрическим центром любой выпуклой фигуры является точка, равноудаленная от её вершин.


Только в случае с параллельной проекцией.


К данным объекта. К членам-данным объекта. Речь все время шла только об этом.



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


Point в данном случае не является классом. Это комплексный тип, в одном ряду с примитивными. 


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

NotGonnaGetUs, чем больше вы высказываетесь (или стараетесь поймать меня на слове, или выдаете за мои слова то, что я не писал), тем больше я убеждаюсь, что вы действительно не понимаете, о чем я пишу. Если вам действительно интересно моё мнение, давайте начнем заново, более предметно. С примера о квадрате и точке - используя принцип Лисков, покажите, что такое наследование неправомерно всегда, вне зависимости от применения

Добавлено @ 18:52 
Про центр объекта: 

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

Добавлено @ 19:02 

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

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

Здесь кто-то уже высказал ключевой момент, что говорить о нарушении LSP имеет смысл только в рамках контракта, который предоставляет пользователям базовый класс, его спецификаций. То есть вне зависимости от применения ничего конкретно сказать нельзя. Я могу представить ситуацию, когда наследование квадрата от точки будет оправданно (и это тоже уже кто-то говорил).
Но решение о наследовании принимается не на основании свойственности данных одного класса другому. DeadSoul привел хороший пример. 

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


В примере, приведенном DeadSoul также говорится о том, что целесообразность модели зависит от применения. И решение о наследовании чего-либо из чего-либо принимается как раз в зависимости от контекста.   

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

Гы, это ж и я говорил. Только вот вы невнимательно читаете оппонентов. Речь ведь (напомню раз в пятый) идет о геометрии, а не о чем-то еще, и именно вы пытаетесь убедить на геометрическом примере что наследовать от точки можно. Кстати, вы уже забыли конкретный же пример с компаниями и контактами.
 

Не понял, в чем я проявил невнимательность? Я всё время подразумеваю, что речь идет о геометрических фигурах. И что с компаниями и контактами? 

См. стр. 1 - в данном случае наследовать квадрат от точки нельзя тк квадрат не есть точка. Какие пояснения еще нужны?   

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

Это сообщение отредактировал(а) w1nd - 21.5.2006, 18:50

Вы собственно чего хотели сейчас сказать? (извините тупого программера, который только и делает, что представляет себе сферических коней, в отличие от Вас - О Великий, Который Знает Истину, за непонимание, однако я действительно Вас не понял). 
Какая вам разница что я себе представляю - коня или сноповязалку?

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

Все. Ждем-с.  

  

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

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

Это сообщение отредактировал(а) w1nd - 21.5.2006, 22:27

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

Возможно. Приведите пример.  

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


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

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

Не хочу окна. 

Вами было высказано следующее:

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

Мною были приведёны в пример Awt и Swing, которые показывают, что свойства ничего подобного _не навязывают_ (В Awt используется событийная модель с chain of responsibility, в Swing основанная на подписке на сообщения (кстати, swing компоненты удовлетворяют спецификациям javabeans на 100%)).

Если вы не согласны с этим утверждением - так и скажите. Сравнение AWT и Swing - это offtopic. 

-----


offtopic, т.к не имеет отношения к свойствам.
Безусловно, вместо int лучше использовать enum (since 1.5).

-----



(Это была шутка...)

Могут и есть.

Да, если спросить сантехника, он не будет знать, что такое принцип подстановки Барбары Лисков, но для людей от computer science, утверждающих о владении ООП, такое не знание непростительно.



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

Н-р, у ромба.


Не так важно, что есть в примере. 

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

Робм - это выпуклый 4-х угольник. 

Обратитесь к определению "выпуклый многоугольник" в учебнике геометрии.

-----

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

В полностью ООП языке не может быть примитивных типов. Их существование не является украшением java.
Н-р, в Eiffel, C# и многих других языках - примитивных типов нет (не путать примитивный тип с константами).

-----


w1nd, я выдаю за ваши слова только то, что вы писали.

Рекомендую вас саму перечитать ещё раз этот топик. Я не поленился, сделал это уже три раза, пытаясь найти что-нибудь здравое среди ваших утверждений.
 
Вам кажется, что вы пишите одно, а вас понимаю неправильно (причём все)?
Так может быть стоит умерить эмоции и попытаться излагать свои мысли чётко и ясно?
Например, не использовать термины в значениях отличающихся от общепринятых (или хотя бы сопровождать их доходчивыми определениями, что бы никому не нужно было за вас додумывать).

-----



Ок, давайте ещё раз, тоже самое.

Пусть у нас есть два класса: А и B.
Согласно LSP, "B" может быть наследником(подтипом) "А", только если _любая_ программа выраженная в терминах "А" останется _корректной_ после замены "А" на "B".
Если это условие выполняется, то можно гарантировать, что существующий код не придётся переписывать при появлении нового наследника класса.

Коротко и красиво, но тут есть подводные камни: что такое _любая_ и как определить _корректность_?

Прежде чем ответить на эти вопросы, посмотрим на следующие классы: 

?

У них абсолютно идентичные интерфейсы и различное поведение. Допустимо ли наследовать B от А?
Правильный ответ: ХЗ (умножить на 3).
Недостаточно знать интерфейс класса и даже его реализацию, чтобы ответить на этот вопрос.
Нужно знать кое-что другое, а именно "контракты" классы (которые в общем случае не могут быть отражены в коде).
Под контрактом понимается набор инвариантов класса и пред-/пост- условия методов.

Если мы скажем: метод A#foo():int вычисляет произвольную функцию от х:int, то наследование уместно (все узнали strategy?),
если мы решим, что этот метод должен возвращать значение линейной функции от x, то наследование невозможно.

Вернёмся к LSP. _Любая_ программа будет работать _корректно_ тогда и только тогда, когда класс B реализует контракты класса А.
"Свобода" B заключается в возможности добавить новую функциональность к классу А, ослабить пред- или ужесточить пост- условия его методов.
 
В реальной жизни далеко не всегда контракты описываются явно (ввиде javaDoc's, examples, etc), но мы, как истиные джедаи сделаем вид, что такой код нами не пишется.

Итак, у нас есть критерий позволяющий определить, допустимо наследование (с точки зрения сохранения функционирования существующего кода) или нет.

Является ли этот критерий необходимым и достаточным для того, чтобы применить наследование?
На самом деле нет. Это только необходимое условие. Всегда есть вероятность, что потребуется добавить в класс (А) новую функциональность, будет ли она иметь смысл для наследников?
Если наследники не смогут её реализовать, то придётся изменить всю иерархию наследование и весь код, который с ней работал или создать параллельно новую иерархию, а это ОЧЕНЬ трудоёмкий процесс (Не забываем, что джедаи абсолютно не приемлют костыли в виде instanceOf и классов нарушающих контракты родителей).

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

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

Вернёмся к квадратам и точкам.

Для решения какой задачи нам могут потребоватся классы Point и Square? Первое, что приходит в голову: "что-то связанное с геометрией".
Затем в игру вступает мозжечёк (ещё до того, как изучен интерфейс этих классов): как же так? "квадрат" не является "точкой", он только содержит "точки"!

"Не является" для джедая значит, что найдутся методы имеющие смысл для Point, но лишённые смысла для квадрата. 

Какие контраргументы приводите вы? 

1) В квадрате (геометрическом объекте) _содержится_ некая точка, с которой можно связать класс, от которого наследуется квадрат (геометрический объект).

2) "Заморозив" классы Point и Square в текущем виде, можно добиться выполнения LSP (отказавшись тем самым от будущих модификаций).

Ответы.

1) Это тоже самое, как наследовать человека от его левой руки, вместо того, чтобы использовать композицию.
Получаем сильную связь между классами рука / человек + слабое зацепление между методами класса человек.
Такие конструкции очень трудно поддерживать.
Н-р: как быть в случае приведения типов (Point p = new Square(), p.draw())?
Как быстро ответить на вопрос, кому принадлежит конкретный метод класса (square.rotate() - rotate точку вокруг центра координат или квадрат вокруг центра симметрии?)?. 

2) Заморозка противоречит стремлению создавать простой для модификации и расширения код. Если отказаться от этой цели, 
то можно и не городить огород с ООП, а обойтись функциональной декомпозицией и любым процедурным языком. 


Что в этих рассуждениях вызывает вопросы?




 

Можно допустить что такая ситуация возможна, но пример неочевиден и к геометрии имеет весьма отдаленное отношение. 



См здесь