не понимаю предпоследний абзац. что хотел сказать автор этим правилом?

 

Думаю, автор имел в виду, что если у тебя член класса x методами get и set только читается и изменятся, то эти методы не имеют смысла, так как компилятор все равно при оптимизации будет просто подставлять значение данного члена (без вызова метода).
Вот только я не уверен, что неиспользование это хорошо. По-моему, лучше get/set использовать, так как в случае если при изменении данного параметра придется еще выполнять ряд действий, то не придется менять интерфейс класса (проще говоря, не придется переписывать уже написанные программы, использующие этот класс).
А читабельность можно повысить правильным форматированием.  

bsa, 
нет совсем не это имел в виду автор. В этой книге автор несколько раз приводится пример про календарь.
на самом деле имеется в виду, что данные класса в правильно спроектированном классе не представляют инттереса вне класса. Нужно рассматривать класс, как самодостаточную вещь и оперрировать не данными класса, а его интерфейсом. Подход в том, что данные закрыты не для того чтобы просто затруднить к ним доступ, а в первую очередь потому, что в правильном классе нет необходимости в доступе к данным извне класса, а есть функции типа "сделай что-то" , "создай это" и тд. 
а set и get на самом деле  по сути  нарушают инкапсуляцию 

В этом автор ошибается. 
1. С течением времени смысл этих методов может изменится
2. С getter-ами\setter-ами проще отлаживатся, т.е. найти то место где туда устанавливается не очень корректное значение
 

про читабельность там с иронией говорится.

Добавлено @ 22:19 
весь смысл в том, что установка 
по сути и есть нарушение инкапсуляции и в хорошо спроектированной программе данные классов не устанавливаются и не считываются 

Fazil6
Тебе бы книжки писать - объяснение намного понятнее.  

Fazil6, хорошо обьяснил.

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

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

Ага! Если я правильно понял, то, к примеру, вместо set использовать инициализацию в конструкторе, а заместо get использовать к примеру методы "Распечататься",  "Записаться в файл" и др. Таким образом, необходимость в методах set и get должна отпасть сама собой. 

bsa, 
Fazil6, 
DeadSoul, 
sergej.z, 
всем участникам большое спасибо! 

А почему нельзя get'ы использовать ?(c set'ами все понятно...)

Добавлено @ 11:45 
допустим, мне нужно собрать статистику со всех классов. В каждом классе есть метод GetOccupied. Неужели этот метод нарушает инкапсуляцию ? То есть технологию аксессоров нельзя применять ?  

А как передавать настройки новому классу?
Через методы, или может в конструкторе?

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

P.S. Стандартные классы направо и налево используют открытые свойства. 
Врятли программисты не знали свое дело, когда проектировали их. Даже больше -- они же и создавали стандарты языка  
Представьте что бы было если бы "самый главный" класс Form не имел открытых свойств. Что бы тогда было. Заголовок, положение, размеры, ... все передавать через конструктор?
+ Обясните мне разницу между методом Form.SetCaption("Название формы") и Form.Caption = "Название формы" с точки зрения работы программы? ... Да ее просто НЕТ  
P.P.S. Я сам .Net-чик, поэтому не знаю как в С++ называется свойство заголовка формы 

Добавлено @ 13:51 
Продолжу  
Несомненным плюсом Сеттеров является то, что мы можем провести валидацию данных и в случае несоответствия выкинуть исключение. Именно поэтому не стоит использовать открытые поля классов. Они не поддерживают валидацию.
У Геттеров такого явного преимущества нет   Кроме как запрета на чтение значения поля.
  P.S. Автор может и знает свое дело, но, ИМХО, писать не умеет   . Сполшные сложные предложения, обороты... Пришлось дважды перечитывать, прежде чем войти в курс дела.
Перечитайте этот отрывок. Все ли понятно после первого прочтения?


 

Хорошая шутка


Можно пример? Ещё привлекает внимаение слово "свойства"...


Да. Если такое произошло - значит существет ошибка в проекитировании этого самого класса. 

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

Не думай, что гуишные классы NET, VCL или MFC являются стандартом программирования и речь идет о ООП в теории, а не конкретной реализации конкретных классов.
Свойство - это интерфейс класса, а не данные класса и именно об этом говорит автор. 

Я что угадал? У нас (в .Net) заголовок формы устанавливается через Form.Text   


Поля класса -- конретные "переменные" класса, т.е. его данные.
Свойства -- "обертки" для полей класса, сделанные с помощью get и set.
Врятли от языка к языку эти понятия меняются.   

