Раз уж мы заговорили о доказательствах, то наличие множественного наследования в С++, еще не означает что это единственно верный путь. У него есть свои недостатки.
А пример, ООП без множественного наследования это таже Java и C#. И пока я так и не понял, почему квадрат, в хорошо споектированной программе обязательно должна наследоваться от точки и размера. 

Позволю себе дать ссылку на подобное обсуждение о вреде/пользе МН на RSDN. 

Не обязательно должен. Domestic Cat нашел данный пример странным; я утверждаю, что странного (или плохого) в этом ничего нет. И еще я считаю подход со свойствами неуместным в ООП.

Что касается Java или C#, то они появились попозже ООП, да и ООП, в принципе, оторвано от какого-либо конкретного языка (хотя C++ создавался в т. ч. и как инструмент для ООП). Я говорю о том, что без МН в ООП не обойтись. Может быть, утрирую, но все равно обойтись бывает очень трудно (не вообще обойтись трудно, а чтобы не скатиться в структурное программирование).

    

Это сообщение отредактировал(а) w1nd - 13.5.2006, 04:48

Ну а я утверждаю что это неправильный пример наследования, неважно, множественного или не множественного. По определению наследования.



Обойтись можно, как показывает опыт. 

Ну так приведи пример, когда обойтись трудно.

Да и по поводу properties, я слышу только что это не ООП, но не вижу аргументов. Объясни например почему класс JFrame не должен предоставлять возможность управления своими размерами в виде setSize() и getSize(), где тут нарушение ООП парадигмы. 

 

Чего я не понял, это почему Domestic Cat привязался вначале к квадрату из кординаты и размера? откуда вы знаете где и как такая структура классов будет использоваться? Это вполне может быть крайне удобным и логичным в рамках задачи для которой это проектировалось. Вполне понятно, что одни и те же "объекты реального мира" можно описать различными способами и с чего вы взяли что какой-то способ лучше а какой-то хуже? все зависит от того где и как вы будете результаты своего проектирования применять. 

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

Как раз не по определению. Вы просто пытаетесь сравнить геометрические точку и квадрат и находите существенное различие (хотя и то и другое - объект на плоскости). А в случае с классами отношение is-a никогда не определяет точно такое же отношение между объектами реального мира. Поля и методы точки свойственны (или применимы, если хотите) квадрату, значит он - точка. Потому что в определении класса ничего другого, кроме полей и методов не написать.

Конечно можно! Как правило, путем отказа от парадигм ООП.

Вы сами отвечаете на свой вопрос. Класс не должен предоставлять возможности управлять своими атрибутами. Разницы между методами getSize/setSize и публичным полем size нет. Создание таких свойств - это структурное программирование, а не объектное. Не должно быть у класса никаких доступных полей данных, пусть даже getSize двадцать раз конвертирует результат. Мы можем послать объекту сообщение (вызвать метод): "сделай что-то", но никогда не можем запросить у объекта данные.  

А сие кстати, верно...  В Java нет структур, вот почему мы вынуждены пользоваться нарушением идий теоритического ОО проектирования под названием JavaBean.   если вам нужно хранилище данных, то вам не нужен класс. класс он должен что-то "делать" а не просто предоставлять и получать данные в различной форме.   Вот тепярь я понял в чем прелесть структур в С++... это не классы, это полностью публичные хранилища данных (причем методы у них тоже есть так что работу по преобразованию данных можно тут же и запрограммировать) и то что это не классы подчеркиваеться на уровне синтаксиса языка. хмм... 

