Получить / Установить в мире c ++, подделка?

C++ не имеет свойств как C#. Это возможно к методам записи с, "получают" и "устанавливают" на их имена, но они автоматически не создают свойства. Так это - хорошая практика для использования, добираются и методы установки затем?

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

В моем задании, мы действительно используем, получают и устанавливают. Причина состоит, прежде всего в том, что она позволяет записать синтаксические анализаторы для автоматического обертывания классов C++ другими интерфейсами - ActiveX.NET, LabVIEW, Python, и т.д. При использовании intellisence Visual Studio (и подобные технологии на других IDE), я нахожу, что использование добирается, и методы установки делает открытие, что я был легче. Таким образом, существуют времена, где выгодно использовать, добираются и методы установки.

самая важная вещь состоит в том, чтобы выбрать стандарт стиля кода для Вашей библиотеки и согласовываться с нею.

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

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

Я не знаю, рекомендовало ли это использование или нет, но я использую, регулярно добираются/функции множества в моих классах C++, и я писал код C++ больше двух десятилетий теперь. Я никогда не смотрел на Java или C#, таким образом, я не перенимал привычку от тех языков.

Можно определенно использовать средства доступа в C++. Это хорошая статья , на придумывая хорошие схемы средства доступа. похожая статья А также шоу Вы простой meta класс помощника средства доступа, чтобы помочь Вам определить эти умные средства доступа тривиально.

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

Для большинства объектов Вы захотите иметь методы считывания и методы set, но необходимо всегда рассматривать, как объект будет на самом деле использоваться, когда Вы запишете им. Повышение и STL полны методов считывания и методов set, они просто не используют имена, "получают" и "устанавливают" вместо этого, они используют имена как "длина", "конец", "резерв", "способность", и т.д. Причина они не используют слова, получает или установила, то, потому что эти функции служат цели, больше, чем просто устанавливание значения в объекте.

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

Я склонен иметь методы считывания и методы set, я просто не склонен называть их "getX и "setX", обычно я буду делать что-то вроде этого, например:

int x = o->x() // getter
o->setX(5); // setter

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

Я только использую методы считывания/методы set, когда нет никакой альтернативы. Когда я могу, я использовать этот шаблон (не в том смысле, что это - хорошая практика, а в том смысле, что я последовательно делаю это): Изменение свойства не влияет на поведение объекта, пока оно не действительно необходимо. Например:

myWnd->Title = "hello"; // not a setter, just a LPCSTR member
myWnd->Title = "world";
myWnd->ShowWindow();    // perhaps updates a WNDCLASS structure
                        // and other complicated things that
                        // the user of the class doesn't want to know

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

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

• C даже не имел возможности методов считывания/методов set, таким образом, была привычка к использованию прямого доступа к участникам, как в структуре. Привычка всунула C++.
• C/C++ всегда способствовал скорости, и если бы была возможность старого компилятора, который правильно не встроил бы, то метод считывания/метод set имел бы штраф скорости.

Ни один из них неопровержимые доводы.

Мой опыт через C++ и Java, хотя в наше время я работаю в PHP. Мои общие эмпирические правила, которые я использую для PHP и C++:

1. , Если у Вас должна быть членская переменная быть читаемыми снаружи класса, но не перезаписываемыми: используйте getVariableX () только.

2. , Если Вы хотите позволить членским переменным изменяться/читаться за пределами класса, но нуждаться в дополнительной работе, выполненной на них прежде чем/после того, как их значения изменяются: используйте setVariableX () и getVariableX ().

3. , Если бы членская переменная может быть изменена снаружи класса и установить/получить методов, просто было бы простое присвоение: просто обнародуйте переменную, поскольку это - то, с чем Вы сделали бы так или иначе, устанавливал/получал (только более запутываемым способом).

Примечание, что, если Ваш добраться и методы установки делают намного больше, чем тривиальное получение и установка, то необходимо, вероятно, переименовать их, чтобы более точно описать их функцию.

Я почти всегда использую, добираются/методы установки, главным образом потому что можно установить точки останова на них и узнать, где элемент данных устанавливается (или получается доступ, хотя это менее распространено). Кроме того, можно добавить утверждения отладки в стандартной программе метода set (и стандартная программа метода считывания, хотя это менее полезно) удостоверяться, что объект находится в допустимом состоянии при устанавливании значения.

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

Здесь будет немного дидактики ...

У аксессоров есть два аспекта:

• Работа в синтаксисе языка
• Передача намерения

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

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

Самый сложный аспект - сообщить о намерении, и способ сделать это - придерживаться языковых идиом. К сожалению, в C ++ синтаксис несколько мешает этому, поэтому у нас есть такие вещи, как .size () для коллекций и .first и. второй по парам. Все они являются аксессорами, но синтаксис меняется в зависимости от реализации - ой.

Теперь eJames говорит о публичных членах, нарушающих инкапсуляцию. Независимо от того, является ли член общедоступным, это не имеет ничего общего с инкапсуляцией. Инкапсуляция - это продукт дизайна объектов и элементов управления, доступных разработчику классов на языке, который они используют. Это то, что я исследовал более подробно в статье «Инкапсуляция - хорошая вещь ™» (этот сайт пока не позволяет мне добавлять ссылку, но я думаю, что это не так уж сложно для Google).

Что это за оставляет нас с тем, что в C ++ производный атрибут должен использовать синтаксис вызова метода. Непроизводное поле не обязательно, но при желании может быть выбрано. Если вы действительно используете синтаксис вызова метода, вам нужно написать метод-оболочку самостоятельно. Несложно, но, безусловно, увеличивает количество строк. Я попытался показать способ использования языка шаблонов C ++ для абстрагирования кода доступа. Он не совсем успешен, но он справляется со многими случаями использования.

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

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

Even tho c++ doesnt support property accessors by simulating them we dont only make readibility better or provide encapsulation but we provide control mechanism to set a value to a variable or we get calculated value for a variable. So this is the ultimate purpose of accessors. To achive these goals language doenst necesserily support accessors directly. Period.