Я ведь дал пример 

А вообще зайди IDE, выдели любой класс и любуйся открытыми СВОЙСТВАМИ в закладке Propertes.
Там перечисленны только они, полей нет  

А я что спорю   

После нас хоть потоп. Да?
Представьте ситуацию: 
Мы спроектировали класс, который что-то обрабатывает, а потом выводит на экран (ShowOnScreen()). 
Мы продали этот класс. Его используют другие люди. Всем нравится, все в восторге.
Через некоторое время понадобился вывод на принтер. Они связваются с нами, мы лезем в код добавляем метод (SendToPrinter()). Через время понадобился вывод еще на что-нибудь...
Это выход? Вместо того чтобы открыть результат вычислений, после чего любой сможет написать свой вывод на что угодно.
О   придумал еще пример:
Вы вешаетесь на событие формы Resize, вам нужно перепозиционировать контролы на форме. Как это сделать, если размеры формы закрыты?

Обожаю когда люди критикуют только часть сообщения, а не всё полностью
Почему не было комментариев по этому поводу:

или

 

Мне ответьте  пожалуйста...
 

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, принимающей один параметр.
Геттер -- функции любого типа без параметров.

 

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

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

по-моему это оскорбление... 

Повторяю: свойства -- это данные класса завернутые в get и set (неважно каким образом завернутые).

Это просто пример класса у которого много открытых "данных". И как их закрыть я ума не приложу   

Почитай внимательно первый пост

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

Добавлено @ 12:08 






 

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

пример с формой не говорит, что это стандарт и так нужно делать всегда. 

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



И все таки,  что мы такое сейчас имеем???? 

Поднятая тема -- не стоит использовать gettter и setter в коде?
Или я не так понял, и поднятая тема -- не стоит использовать gettter и setter в коде, если они ничего не делает кроме как напрямую обращаются к данным? Как в примере.

Это врятли. Но то что я плохо изъясняю свою позицию --- с этим  я могу согласиться


Нееее, эт я в курсе  Даже много раз писал... Но тема-то про гет и сет, а это и есть свойства   

Забудь, я просто перефразировал автора.

Но таких классов не одна форма. Их сотни  
P.S. Предлагаю закончить ругаться  . Объясните мне четко и понятно в чем я не прав, пожалуйста. 

Вообще-то, SetCaption и есть сеттер для "свойства" Caption, куда ты собираешься дублировать код?

В отсутствии свойств С не при чем, вон в C++ Builder'е свойства давно есть как расширение языка. Может в следующий стандарт их все же включат. 

А зачем? 

Дя..., Это все отличие синтаксисов языков. Под SetCaption я имел в виду просто функцию, а не сеттер.
Функциями ж типа можно пользоваться.
А вообще, повторю свою позицию:

И никакой разницы между ними нет

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

Как то странно: get и set есть, а свойств нет    

Как так?

  
P.S. Мог накосячить с синтаксисом, так как не в курсе про * и & (приведение к ссылке и назад). Но идея, думаю, ясна. 

В С++ сеттер это и есть "функция типа void, принимающая один параметр".

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

Удобная все таки штука - свойства! 

ivashkanet
мда.... как все запущено....
ты бы почитал первые сообщения в этой ветке.

Ну и что в том, что ты смог через открытый интерфейс получить значение данных. Если у тебя в классе есть необходимость в данных другого класса, то твой дизайн неправильный и об этом речь изначально, а не о том, что нельзя использовать set и get. В моем примере нет никакой необходимости в таких методах  

Это сообщение отредактировал(а) Fazil6 - 9.7.2006, 19:35

А с ней (SetCaption()) нельзя делать вот так: Caption="Caption"  

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

Инициализация в конструкторе:
А если у нас десяток полей (настроек класса) и все они необязательные? Делать конструктор на 10 параметров, или, еще лучше, 10! конструкторов на все случаи жизни.  
Методы "Распечататься",  "Записаться в файл" и др.:
Невозможно предусмотреть все варианты.
А твой, Fazil6, пример ничем не лучше чем get или функции, возвращающей значение.

А если цель моего класса -- обработать данные, то как мне их передавать?
Наилучший выход метод Execute() или Calculate(), которые вернут вычисленное значение/структуру.
А это ничем не лучше чем get 

Ошибка проектирования

Ошибка проектирования 

именно. Именно это я и говорил. Именно так он меня и понял. Иэто правильно. Пользователь класса не должен задумываться о данных класса. Они его не интересуют.


