Модератор: Вынесено из 5 основных отличий между Java и C++ 



Вместо примера кода классический пример из книжек: класс Point, класс Size обладают некоторыми полями и методами, класс Square их наследник и в то же время и Point, и Size. К сожалению, на Java этого номально не сделать. Так же нельзя сделать гуишный компонент для ввода строки наследником строки.  

Оффтоп: 

Какие-то странные примеры наследования. У автора книжки с ООП было явно туговато.  

Первый пример есть во всех книжках по ООП. А в чем странность? 

В том, что наследовать Square от Point и Size нельзя - квадрат не есть точка и никак не размер. Впервые такой пример встречаю просто. 

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

Наследование - это отношение is-a, вот и все.


http://en.wikipedia.org/wiki/Inheritance_%...uter_science%29

Наследовать квадрат от неправильно, тк квадрат не есть точка, тем более не "размер".   

Именно так. Но вы (как и многие) допускаете распространенную ошибку - отождествляете эти классы с объектами реального мира. Для квадрата свойственны все поля и методы координаты и размера - именно это (все поля и методы) определяет наличие отношения is-a для классов.    

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

Простой пример:




ООП и постоено на объектах реального мира, просто в каждой ситуации програмист рассматривает лишь отдельные стороны объектов, важные в данной ситуации. С точки зрения геометрии квадрат не есть точка. Да, он унаследует два поля точки, но за выигрыш двух строк кода придется платить - например, можно будет откастить объект квадрата к объекту точки или размера, что будет приводить к появлению багов, непонятному коду. К примеру, у точки есть метод Paint, который мы перегружаем в Square. Тогда метод DrawPoint(Point point) приведет к изображению не точки, а квадрата при вызове DrawPoint(square). 
Согласно такой логике мне нужно наследовать класс Company от класса Contact, поскольку последний содержит все поля (адрес, имя, телефон, емейл, итп). К чему такой наследование приведет нетрудно догадаться. 
 

ООП построено не на объектах реального мира, а на принципе инкапсуляции и полиморфизма .

Само существование методов вроде DrawPoint или CreatePolygon полностью противоречит принципам ООП. Только сам объект может себя рисовать или создавать. И если бы класс Контакт не обладает атрибутом Пол или Возраст, он подойдет для Компании; в ином случае нужно просто выделить общие для них поля и методы в отдельный(е) класс(ы) и назвать соответствующе.   

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

Замените DrawPoint на метод Point.Paint, и проблема останется. CreatePolygon вполне может относиться к классу, занимающемуся проецированием полигонов из 3D на экран, тогда полигон сам себя прорисовать не сможет, так как ему будет необходимо знать ряд других параметров, возможно, выполнить к-л оптимизации при прорисовке, итп.


Предположим, что пол и возраст не важен и мы унаследовали Company от Contact. Бизнес-логика приложения очень сложная, где-то я по ошибке передал Company в метод, ожидающий Contact. На дебаге я потрачу раз в 30 больше времени, чем если бы я потратил 2 минуты на создание общего класса Entity. 

Какая проблема? Проблема здесь только в том, что пользователь класса Point хочет знать, каким образом этот класс себя нарисует, а знать ему (пользователю) этого не положено.

И снова я вижу грубое нарушение принципа инкапсуляции. Если полигон не может, следует либо расширять функционал полигона, либо расширять функционал канвы (преобразования, оптимизации и прочее).


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

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

Да какая угодно. Например, создается репорт, содержащий к-л статистику по посещениям сайта (скажем, Контакт/Компания содержат поля MonthlyHits и IP). В данный метод передается массив Контактов, в который по ошибке попала одна Компания. У всех этих объектов вызывается проперти MonthlyHits, IP. Такой баг и заметить сложно. 