Программирование - это все-таки описание реального мира, а не наоборот. Потому утверждение "у классов А и Б одинаковые поля, плюс у класса Б есть все методы класса А" не означает, что Б должен наследовать от А. is-a  соотношение определяется из логики реальной задачи, из того, что это значит в данном контексте. Вы забываете, что наследование также называется generalization - обобщение, базовый класс - это абстракция более высокого уровня, которым можно в некоторых случаях заменить любой из сабклассов (Vehicle <- Car, вместо "машина" можно использовать "средство передвижения" в случае например подсчета всех средств передвижения компании). Если рассмотреть геометрию, то квадрат не есть точка, в геометрии нельзя квадрат заменить точкой. Если угодно реюзать код - например координаты, выстроите правильную иерархию наследования. Например можно ввести понятие GeometricObject. Понятно, что любое геом тело будет включать в себя хотя бы одну точку (квадрат - одна из вершин, круг - центр, линия - одна из двух точек, определяющих линию, итп) и дайте этому классу два поля - x и y. Вот теперь наследуйте от него Point, Rectangle и все остальное, и теперь данная иерархия будет правильной, так как точка есть геометрический объект и квадрат также есть геом объект. 



1. Предположим, мне нужно узнать размер квадрата, чтобы где-нибудь в статус баре написать "квадрат стороной 10 мм". Как вы это реализуете?
2. Где написано, что у объекта нельзя запрашивать данные? Инкапсуляция означает не то, что объект должен скрывать всё на свете, а то, что он должен скрывать имплементацию. Проперти как раз идеально ложится в данное определение - не важно откуда объект берет свое свойство - из базы, считает, или просто хранит в виде поля. Более того, проперти (геттер, сеттер если хотите) - это тоже message, то есть то же самое, что и метод. В чем принципиальная разница между мессагами "верни мне массив твоих координат" и "верни мне твою площадь"?
    

экземпляр_класса_квадрат.отобразить_свой_размер_в_статус_баре().

Доступ к данным должен быть невозможен. Что вы будете делать, когда сам тип этого свойства поменяется? Или вместо одного свойства потребуется десять?

Да ни в чем. Ни то, ни другое не нужно. От объекта нужен только функционал. Для чего его координаты или площадь? Где-нибудь нарисовать? Это сделает сам объект. 


Только в том случае, когда мне где-либо понадобится этот GeometricObject (кстати, в честь чего у абстрактного геометрического объекта будут координаты? координаты начинаются с точки). Делать его только чтобы был не имеет смысла - это только запутает. Я как раз не забываю, что означает наследование, но я, проектируя структуру классов, не собираюсь следовать примерам из реального мира. Мой реальный мир - это моя программа, здесь всё по-другому. 

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

З. Ы. У любого геометрического объекта, между прочим, есть центр, а у точки отсутствует размер, поэтому любой объект - суть точка.

              

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

  А откуда экземпляр_класса_квадрат узнает о статус баре? А если необходимо не только в статус баре, а еще в 30 разлиных элементах, то придется еще 30 методов реализовывать: экземпляр_класса_квадрат.отобразить_свой_размер_в_объект1() ... экземпляр_класса_квадрат.отобразить_свой_размер_в_объект30() ??   

Это сообщение отредактировал(а) MoonCat - 13.5.2006, 20:35

А вы что думали?  Объектно-ориентированный подход фактически является вывернутым наизнанку в сравнении со структурным. 

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

Кстати, без МН или интерфейсов Java в этом случае придется очень туго, так как все 30 компонент уже имеют какого-то родителя. Но интерфейсы Java отличаются тем, что реюзать код не получится (или получится, но очень через задницу - через статические методы в непубличном классе).  

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

Оффтоп: понятия "центр" у любого геом объекта нет. То, что любой геом объект есть точка - с чего это вы взяли?



А что, если я хочу отобразить название красным цветом? Курсивом? Использовать буквы разной ширины и цвета?  А что, если мне нужно размеры квадрата вывести в виде (x1, y1, x2, y2,  размер), а Васе Пупкину - в виде "Квадрат имеет длину 5 "? А что, если мне нужно создать кристал репорт по размерам всех квадратов, Пете - создать ворд документ, а Ване - послать размеры на мыло? 

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

 

Да нет уж, это ваш подход вывернут наизнанку.

Да. Любой программист поймет этот код, также, как понимает Java или дотнет фреймворк. А вот наследование квадрата от точки - врядли.



Для чего угодно - см выше

Кто это сказал?