Совершенно согласен с фразой:



Спасибо. 
Ванкувер? Жаль так там и не побывал.  

[quot w1nd]
Подведём итог. Изначальный вопрос - что может быть странного (или непонятного) в примере наследования квадрата от точки - так и остался без ответа  Разумеется, это была чистой воды провокация; мне самому чье-либо мнение по затронутым в теме вопросам... как бы это сказать... не очень интересно. Что ж, некоторые собеседники (не буду указывать пальцем) выявили непонимание идеологии ООП (точнее выражаться не буду).
[/quot]

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

Если последовательно провести вашу линию в жизнь, то окажется, что правильнаяя ОО программа должна состоять ровно из одного класса.
В самом деле, вернёмся к вашему решению об отображении размеров квадрата в статусБаре.
Почему вы решили, что квадрат должен говорить статусБару, что тот должен отображать?!
Чем СтатусБар хуже? Сделаем в нём метод showКвадрат(квадрат:Квадрат).
Чтобы сильно не мучаться соберём статусБар и квадрат в один класс. 
Полное сокрытие данных! Идилия!

Кстати о наследовании...
Мейер выделяет 12++ форм наследования, начиная от наследования интерфейса и заканчивая наследованием реализации.
Далеко не все из этих форм наследования доступны в ОО языках.  
Попытка наследовать класс квадрат от класса точка - это пример наследования реализации.
Наследуется не поведение (квадрат _всегда_ ведёт себя как точка), а какие-то языковые конструкции.
Так же точно можно наследовать: 



Тоже хотите задать вопрос  "что может быть странного" в этом примере?


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

Рекомендую к чтению не книжки безымянных программистов на С, а что-нибудь из нижеследующих:
http://www.ozon.ru/context/detail/id/2336754/  - что такое ОО метод
http://www.ozon.ru/context/detail/id/1048352/  - что такое ОО дизайн
http://www.ozon.ru/context/detail/id/1616782/  - немножко реальных задач
 

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

З. Ы. Да, и кто такой Мейер? Всего лишь безвестный основатель EiffelSoft, хех. 

З. З. Ы. Еще и два плюса за этот бред получили    

Это сообщение отредактировал(а) w1nd - 16.5.2006, 17:00

Если честно, то то, что вы здесь высказали - бессвязные мысли, даже не оформленные во что либо законченное (хотя бы в код что ли) - не знаю как и назвать... Если просто покричать охота - вам не сюда. Потрудитесь вести спор нормально, а не кричать "бред" не отвечая по существу. 
Это предупреждение. 

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

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

Не увидел никакой чепухи, в данной теме вы именно это и утверждали. Если считаете, что ва неправильно поняли - уточните, в чем.  

А я считаю, что в учебе скромность и отсутствие мании величие тоже немаловажный фактор.

А можно по пунктам и с цитатами? Просто видишь-ли, дело в том что теория ООП используется на практике и большинство людей согласны с тем что данные которые надо открыть -- надо открывать, ибо в этом случае данные представляют собой интерфейс.
Ты же, пытаешься посягнуть на фундаментальное. Ок, ноу проблем, никто не сдерживает так сказать, "полёт мысли" и абстрактное мышление. Но будь добр доказать что ты прав.


(пошёл наследовать класс XML ноды от точки) 

w1nd, два вопроса:
Совместима ли статическая типизация с «хорошим ООП»?
Являются ли примитивные типы нарушением принципов «хорошего ООП»? 

Тут возникло предложение позвонить в Sun Microsystems и попросить заменить класс Object на класс Point ...    
Теперь все от точки наследовать будем!!!       

Ну хорошо, предположим что в существующих GUI фреймворках не соблюдаются ООП принципы, и комбинировать эти два подхода не выгодно. Хотя не совсем понятно как получается что:

при этом если взять, что Java, что .NET там почти все построено на концепции properties, а:


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

Я тоже так считал. Когда учился.


