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

Повторяю: свойства -- это данные класса завернутые в 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 моделей принтеров действительно невозможно, но можно постараться сделать так, чтобы их потом можно было безболезненно добавлять.