Считаю, что большинство учебников по ООП врут.

 

Доступ к переменным объекта должен быть всегда!

За исключением случаев когда доступ не ограничен просто доступом, а предваряется процедурами и/или процедуры следуют после доступа.

Господа, писать две функции GetVariable() и SetVariable() для private переменной c одной строчкой - это дебилизм!

 

Кто что думает?

QUOTE (D-Light @ Aug 21 2006, 20:51)

Было услышано нечто, с чем не согласилось (или вообще не поняло что к чему) большинство. Я лично вообще не вижу смысла спорить насчет того, что тяжелее: один метр или градус Цельсия.

Да.

А не лучше ли эти DoubleField и т.п. реализовать так:

шаблонный класс, внутри:

ссылка на объект

ссылка на поле (для удобства использования)

ссылка на get функцию (если 0, то используется ссылка на поле)

ссылка на set функцию (если 0, то используется ссылка на поле)

В нем реализовать все операторы, в потомке дать доступ ко всем полям и сделать функцию инициализации. (т.е. сам объект будет работать с потомком, а снаружи будет виден базовый класс)

 

Для каждого псевдосвойства будет нужно 1 доп. переменная, 1 строка инизиализации и get, set по мере необходимости.

QUOTE (ПалСемёныч @ Aug 21 2006, 20:03)

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

Я если честно мало что понял из этого ;)

Что значит реализация вложенных объектов?

Что такое оператор конкатенации (в С++ сроду такого не было)?

 

Я еще раз напомню ваше утверждение (выделение мое)

QUOTE

А умные книжки (толкующие про C++) как раз явно, открытым текстом советуют перегружать оператор присваивания для сохранения инкапс"ю"ляции на фоне приятночитаемости.

Вас попросилм дать ссылку (еще лучше цитату), а вы что-то наводите тень на плетень.

QUOTE (System @ Aug 15 2006, 03:15)

Считаю, что большинство учебников по ООП врут. Доступ к переменным объекта должен быть всегда! За исключением случаев когда доступ не ограничен просто доступом, а предваряется процедурами и/или процедуры следуют после доступа. Господа, писать две функции GetVariable() и SetVariable() для private переменной c одной строчкой - это дебилизм! Кто что думает?

Ха https://academ.club/html/emoticons/smile.gif дебилизм - это когда пользователь вашей библиотеки начинает дергать за те ниточки, которые неизвестно куда для него ведут. а Вы пробовали хоть раз писать более-менее сложную библиотеку классов, которую в дальнейшем будут использовать программисты, отличные от Вас? Уверяю Вас, когда пользователю можно поменять все и вся (даже то, что по идее ни в коем случае нельзя разрешать программисту менять), все грамотно спроектированные интерфейсы летят к чёртям, теряется минимальность, возрастает количество способов использования и соответственно, вся простота использования Вашей библиотеки испаряется - вместо этого программист сидит и чешет репу, почему одно и тоже возможно сделать несколькими способами и как лучше??? Да это еще полбеды. Представьте себе, что Ваша тривиальная реализация свойств либо методов доступа к закрытым/защищенным полям ВДРУГ оказывается неприемлемой, и внезапно становится необходимым не просто возвращать/устанавливать поле, а подключать некий интеллект - при доступе выполнять некоторые дополнительные операции? Легче ведь в одном месте поменять функциональность, чем в 100, да и читаемость кода от этого не пострадает.

 

Неспроста ведь инкапсуляция введена, да и принципы ООП придумали не школьники. Читайте Майерса, "More effective C++", у него на эту тему все популярно сказано.

QUOTE (Mad Sanity @ Aug 22 2006, 18:06)

Уверяю Вас, когда пользователю можно поменять все и вся (даже то, что по идее ни в коем случае нельзя разрешать программисту менять), все грамотно спроектированные интерфейсы летят к чёртям, теряется минимальность, возрастает количество способов использования и соответственно, вся простота использования Вашей библиотеки испаряется - вместо этого программист сидит и чешет репу, почему одно и тоже возможно сделать несколькими способами и как лучше???

Как раз это только хорошо. Больше вариантов использования - больше гибкость.

 

P.S. С автором частично согласен - не для всякого свойства нужно писать getVar и setVar. А вообще, надо переходить с C++ на совремменные языки и не иметь таких проблем.

QUOTE (GrayFace @ Aug 25 2006, 00:38)

А вообще, надо переходить с C++ на совремменные языки и не иметь таких проблем.

Да? И какие же языки мы зовем современными?

Как всегда, все заканчивается холиваром https://academ.club/html/emoticons/cbs_madlaugh.gif

QUOTE (System @ Aug 15 2006, 03:15)

Господа, писать две функции GetVariable() и SetVariable() для private переменной c одной строчкой - это дебилизм!

Это не оправдано пока проект маленький.

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

AmbassadorKosh,

Мы зовем современным C#. https://academ.club/html/emoticons/smile.gif Java; Delphi, в конце концов, тоже более-менее идет в ногу со временем. Я как раз все время писал на Дельфи, так что отсутствие property, для меня, выглядит достаточно дико. Сильно удивляет то, что создатели Java настолько гнались за строгостью (или чем-то обычной логикой непостижимым), что оставили это за бортом.