Мы про ООП или про что? Инкапсуляция подразумевает не сокрытие информации (это как самоцель не имеет смысла), а сокрытие способа хранения, реализации, взаимодействия. Это необходимо для того, чтобы не переписывать клиентский код при внесении изменений в реализацию класса. Геттеры/сеттеры - это как раз нарушение инкапсуляции (замаскированный прием структурного программирования). Вообще (как я и говорил, вы, похоже, зацикливаетесь на существующих framework'ах, которые примером ООП не являются), само по себе понятие properties объекта очень сомнительно с точки зрения ООП.


Какой-то неподходящий пример. Здесь иллюстрируется только ошибочность решения наследовать компанию из контакта, т. к. в нем есть малоподходящие компании атрибуты (MonthlyHits, IP). Но пусть это неотъемлемые атрибуты любой компании, при чем здесь наследование? Подобную ошибку с таким же успехом можно допустить где угодно: можно создать метод, принимающий в качестве параметров массив объектов и напихать туда чего попадет. 

Чует мое сердце, что для этого нужно наследование, а не инкапсуляция...  

1. Что же тогда по твоему хороший пример?
2. Чем properties плохи (то что при их использовании  можно спокойно менять способ хранения данных, я тебе уже демонстрировал)? 

Я немного неясно написал, предполагается что проперти MonthlyHits, IP могут быть как у компаний, так и клиентов. Тем не менее, пример это подходящий - ошибок можно было бы избежать, если бы Contact и Company наследовали бы от Entity. Тогда в массив Contac[] объект Company никак бы попасть не смог.


По-прежнему не вижу нарушения инкапсуляции. Объект часть своих свойств может скрывать, часть - предоставлять через методы/проперти. Если например класс Point не будет иметь методов getX, getY, то использовать его будет неудобно - для всех возможных применений класса придется создавать свой метод, меняя класс. Реюзать такой класс будет еще труднее, поскольку невозможно предусмотреть все возможные варианты использования Point. 


Существующие фрейворки, хоть и не на 100%, но по крайней мере процентов на 90 меня устраивают. Наследование Company от Contact или Square от Size - не устраивает на 100%, я легко могу представить как сложно поддерживать такой код. 
 

Имхо, это скорее способ стандартизации работы с полями (свойствами) классов. 
 

Так ведь не знаю! Вот и хочу узнать, в каком случае решение о наследовании одного класса из другого (при условии, что все поля и методы родителя свойственны дитю) может быть ошибочным?
   

Заключение о том, что поля/методы класса А свойственны и классу Б должно следовать из логических соображений, из архитектуры, а не из сравнения (все поля класса Size есть и у Square и у Car, следовательно унаследуем Square и Car от Size). Что будет, позже, когда код написан, придется изменить класс SIze и дописать метод Resize()? Не получится ли, что размеры Car можно менять как угодно? Базовый класс должен быть абстракцией более высокого уровня, чем сабкласс (Entity - абстракция от Company и Contact).  

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


А я вот не могу представить трудностей, которые представляете вы. Поделитесь?   

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

Тот, кто пишет метод Process(Entity entity), знает, что в данный метод можно передать любую Entity. Если будет нужно создать метод, специфичный для контактов (Process(Contact contact)), то передать туда Company будет нельзя.
 

1. Непонятный код. К примеру, можно будет спокойно писать 

2. Плохой код. К примеру, добавление нового метода или поля в контакт (например, пол) через полгода после старта проекта приведет к появлению компаний женского и мужского полу.
3. Больше багов
 

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

Добавлено @ 22:44 

Гут!   

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

Один мой товарищ, например, считает, что возможность переопределения операций в C++ - зло, которого следует избегать любой ценой. В чем здесь прикол? У него просто нет нормальной IDE, а C++ он знает недостаточно хорошо, чтобы отследить все зависимости без IDE. А другой мой товарищ вообще не знаком с программированием и нифига не понимает во всех этих кракозяблах. Так что, программировать нужно так, чтобы все одобряли и понимали? Не смешно ли?

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

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

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

Кто тебе это сказал      


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


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

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

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

Целью разработки каких-либо моделей или фреймворков никогда не становится упрощение, только ускорение.      

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

Да ладно 
Spring Framework значительно упрощает разработку
 

Конечно. В команде когда-нибудь работал? Занимался переписыванием кода после индусов? 



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




Упрощение - тоже ускорение, оно ускоряет дебаг и поддержку кода.
 

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

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

Изначально вопрос состоял в том, может ли ООП обойтись без множественного наследования. Я утверждал, что не может и пока не никто не смог предъявить сколько-нибудь весомых аргументов против (кроме утверждений о том, что кто-то потеряет голову, глядя на классы с N-надцатью родителями). 

 

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

[OFF] MoonCat, Daily WTF: там этого добра навалом  

Раз уж мы заговорили о доказательствах, то наличие множественного наследования в С++, еще не означает что это единственно верный путь. У него есть свои недостатки.
А пример, ООП без множественного наследования это таже 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 или дотнет фреймворк. А вот наследование квадрата от точки - врядли.



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

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

 

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


Ты прекрастно знаешь что методы getSize/setSize и публичное поле size, это две большие разницы. Т.к. методы, помимо изменения внутреннего поля size (кстати, ты можешь сходу сказать в каком виде оно храниться?) еще и вызывает перекомпоновку дочерних элементов и перересовку нужных компонентов.
Ты считаешь что для того чтобы получить размер JFrame надо вызывать не getSize() а gimmeYourSizeMan(), а для изменения размера heySetYourSizeBitch(). И это будет являть собой истинно ООП подход?
Или ты вообще уверен, что нефиг программисту знать, или тем более управлять размерами JFrame. Не его ума это дело, разработчик JFrame лучше знает какого размера должно быть окно 

P.S. У тебя дико странный взгляд на программирование. Все существующее ты отвергаешь, но при этом не предлагаешь ничего удобоваримого взамен. Предлагаю тебе в качестве примера, набросать иерархию классов, для описания геометрических объектов на плоскости. А то вообще не понятно, как ты предлагаешь писать код с таким подходом. 

Эк вас занесло... У любого объекта есть геометрический центр. А еще есть центр тяжести. Думаю, еще какие-нибудь центры имеются. А считать точкой объект или не считать - зависит исключительно от удаленности наблюдателя. Город на карте - всего лишь точка. 

Понадобиться может что угодно, но получите вы только то, что может сделать объект.

Не мой, извините, я в соавторах ООП не числюсь. И прошу внимательно перечесть - по сравнению с чем.

Перефразирую ваше утверждение: любой поймет, что я имел в виду написав "1+1-1+1=2" вместо "1+1=2" или "2=2".

Вообще-то это имеет какое-то отношение к инкапсуляции, и говорят об этом все авторы, пишущие об ООП. 

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

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

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

Это вы так считаете (и откуда в вас такая уверенность - ума не приложу). Я же (в данном случае) считаю, что пользователю окна (в случае ООП) не нужно знать, какой у него размер.


Ух! Это высказывание породило ряд вопросов:
Во-первых, куда уж больше примеров? Во-вторых, скажите пожалуйста, что существующее я отвергаю (для меня это полная неожиданность)? В-третьих, что вы знаете о моих взглядах на программирование (здесь я еще ничего об этом не писал, мы пока обсуждаем наследование в теоретической ООП-программе)? 

Есть ли понятие "геометрический центр"?


Мы говорим о геометрии, а не о географии. Найдите мне в хоть одном учебнике слова о том, что любой объект есть точка.


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

Перечитайте пожалуйста определение инкапсуляции. 
Инкапсуляция за 3 минуты



И что? Если для данного объекта допустимо предоставлять доступ к полю, то на здоровье, в чем проблема? Важно, чтобы объект скрывал те поля и те методы, которые нужно скрывать.



В ходе беседы лично у меня складывается впечатление (прошу заранее извинить если не прав) что у вас очень мало или вообще нет опыта работы в серьезных или даже средних проектах. Попытаюсь объяснить. Возьмем часть реального веб приложения - страница, на которой отображаются некие данные. Данные эти читаются из базы в классы-мапперы типа Person, Project, итп, всего штук 15 классов. Задача состоит в том, чтобы иметь возможность сохранять страницу в виде xml файла. 
Будем действовать согласно вашему подходу. Нельзя нам дать классам пропертя типа Name, Id и проч! Что ж делать? Унаследуемся от класса, который умеет сохранять все в xml? Можно, только проблемка то в том, что этот класс будет абстрактным, тк доступа-то у базового класса к полям всех возможных сабклассов нет! Следующий наш шаг - оверрайдить метод WriteToXML и писать 15 методов в 15ти классах...
Через три месяца клиет вам сообщит, что он хотел бы иметь возможность экспортировать не в xml (нахрена ему xml?) а в WordML, PDF и аутлук. И что теперь? Убиваем все 15 методов, наследуемся еще от 3х классов и создаем 45 методов? Классный подход, совсем нетрудоемкий. Кстати, если захотите реюзать в других проектах - не получится, кроме как копипастингом.
А теперь допустим, что мы таки предоставили доступ к полям наших 15 классов. Теперь мы спокойно напишем класс Exporter, унаследуем от него XMLExporter, который будет брать у объекта Provider массив значений. Веб-страница будет выступать таким провайдером, собирая нужные данные с объектов, которые она отображает. Теперь для того, чтобы добавить экспорт в WordML, нужно дописать один-единственный класс с одним методом. И все. Более того, все эти экспортеры можно поместить в отдельную либу и юзать где угодно.
По-вашему, данный подход - неправильный? А по-моему, неправилен именно  ваш - просто вы его даже в реальных проектах не опробовали. 

Каждый объект имеет некое назначение, то как его предполагается использовать. И если прикладному программисту для корректного использования компонента, т.е. такого как предполагал разработчик компонента, нужно иметь доступ к данным делающим возможным обход криптозащиты, то эти данные должны быть предоставлены. И между прочим так и есть, разработчики ОС имеют доступ к таким данным, другое дело что только они. Сторонние программисты, доступа к этим данным не имеют, поскольку не предполагается что им эти данные нужны и даже наоборот, считается что эти данные им не нужны. Тут у нас 2 интерфейса, один для разработчиков ядра, другой для прикладных программистов.



А то что благодаря этому выполняется куча дополнительных действий, делающих возможным нормальное функционирование компонента, это по твоему не важно?
Хотя учитывая, что:

то тогда это все напоминает смертельный номер: "Внимание, только у нас и только сегодня! Написание GUI без использования методов getSize()/setSize()! И на последок, сложный акробатический трюк, написание прграммы без использования статических методов!"
А уверенность такая у меня от этой беседы и от этой.



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

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



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

P.S. Ты С++ случайно не у Гостева в МИЭМ-е учился? 

А что вы мне тычете в нос википедией? Это все равно что на собрание сочинений Васи Пупкина ссылаться  Геометрический центр - это точка равноудаленная от границ (или вершин, не помню) выпуклой фигуры.


Вот уж никак не география. Проекция объекта вся уместилась между двумя координатами. И учебники здесь не при чем, просто постановки задачек вспомните: из точки А в точку Б...  


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


Перечитал. Готов подписаться почти под каждым словом. А дело-то в чем?


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


Я тоже пару раз совершал такую ошибку, так что извиняю  

То, что вы иллюстрируете не имеет ничего общего с тем, что я предлагал. Предположение о методе на каждый вид обмена - ваше, я же привел иной пример (в ответ MoonCat). 

Да, я ни разу не опробовал данный подход в реальных проектах. Но (и я об этом уже говорил, по-моему) ООП практически невозможно внедрить частично в структурно-ориентированный проект. Кстати, тот пример который вы мне приводили (про свойства) и есть попытка такого смешивания. Вот я и не пытаюсь. И еще очень ограничивает отсутствие МН (я ведь давно программлю только на Java). Но и это еще не все причины. Я считаю безусловным злом попытки внедрить какие-то новые подходы в устоявшуюся систему/фреймворк. Поэтому в структурно-ориентированной среде я практикую структурный подход. А в процедурно-орентированной ни за что не буду внедрять объекты. 

Интересно, и где будет геометрический центр у произвольного полигона или прямой?


Повторю: где написано что любой геом объек есть точка?



Вот в чем: 



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

квадрат вырождается (да и круг и прочая плоская и nD геометрия) при нектором соотношении его Size (которое во превых далеко не всегда всего 2 размера, и которое можно кстати и не наследовать вооще) и расстояния до оного. т.е. в принципе может. просто вопрос насколько велика модель, где составными частями являются точка и квдрат ... я прав если это попытка описания 3D граф. движка  - а вот если попытка описания мироздания, или хотя-бы конструкторско-натурной модели ракетного двигателя, каким-бы он крупным не был состоя из каких-бы не было мелких деталей  (ба! даже не не надодо Белый свет описывать  ) - я уже не прав. Но в последнем случае - уже глупо описывать квадраты и курги, сферы и прочее при другом уровне детализации - атомарном, т.к. модели это попросту не нужно, т.к. благодаря Человечеству модель уже кое что знает о более глубоком уровне детализации (предпологается что разработчик - так-же ) - остается вопрос как этим всем воспользоваться..
Так что ООП, то ООП, и про наследование можно много говорить, но лучше изначально задуматься а для чего все это - где (предметно) ООП собрались применять ... а? т.к. ответы на все вообщем-то базовые моменты давно и хорошо изложенны в разнообразной литературе, есть и сранения и анализ математических и аналитеческих умов ...
хотя конечно пытливые умы всегда стявят под вопрос все. и это наверняка правильно.
(я скорее не к Вам, а к Вашему оппоненту и вообще обо всем этом споре).


 

До этого мы говорили только о пользователе объекта, т. е. о прикладном программисте.


Это к чему написано? Если вам нечего возразить по-существу, зачем писать нелепицу?


Между строк вычитали? Или на HTML-тэгах гадали? Там о вашем эктравагантном видении ни слова.


Концепцию я как раз предложил, вы же, похоже, ожидаете примеров кода. Примеры кода я писать не буду - в этом нет необходимости. А конструктивной критики с вашей стороны пока не было.


Религия. Идеология, которая приносит свои плоды. Если вам удобен структурный подход - кто спорит, пользуйтесь, только не нужно мешать мух с котлетами.

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


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


Нет, в МИЭМе я не обучался. Да и вообще, ВУЗы программированию обучать пока не в состоянии (учить некому). Но это к слову, не нужно отвечать на эту реплику.

З. Ы. LSD, у меня возникло впечатление, что вы отвечаете только с тем, чтобы оставить за собой последнее слово. Побольше конструктивизма, а?

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

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


А что, простая логика вам не помогает принять это утверждение? Много где писано, много где сказано - я что, справочник что ли?


Это первая из двух связей. Вопрос в том, нужна ли вторая.   

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

Господа-Товарищи, а можете привести реальный пример кода идеальной ОО программки(не большой)? Так будет интересней ну чтоб, к примеру, квадрат себя увеличивал до размеров половины площади плоскости, в которой он лежит… 

Опять пример кода  Тело метода плоскости: 

А как, программно, узнать, какую часть площади плоскости занимает квадрат? Я извиняюсь, но просто хочется понять…  

Ниасилил.


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


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

  

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



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



Твои впечатления, это твое личное дело, пусть будет так. 

Это сообщение отредактировал(а) LSD - 14.5.2006, 23:40

Лично меня волнует сильнее не ВАШИ рассуждения, а ошибка скрипта на этой ветке.
Все такие блин сильные типа теоретики, а ошибка скрипта показывает обратное мнение обо всех.  ... даже не причастных к этой ошибке ...
вот. простая штука.  

Уважаемый....данный квадрат будет занимать четверть плоскости. Или мне кажется ?


 

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


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


Как я уже дважды (если не больше) писал в этой теме, GUI делать я в ООП не буду даже и пытаться. Когда я делаю гуевые компоненты в Java, я не отступаю от принятого авторами стандарта. Переписывать существующие не-ООП фреймворки с нуля невыгодно, а гибрид делать невыгодно тем более - всё равно ничего хорошего не получится. 


С собственными атрибутами может работать только сам объект. Если некоему объекту X требуются данные квадрата, единственный путь - реализовать в квадрате обработчик сообщения (метод), который передаст эти данные объекту X.


Вам шашечки или ехать?   

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

Пардон, не улавливаю отличий от банального getter'а. 

Я понял...

Это все провакация. Задуманная, чтоб просто  поговорить на умную тему, и поспорить ниачом.

Вначале было интересно.
Затем было смешно.
Сейчас уже не смешно....    

Это сообщение отредактировал(а) Tirael - 15.5.2006, 01:34

Чем ловите?

Разница в том, что вы не можете получить данные квадрата, в отличие от ситуации с getter'ом.  
 

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