Это и есть так называемое сокрытие данных?

@Jzx · Регистрация: 31.12.2017

Студворк — интернет-сервис помощи студентам

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <iostream>
using namespace std;
 
class myclass
{
    int a;
public:
    int &geta();
} myclass1;
 
int &myclass::geta()
{
    return a;
}
 
int main()
{
    myclass1.geta()= 2018;
    cout << myclass1.geta();
}

Результат работы программы: 2018

@New man · 06.11.2018, 22:22

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

@TheCalligrapher · 06.11.2018, 22:49

Сообщение от Jzx

Это и есть так называемое сокрытие данных?

Да, разумеется. Это один из вариантов сокрытия реализации (или сокрытия данных - как вам больше нравится).

В данном случае вы даете клиентам вашего класса полный контроль над неким свойством a, т.е. даете клиентам доступ к этому свойству, как к lvalue. Клиентский код может использовать оператор присваивания, чтобы читать данные через полученную ссылку, записывать данные через полученную ссылку, а также [возможно] оператор взятия адреса, чтобы формировать указатель на полученное lvalue. Однако при этом вы скрываете от клиентов место физического хранения этого элемента данных - он может быть членом класса myclass, а может и не быть, т.е. храниться где-то совсем в другом месте.

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

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

@XLAT · 07.11.2018, 11:47

Сообщение от New man

Это как построить высокий крепкий забор, поставить самый сложный замок на ворота, а потом отдать набор ключей ворам.

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

@COKPOWEHEU · 07.11.2018, 17:28

Лучшей иллюстрацией сокрытия данных будет что-то вроде такого:

C++
1
2
3
4
5
6
7
class myclass{
  private:
    int a;
  public:
    int GetA(){return a;}
    void SetA(int _a){a=_a;}
} myclass1;

Здесь, если юзер не знает деталей реализации (например, если код GetA и SetA вынесен в *.cpp файл), он не будет знать, существует ли вообще переменная a и какого она типа.

@TheCalligrapher · 07.11.2018, 18:35

Сообщение от New man

Это как построить высокий крепкий забор, поставить самый сложный замок на ворота, а потом отдать набор ключей ворам.

Сокрытие реализации - это не защита от воров.

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

C++
1
2
3
4
5
6
7
8
class myclass
{
public:
    int a;
};
 
...
int myclass::*p = &myclass::a;

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

Сообщение от XLAT

и этот любой изеркодер может через паблик менять нутро привата.

И? Что именно вы хотите этим сказать?

Если разработчику класса нужно публично-доступное свойство, которое физически реализуется полем этого же класса, то так и получится: юзер будет "через паблик менять нутро привата". Как и должно быть.

В данном примере вызывает удивление возврат ссылки на поле, что является существенно более слабой формой сокрытия реализации, чем пара setter/getter, но тем не менее и здесь присутствует сокрытие реализации.

@COKPOWEHEU · 07.11.2018, 19:05

Сама идея сокрытия реализации / данных заключается не в том, чтобы никто и никогда не получил к ним доступа. При "правильной" реализации объекта (или библиотеки, или еще какого-то модуля) он должен представляться черным ящиком, назначение которого можно понять и без информации о внутреннем устройстве. Это отчасти психологический стимул снижать связность, выделяя сильно связанные друг с другом участки в один модуль и оставляя лишь необходимый минимум ручек и кнопочек для взаимодействия. В результате разработчику не приходится держать в голове всю структуру программы и каждый раз достаточно только одного уровня абстракции.
Например, при написании скрипта используется только его уровень абстракции, а все утилиты считаются черными ящиками, у которых есть входы и выходы (ключи запуска, stdin и stdout). Как именно устроена каждая из них значения не имеет. Если на программу придет обновление и полностью изменит ее структуру, внешний скрипт этого даже не заметит (хорошо бы если бы так, эх...). Если спуститься на уровень ниже, на реализацию какого-то отдельного "кирпичика", ситуация повторяется: нам безразлично, кто и с какой целью будет вызывать нашу программу и нам безразлично (в определенной мере), как именно устроены используемые библиотеки.
Поэтому реализация ТСа не является удачным примером. Он дает пользователю бесконтрольный доступ к полю класса. То есть класс сам не знает, когда это поле изменится. Это увеличивает связность: теперь класс обязан считать, что поле может измениться когда угодно, он не может, например, использовать это поле в расчете какого-нибудь сложного выражения для повторного использования (а вдруг поле изменится и придется пересчитывать выражения, а объект-то об этом не знает).

@XLAT · 07.11.2018, 19:15

