ivashkanet, Меня просто удивило, то что ты говоришь про стандартные классы и тут же про какие-то формы. В стандартном С++ нет форм. И пример просил привести именном поэтому. В стандартной библиотеке С++ надо постараться, чтобы встретить set/get, хотя найти можно.

А у меня в IDE нет такого. хнык-хнык((

Добавлено @ 16:51 

Скорей всего по лигике этот класс сам должен эти данные записать в класс сборщика статистики 

А класс формы разве не стандартный класс?

Что за IDE такое??? 

речь не о наз ваниях функций. Речь о данных, а не о свойствах. SetCaption это не установка переменной, хранящей значение заголовка, а именно изменение заголовка


вот и непонятно что именно и кому ты хочешь доказать...


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

Базовый класс Write.
От него наследуются классы WriteInFile, WriteInScreen и т.д.

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


En_t_end, 

Да нечего отвечать. Все уже написано выше. 
Данные класса не должны никого интересовать вне этого класса.

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

Добавлено @ 17:07 

это по какому стандарту??????   

Нет.

Блокнот + CommandPromt + MinGW 
=))) 

Что-то мне вспомнилась недоброй памяти ветка, где затрагивались вопросы инкапсуляции. В воздухе отчетливо запахло догмами…
Автор сказал именно то, что хотел сказать:

Не надо априори заворачивать все в get/set, и не надо априори считать открытый доступ к полям злом.

Позволю себе привести цитату с одного форума, не совсем on-topic, но очень близко:


P.S.
Солгасен с DeadSoul:
 

Поподробнее об это, пожалуйста.
Что мешает мне в сеттере СВОЙСТВА Caption ПОЛНОСТЬЮ продублировать код функции SetCaption  
Или это опять нарушение инкапсуляции


Хророшо, но тогда получается, что он неправильно спроектирован?

    

ОК, согласен. Но тогда все наши классы будут неподъемными монстрами, с КУЧЕЙ "лишнего" кода, который будет только заботиться о взаиможействии с остальным миром.
Я получу, наконец, ответы на свои вопросы?

Заметьте, Form.Caption -- это не поле, а свойство, сделанное с помощью get и set, а в set помещен 1:1 код метода SetCaption
и 
 

В С++ нет такого лексического понятия как свойства! В это то собственно и весь топик, т.к. иногда приходится писать get/set
Ты похоже со своим уставом монастырем ошибся;) 

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


да???????    нифигасе!!!!!

где у меня лишний код? Хочешь выводить файл на стену или в космос - пиши соответствующего наследника Write и все в шакаладе. Работавший до этого код никак не изменится и работа его никак не изменится

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

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

 

пустые слова. Что мне мешает думать о фукнционале при разработке объектной модели? Пример тоже ни о чем не говорит.



ты неправ

Добавлено @ 18:44 
 ну так это вообщето очевидно, что если есть правила, то правильно - это соблюдать правила и программирование здесь ничем от других областей жизни не отличается 

Я наоборот считаю, что если сначала строить ОО-модель, то можно получить результат не только быстрей, но и качественне. Ты сразу накладываешь условие на некоторые параметры, подстраиваешь условия под возможности ООП, проектируешь с учетом ООП. Если же строить модель потом(я пробывал и так), приходится "обрезать" идею под возможности. Методом проб и ошибок, выбрал первое.

Добавлено @ 18:59 

я не это имел ввиду  Я говорил не просто о соблюдении правил. Если одна часть ПО будет спроектированна в виде библиотеки высокачественных классов, а другая в виде простого кода, набора итеративно-функциональных операторов, то это неизбежно приведет к возникновению get/set в библиотеке. Поэтому, чтобы в проекте ПО не было узких мест, в виде такого кода, следует проектировать ВСЁ ПО, как набор ОО-моделей.  

Это сообщение отредактировал(а) En_t_end - 8.7.2006, 19:06

ОК. Вот тебе линк на корень той дискуссии. Я не настаиваю на полной правоте этих слов.

По линку на ту ветку (в здешних РВ) сходил? Там тоже человек отстаивал антиобъектнориентированность геттеров/сеттеров и свойств, как синтаксического сахара над ними.

Кстати, смысл есть и в закрытых или защищенных mutators. Уж они-то инкапсуляцию не нарушают, но иногда оправданны, т.к. повышают сопровождаемость кода. 

Это сообщение отредактировал(а) Void - 8.7.2006, 19:01

там на другую тему дискуссия 

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


Ага, читал. А то что вы сейчас имеете досталось вам от несовершенного C  

Монастырь агрономов-осеннизаторов?

С какой такой стати?

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


Полностью согласен с Void. Сеттеры и геттеры это синтаксический сахар, ИМХО.
Сеттер -- более удобная (синтаксическая) замена функции типа void, принимающей один параметр.
Геттер -- функции любого типа без параметров.

 

Если учесть что в С вообще нет ООП, то о каком наследстве может идти речь?

А с такой, что пытался кике-то "свойства" и формы приписать