изменить класс. Это плохой класс, если нужно создав класс начинать настраивать его установкой  значений его переменных. Не надо только начинать мне приводить всякие классы форм из NET или VCL. Это не стандарт правильного проектирования классов всилу ряда причин. Сейчас разговор об объектно ориентированном подходе в теории.
 
Во первых перед программистом никогда не должна стоять задача предусмотреть все варианты. Перед ним стоит конкретная задача, а не некий гипотетический худший случай. Во вторых я привел тебе пример, когда классы разработаны так, что добавления нового функционала не затрагивают ни одной строчки работавшего до этого кода. И это правильно. 

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


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

Забейте. Каждый остался при своем мнении.
Всем спасибо, что уделили мне время   

возможно повторюсь за Fazil6, но все-таки. я думаю здесь можно вспомнить The Dependency Inversion Principle - принцып иверсии зависимостей. 

по сути он состоимт из двух частей:


и в пример приводится программа "Copy". модуль copy может читать с клавиатуры и записывать на принтер.

                          ---- Copy-----
                         |                    | 
                        Read            Write
                      Keyboard       Printer

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

                          ---->Copy<----
                         |                      | 
                      Abstract       Abstract       
                       Reader         Writer
                         |                      |
                        Read          Write
                      Keyboard       Printer

то есть в классах Abstr. Reader и Writer содержатся чистые виртуальные функции, и мы сможем добавить в систему "чтение из файла" или принтер другой модели, не трогая при этом Copy. предусмотреть 50 моделей принтеров действительно невозможно, но можно постараться сделать так, чтобы их потом можно было безболезненно добавлять. 

нет



Какая GUI библиотека является стандартом и что это за ряд причин? 

А еще вопрос можно?

как реализовать класс Vector с тремя полями x,y,z не используя доступ к данным?

Или его существование будет ошибкой проектировки? 

Leksey, А чем этот Vector принципиально отличается от всего выше рассмотренного? Ничем, а значит и требования для него те же. 

можно

напрягаешь голову, думаешь и реализовываешь

 
если он мне нахрен не надо в программе, то конечно это  

Даже если речь идёт о классе-наследнике? Т.е. код вроде


это уже ошибка проектирования?


Странный код, однако :-‎)
Начнём с того, что непонятна природа SomeData. Что будут с ней делать функции write производных от Write классов? Кроме того, что мы будем делать, если нам понадобится не просто «распечатать» какое-то одно поле, а ещё и какие-то операции осуществить (причём, возможно, с несколькими полями)? Или все данные класса нужно непременно сосредоточить в одном-единственном поле d типа SomeData, и это есть хорошо?


Ну это вообще шедевр, заслуживащий наивысших похвал :-‎) 

Fazil6  А что так грубо?

Я вроде привел пример очень простого класса и просто интересно было посмотреть как его реализовать.А то может я что не так сделаю... 

да. 
Это тоже самое, когда твои данные были бы просто protected
Если DerivedClass оперирует данными, то почему эти данные находятся в другом классе.
Данные класса - это деталь реализации, когда в наследовании принимают участия данные, то детали реализации становятся частью интерфейса, а это плохо.


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

Вотм то и дело. Есть интерфейс и он определен


Классу по барабану, что вы будете делать с данными. Куда хотите, туда и выводите. Класс Сам решает какие данные он хочет вывести и передает их.    
 
 Опять пишем класс на на все случаи жизни?
и что? Необходимость в доступе к данным == неправильный дизайн. Проектирование  + виртуальные функции - вот инструмент решения проблем. Сколько еще раз повторить? 

Или Вы мне надеетесь доказать, что инкапсуляция куйня?


данные вне класса никому не нужны.
Представьте себе функцию swap. Функция сидит себе и ничего не делает. Вдруг ее вызвали. Она получила 2 ссылки и поменяла их значения местами. Какое ей дело кто ее вызвал? Какое ей дело кто ей эти аргументы передал? По барабану что эти данные значат. Тоже самое происходит и снаружи этой функции. Когда кто-то вызывает функцию swap ему 100% до лампады как эта функция будет выполнять то, что от нее ждут. Она выдала результат  и ауфидерзейн. Теперь представляем функцию, которая ходит за всеми и просит их дать ей 2 переменные и уж она их обработает. Бред.

Почему по вашему с классами это не Бред?
 
При хорошем проектировании вопросы, которыми вы пытаетесь меня победить не возникают вообще. 
UnrealMan, 