Назовите свои pro et contra. Пока один лишь Domestic Cat возразил по существу, говоря, что квадрат в реальном мире не может быть представлен, как точка (хоть он в этом и не прав).


Ну а я утверждаю, что подобного не писал  Процитируйте что-нибудь, будте так любезны. Да, и, развивая тему, разъясните мне, что это было:К слову, разъясните мне так же, как все мирятся с вопиющим фактом наследования классов вроде AbstractAction из класса Object. Исходя из верований всех отметившихся, класс Object может быть родителем AbstractAction только в том случае, если будет переименован в Something или что-то в этом духе.

Добавлено @ 23:28 

Да. Нет. 
Что вы хотели сказать?

Добавлено @ 23:34 

Не из одних properties все они состоят. Под фрагментами я имел в виду кусок модели классов, способы взаимодействия отдельных классов и прочие подобные детали.
Что касается последнего вопроса - да, безусловно. Что из этого следует?  

Это сообщение отредактировал(а) w1nd - 16.5.2006, 23:38

Конечно, но без них они не смогут существовать. Подавляющее большинство взаимодействия мужду объектами идет посредством properties.


И они были написаны в соответсвии с твоими представлениями об ООП? 

Я пытаюсь уяснить для себя ваше понимание ООП.

Если убрать из ваших постов излишний апломб и некорректные примеры, я с вами даже соглашусь по большей части. (Впрочем, вполне вероятно, что я вас опять неправильно понял, и вы меня быстро заставите изменить свое мнение).
Вы утверждали, что getters/setters и свойства нарушают инкапсуляцию и создают излишние связи между объектами. Но четкая граница между getter и посылкой сообщения «скажи мне какую-то свою характеристику» объекту так и не была проведена.
Свойство может скрывать сколь угодно сложную логику. Если нет прямого соответствия между значением свойства и каким-либо полем класса, если оно возвращает нечто вычисляемое, существенную информацию об объекте — оно не противоречит ООП и является синтаксическим сахаром над нотацией метода/пары методов, не так ли? (Если не так, я уж и не знаю, что сказать).
Но есть объекты, информация, содержащаяся в полях которых, составляет часть публичного интерфейса. Например, возьмем класс… нет, лучше интерфейс коллекции. Коллекция должна предоставлять метод для перебора своего содержимого — это ее наиболее существенное качество. Но можем ли мы отказать в существовании свойству или getter'у, который будет возвращать число элементов, содержащихся в коллекции? А ведь это тело этого свойства, скорее всего, будет состоять всего лишь из возврата значения поля.
Вы сказали, что примтивным типам не место в ООП. Но так или иначе, без типов, соответствующих, к примеру, множеству целых чисел, не обойтись. Значит, нужны классы, обладающие поведением целых чисел. А они-то как общаться будут с окружающим миром, не выпадая из рамок ООП?


А вам не кажется, что при таком подходе количество излишних связей только возрастает? Ведь теперь класс квадрата обязан знать обо всех типах объектов, в которых ему надо отобразить свой размер. Или введем еще интерфейс нечто_в_чем_можно_отобразить_размер_квадрата?


А кто сказал, что отказ от парадигмы ООП — это непременно плохо? Не будьте догматиком. Цель проектирования — не следование парадигмам ООП (которые всяк норовит истолковать по-своему), а повышение уровня абстракции. Так что дело не в «недостаточной объектно-ориентированности» существующих фреймворков, а в том, что так называемое «чистое ООП» не является универсальным подходом. Говоря формальным языком, полностью stateful модель точно так же не всегда подходит для описания предметной области, как и полностью stateless. 

Речь шла (как я понял и на чем делал упор) о геометрии, а не вообще квадрате в любом контексте. И в этом случае подобное наследование ничем не лучше приведенных NotGonnaGetUs примеров. 

Относительно наследования вы утверждали что
1. Квадрат нужно наследовать от точки, тк у квадрата есть те же поля что и у точки
2. Пример номер два: наследовать квадрат от Size
3. Пример номер 3: Company можно наследовать от Contact.
Может вы этого не писали?