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


Ты прекрастно знаешь что методы 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

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