а тут уж что тебя не устраивает?
 

тебе показалось. Ну писать тебе класс я не буду просто пото потому, что понятия не имею, что за класс тебе нужен. Обратись в центр помощи, может там помогут.
  

Fazil6, в твоем первом примере с классом Write ты говорил, что нет необходимости давать доступ  к внутренней структуре класса с помощью get/set? Если да, то твой пример ничего не объяснет, поскольку Write это абстракный класс, не содержащий никаких данных. Все данные передаются явно методу write, но откуда беруться эти данные? Если из другого класса, то здесь без get() не обойтись, а если это просто внешний объект, то причем здесь тогда инкапсуляция?
Может на более высоких уровнях абстракции и можно обойтись без get/set, то при реализации таких базовых классов как Point сложно обойтись без getX(), getY(), getZ().
Вообще, если класс представляет из себя некоторую структуру данных, то он далеко не всегда знает как эти данные обрабатывать. Тут одним наследованием и полиморфизмом не обойтись, предется открывать доступ к части данных. 

Write - это класс обрабатывающий данные. MyClass - это класс у которого есть данные (вот они!!! данные!!!), которые он хочет обработать. Ему передается "обработчик" (наследник Write) и с помощью этого обработчика(у которого тоже есть открытый интерфейс) класс MyClass обрабатывает свои данные. Никто ни у кого никакие данные здесь не запрашивает. Этому обработчику глубоко до фени откуда взялись данные, чьи они и зачем. Он знает тип этих данных и знает что с ними нужно сделать.

Добавлено @ 14:36 

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

А как класс Write получит доступ к данным SomeData?
С помощью get/set или того хуже SomeData - это структура с открытыми данными? 

baronp, не тут идея как раз в том, что для Write доступ к SomeData не нужен.
Наоборот SomeData использует Write и внутри себя подготваливает данные в том виде, в котором Write готов их принимать.
Всё красиво в теории. Но "В теории нет разницы между теорией и практикой, на практике же она есть" (см. мою подпись).
Никогда не поверю, что можно эффективно писать не интересуясь состоянием объекта до того, как потребовать от него действия.

Вы же предпочтёте проверить сколько у вас денег в кошельке прежде, чем сделать дорогую покупку, а не говорить потом у кассы: "Ooops, an exception occured"    

Это сообщение отредактировал(а) Дрон - 12.7.2006, 15:53

То есть в SomeData есть метод getDataToWrite()?
Понятно, что дело не в названии метода, но чем же он в таком случае отличается от геттера? 

Повторяю : это абстрактный пример. Не важно что такое SomeData. Считайте, что это int. Вы за деревьями леса не видите.
   
Я - класс , деньги - мои данные. Я проверяю и ничего в этом страшного нет. Это ведь в классе происходит. А вот когда на просьбу показать товар, продавец потребует показать сколько у меня есть денег...  Никого не должны интересовать мои деньги кроме меня. 
 

То есть класс, содержащий данные должен знать о классах, которые будут эти данные обрабатывать (точнее, не о самих классах, а о интерфейсе Write). Если это библиотечный класс, то имхо будет сложно учесть в нем все возможные способы работы с его данными. 

с его данными тоже никто работать не собирается.  
Никто не должен предусматривать все способы. Пиши те способы, которые нужны на данный момент. Если потребуется новый способ, ты напишешь новый класс, наследник Write реализуя интерфейс нужным тебе способом и все. С работавшим до этого кодом ничего делать не нужно. 

его данные использует метод write для вывода чего-то там на печать. 

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

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

что то я запутался: где у тебя храняться данные, которые надо вывести на печать или на экран?
в потомке Write или где-то еще? 

по моему очень простой пример. Функция write получает данные в аргументе от MyClass и куда-то их записывает.

 

Еще раз повторю свой вопрос: как метод write получит доступ к SomeData.
В данном случае это принципиально, поскольку класс Write и его наследники не имеют своих данных, а служат лишь для обработки данных, полученных извне. Если SomeData это простая структура, то тогда причем тут полиморфизм, обращаемся напрямую к полям этой структуры и выводим все на печать. Если структура SomeData изменится, придется переписывать много кода. Если же доступ к SomeData идет через get/set, то есть надежда, что придется переписать только эти методы.
Кстати, в данном первом примере вполне можно было обойтись без полиморфизма: просто наделать функции типа writeToFile, writeToPrinter и т.д. Как же тогда получить доступ к данным SetData без get/set и без нарушения инкапсуляции?