https://rextester.com/UFM18971
теперь можно спать спокойно, правильный год уже никто не украдет)

@TRam_ · 07.11.2018, 19:19

XLAT, при одновременном использовании в нескольких потоках будет ошибка. В том числе если будешь обращаться к разным объектам (переменная-то статическая). Лучше её (временную переменную) тоже делать членом класса.

@TheCalligrapher · 07.11.2018, 19:27

Сообщение от XLAT

теперь можно спать спокойно, правильный год уже никто не украдет)

??? Из geta возвращается именно ссылка как раз для того, чтобы дать возможность клиентскому коду менять год. А вы зачем-то подавили эту возможность. Где смысл?

Если бы задача состояла в том, чтобы не допустить модификации года, geta бы возвращала просто int.

@XLAT · 07.11.2018, 20:09

Сообщение от COKPOWEHEU

реализация ТСа не является удачным примером. Он дает пользователю бесконтрольный доступ к полю класса.

ТС ничаво никому не дает, я сам могу залезть в интерфейсную часть любого класса и добавить такой код на любую переменную, которую "типа спрятали" в приват.

Сообщение от TRam_

Лучше её (временную переменную) тоже делать членом класса.

ок.

Сообщение от TheCalligrapher

??? Из geta возвращается именно ссылка как раз для того, чтобы дать возможность клиентскому коду менять год. А вы зачем-то подавили эту возможность. Где смысл?

да ладно, поверьте я высоко ценю силу сетерогетерной идиомы)
да, подавил из чисто академического интереса)))

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

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

@COKPOWEHEU · 08.11.2018, 09:33

Сообщение от XLAT

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

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

Сообщение от COKPOWEHEU

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

@XLAT · 08.11.2018, 10:30

Сообщение от COKPOWEHEU

Повторяю:

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

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

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

@New man 309 / 221 / 74 Регистрация: 23.05.2011 Сообщений: 981
	06.11.2018, 22:22
	Jzx, нет. Вы возвращаете ссылку на внутренний элемент, с которым потом кто угодно может делать что угодно. Это как построить высокий крепкий забор, поставить самый сложный замок на ворота, а потом отдать набор ключей ворам. 0

@COKPOWEHEU 4083 / 2681 / 432 Регистрация: 09.09.2017 Сообщений: 11,921
	07.11.2018, 19:05
	Сама идея сокрытия реализации / данных заключается не в том, чтобы никто и никогда не получил к ним доступа. При "правильной" реализации объекта (или библиотеки, или еще какого-то модуля) он должен представляться черным ящиком, назначение которого можно понять и без информации о внутреннем устройстве. Это отчасти психологический стимул снижать связность, выделяя сильно связанные друг с другом участки в один модуль и оставляя лишь необходимый минимум ручек и кнопочек для взаимодействия. В результате разработчику не приходится держать в голове всю структуру программы и каждый раз достаточно только одного уровня абстракции. Например, при написании скрипта используется только его уровень абстракции, а все утилиты считаются черными ящиками, у которых есть входы и выходы (ключи запуска, stdin и stdout). Как именно устроена каждая из них значения не имеет. Если на программу придет обновление и полностью изменит ее структуру, внешний скрипт этого даже не заметит (хорошо бы если бы так, эх...). Если спуститься на уровень ниже, на реализацию какого-то отдельного "кирпичика", ситуация повторяется: нам безразлично, кто и с какой целью будет вызывать нашу программу и нам безразлично (в определенной мере), как именно устроены используемые библиотеки. Поэтому реализация ТСа не является удачным примером. Он дает пользователю бесконтрольный доступ к полю класса. То есть класс сам не знает, когда это поле изменится. Это увеличивает связность: теперь класс обязан считать, что поле может измениться когда угодно, он не может, например, использовать это поле в расчете какого-нибудь сложного выражения для повторного использования (а вдруг поле изменится и придется пересчитывать выражения, а объект-то об этом не знает). 1

@XLAT Just Do It! 4210 / 2667 / 655 Регистрация: 23.09.2014 Сообщений: 9,077 Записей в блоге: 3
	07.11.2018, 19:15
	https://rextester.com/UFM18971 теперь можно спать спокойно, правильный год уже никто не украдет) 0

@TRam_ зомбяк 1585 / 1219 / 345 Регистрация: 14.05.2017 Сообщений: 3,940
	07.11.2018, 19:19
	XLAT, при одновременном использовании в нескольких потоках будет ошибка. В том числе если будешь обращаться к разным объектам (переменная-то статическая). Лучше её (временную переменную) тоже делать членом класса. 0

Это и есть так называемое сокрытие данных?

Решение