Почему частные поля, недостаточно защищены?

Является ли видимость private полей класса /свойств /атрибутов полезной? В ООП рано или поздно вы создадите подкласс класса, и в этом случае хорошо понимать и полностью модифицировать реализацию.

Одна из первых вещей, которые я делаю, когда я подклассифицирую класс, - это изменить кучу private методов на protected. Однако скрывать детали из внешнего мира важно, поэтому нам нужен protected, а не только public.

Мой вопрос: знаете ли вы о важном прецеденте, когда private вместо protected является хорошим инструментом или может быть два варианта "protected code> & public "достаточно для языков ООП?

261 голос | спросил Adam Libuša 11 MarpmFri, 11 Mar 2016 12:17:59 +03002016-03-11T12:17:59+03:0012 2016, 12:17:59

17 ответов


223

Потому что, как вы говорите, protected по-прежнему оставляет вам возможность «полностью модифицировать реализацию». Это действительно не защищает что-либо внутри класса.

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

На практике члены protected являются, по существу, общедоступным API класса для подклассов и должны оставаться стабильными и обратно совместимыми, насколько это делают члены public. Если бы у нас не было возможности создавать истинные private элементы, то nothing в реализации всегда было бы безопасно изменять, потому что вы не смогли бы исключить возможность того, что (не вредоносный) клиентский код каким-то образом зависеть от него.

Кстати, в то время как «В ООП, рано или поздно, вы собираетесь сделать подкласс класса», технически верно, ваш аргумент, похоже, делает гораздо более сильное предположение о том, что «рано или поздно вы собираетесь сделать подкласс класса каждый ", что почти наверняка не так.

ответил Ixrec 11 MarpmFri, 11 Mar 2016 12:30:06 +03002016-03-11T12:30:06+03:0012 2016, 12:30:06
254
  

В ООП рано или поздно вы создадите подкласс класса

Это неправильно. Не каждый класс должен быть подклассом, а некоторые статически типизированные языки ООП даже имеют функции для его предотвращения, например, final (Java и C ++) или sealed (C #).

  

хорошо понимать и быть в состоянии полностью модифицировать реализацию.

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

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

Или выразить это в терминах Скотта Мейерса: на частные части класса влияет конечный код: код самого класса.

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

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

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

ответил Sebastian Redl 11 MarpmFri, 11 Mar 2016 12:34:24 +03002016-03-11T12:34:24+03:0012 2016, 12:34:24
33

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

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

ответил Robbie Dee 11 MarpmFri, 11 Mar 2016 12:44:30 +03002016-03-11T12:44:30+03:0012 2016, 12:44:30
12

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

  1. Методы связывают с ними условия pre и post (контракты).
  2. Объекты связаны с ними инвариантами.

Модульное рассуждение об объекте происходит следующим образом (по крайней мере, в первом приближении)

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

Представьте, что мы проверяем объект object A, используя описанный выше подход. И теперь вы хотите проверить метод method g объекта object B, который вызывает метод method f объекта object A. Модульные рассуждения позволяют нам рассуждать о методе method g, не пересматривая реализацию метода method f. Если мы можем установить инвариант object A и предварительное условие метода method f на сайте вызова в методе method g,, мы можем принять пост-условие method f как сводка поведения вызова метода. Более того, мы также будем знать, что после вызова возвращается инвариант A.

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

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

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

Защищенные поля

Защищенные поля восстанавливают часть нашей способности рассуждать модульно. В зависимости от языка protected может быть ограничена возможность установки поля для всех подклассов или всех подклассов и классов с одним классом. Часто бывает, что у нас нет доступа ко всем подклассам, когда мы рассуждаем о правильности объекта, который мы пишем. Например, вы можете написать компонент или библиотеку, которые позже будут использоваться в более крупной программе (или нескольких более крупных программах), некоторые из которых, возможно, еще не были написаны. Как правило, вы не будете знать, могут ли и каким образом быть подклассифицированы.

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

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

ответил flamingpenguin 11 MarpmFri, 11 Mar 2016 16:04:49 +03002016-03-11T16:04:49+03:0004 2016, 16:04:49
8

private переменные в классе лучше, чем protected по той же причине, что и оператор break внутри switch лучше, чем инструкция goto label; что человеческие программисты подвержены ошибкам.

protected переменные поддаются неназванному злоупотреблению (ошибки программиста), так же как и оператор goto поддается созданию спагетти-кода.

Можно ли написать рабочий код без ошибок, используя переменные класса protected? Да, конечно! Так же, как можно писать рабочий код без ошибок, используя goto; но поскольку клише идет «Просто потому, что вы можете, не значит, что вам нужно!»

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

Базовые классы не имеют абсолютно никакого знания о производных классах. Что касается базового класса, protected на самом деле не дает вам больше защиты, чем public, потому что нет ничего, что остановило бы производный класс на создании public getter /setter, который ведет себя как бэкдор.

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

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

В конечном счете, существуют языки высокого уровня для сведения к минимуму человеческих ошибок. Хорошие методы программирования (например, СОВЕРШЕННЫЕ принципы ) также существуют для сведения к минимуму человеческих ошибок.

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

ответил Ben Cottrell 11 MarpmFri, 11 Mar 2016 13:06:18 +03002016-03-11T13:06:18+03:0001 2016, 13:06:18
4

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

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

В качестве примера List<T> в .NET делает хранилище закрытым; если бы он был защищен, производные типы могли бы делать некоторые полезные вещи, которые в противном случае невозможны, но будущие версии List<T> могли бы навсегда использовать свой неуклюжий монолитный резервный магазин даже для списков, содержащих миллионы элементов , Создание частного хранилища резервных копий позволит будущим версиям List<T> использовать более эффективный резервный хранилище без разбиения производных классов.

ответил supercat 12 MaramSat, 12 Mar 2016 00:33:11 +03002016-03-12T00:33:11+03:0012 2016, 00:33:11
4

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

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

  1. У автора исходного класса были очень четкие идеи относительно того, почему он может быть расширен (например, это BaseFoo, и в будущем будет реализовано несколько конкретных реализаций Foo).

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

  1. Автор дочернего класса пытается взломать какое-то поведение в родительский класс.

Этот случай должен быть редок (вы можете утверждать, что это не является законным), и не рекомендуется просто модифицировать исходный класс в исходной кодовой базе. Это также может быть симптомом плохого дизайна. В таких случаях я предпочел бы, чтобы человек, взломавший поведение, просто использовал другие хаки, такие как друзья (C /C ++) и setAccessible(true) (Java).

Я думаю, что можно отбросить это предположение.

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

ответил Pace 12 MaramSat, 12 Mar 2016 01:51:23 +03002016-03-12T01:51:23+03:0001 2016, 01:51:23
2

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

  • сделать все переменные /элементы данных частными . Вы не хотите, чтобы кто-то извне возился со своими внутренними данными. Также методы, которые предоставляют вспомогательные функции (считайте вычисления на основе нескольких переменных-членов) для вашего общедоступного или защищенного интерфейса - это только для внутреннего использования, и вы можете захотеть изменить /улучшить его в будущем.
  • сделать общий интерфейс вашего класса общедоступным . Это то, с чем должны работать пользователи вашего первоначального класса, и как вы думаете, что производные классы также должны выглядеть. Чтобы обеспечить надлежащую инкапсуляцию, обычно это только методы (и вспомогательные классы /структуры, перечисления, typedefs, независимо от того, что пользователь должен работать с вашими методами), а не переменные.
  • объявить методы protected , которые могут быть полезны для тех, кто хочет расширить /специализировать функциональные возможности вашего класса, но не должен быть частью интерфейса public на самом деле вы обычно поднимаете частных участников на protected , когда это необходимо. Если вы сомневаетесь, вы этого не сделаете, пока не узнаете, что
    1. ваш класс может /может /будет подклассифицирован,
    2. и иметь четкое представление о возможностях использования подкласса.

И вы отклоняетесь от этой общей схемы только в том случае, если есть хорошая причина ... . Остерегайтесь «это облегчит мою жизнь, когда я могу свободно обращаться к ней извне» (и здесь также включает подклассы). Когда я реализую иерархии классов, я часто начинаю с классов, у которых нет защищенных членов, пока я не перейду к подклассу /расширению /специализации, став базовыми классами фреймворка /инструментария и иногда перемещая часть их первоначальной функциональности на один уровень вверх.

ответил Murphy 12 MaramSat, 12 Mar 2016 02:50:15 +03002016-03-12T02:50:15+03:0002 2016, 02:50:15
1

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

Несколько языков (например, Ruby и Smalltalk) не предоставляют публичные поля, поэтому разработчикам не рекомендуется позволять прямое взаимодействие с их реализациями классов, но почему бы не пойти дальше и иметь только частные поля? Не было бы потери общности (потому что суперкласс всегда может обеспечить защищенные аксессоры для подкласса), но он будет обеспечивать, чтобы классы всегда имели по крайней мере небольшую степень изоляции от своих подклассов. Почему это не более общий дизайн?

ответил Jules 12 MarpmSat, 12 Mar 2016 18:58:14 +03002016-03-12T18:58:14+03:0006 2016, 18:58:14
1

Здесь много хороших ответов, но я все равно вложу свои два цента. : -)

Частный работает по той же причине, что глобальные данные плохие.

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

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

ответил Jay 14 MaramMon, 14 Mar 2016 07:29:31 +03002016-03-14T07:29:31+03:0007 2016, 07:29:31
1

Я думаю, что стоит упомянуть некоторые несогласные мнения.

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

На практике слишком часто при просмотре кода я вижу людей (которые любят использовать частные), меняя уровень доступа с частного -> защищен и не слишком часто защищен -> общественности. Почти всегда изменение свойств класса связано с модификацией сеттеров /геттеров. Они потратили много времени (обзор кода) и их (изменение кода).

Также меня раздражает, что это означает, что их классы не закрыты для модификации.

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

Итак, сколько программистов думает, что это хлопот? Ну, сколько из них используют языки программирования, которые не имеют частных? Конечно, люди не просто используют эти языки, потому что у них нет частных спецификаторов, но это помогает упростить языки, и простота важна.

Имо очень похож на динамическую /статическую типизацию. Теоретически статическая типизация очень хороша. На практике это предотвращает только 2% ошибок Необоснованную эффективность динамического ввода. .. . Использование private, вероятно, предотвращает ошибку.

Я думаю, что принципы SOLID хороши, я хочу, чтобы люди заботились о них больше, чем они заботились о создании класса с публичными, защищенными и частными.

ответил imel96 14 MarpmMon, 14 Mar 2016 13:27:32 +03002016-03-14T13:27:32+03:0001 2016, 13:27:32
0

Я также хотел бы добавить еще один практический пример того, почему protected недостаточно. В моем университете первые годы берут на себя проект, когда им приходится разрабатывать настольную версию настольной игры (которая позже разрабатывается ИИ и подключается к другим игрокам по сети). Некоторый частичный код предоставляется им, чтобы запустить их, включая среду тестирования. Некоторые из свойств основного игрового класса отображаются как protected, так что классы тестов, которые расширяют этот класс, имеют к ним доступ. Но эти поля не являются конфиденциальной информацией.

Как TA для подразделения, я часто вижу, что студенты просто делают все свои добавленные коды protected или public (возможно, потому, что они видели другой protected и public, и предположил, что они должны последовать их примеру). Я спрашиваю их, почему их уровень защиты неуместен, и многие не знают, почему. Ответ заключается в том, что конфиденциальная информация, которую они подвергают подклассам, означает, что другой игрок может обманывать, просто расширяя этот класс и получая доступ к высокочувствительной информации для игры (по сути, скрытое местоположение противников, я думаю, похоже на то, как это было бы, если бы вы мог видеть ваши фигуры противников на борту линкоров, расширяя класс). Это делает их код очень опасным в контексте игры.

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

ответил J_mie6 12 MaramSat, 12 Mar 2016 01:55:12 +03002016-03-12T01:55:12+03:0001 2016, 01:55:12
0

Частные методы /переменные обычно скрываются от подкласса. Это может быть хорошо.

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

Защищенный метод должен входов проверки работоспособности.

ответил Phil Lello 13 MarpmSun, 13 Mar 2016 22:31:23 +03002016-03-13T22:31:23+03:0010 2016, 22:31:23
-1

«private» означает: Не предназначено для изменения или доступа кем-либо, кроме самого класса. Не предназначено для изменения или доступа по подклассам. Подклассы? Какие подклассы? Вы не должны подклассифицировать это!

«protected» означает: Только предназначено для изменения или доступа к классам или подклассам. Вероятно, вы считаете, что вы должны подкласс, иначе почему «защищен», а не «частный»?

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

ответил gnasher729 12 MarpmSat, 12 Mar 2016 15:08:47 +03002016-03-12T15:08:47+03:0003 2016, 15:08:47
-1
  

Одна из первых вещей, которые я делаю, когда я подклассифицирую класс, - это изменить   куча частных методов для защиты

Некоторые аргументы в отношении private vs. protected методов :

private методы предотвращают повторное использование кода. Подкласс не может использовать код в приватном методе и может потребоваться его повторное внедрение - или повторно реализовать метод (ы), который изначально зависит от частного метода & c.

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

Это плохо? - Я так не думаю.

Конечно, (псевдо) открытый API блокирует первоначальный программист и препятствует рефакторингу этих интерфейсов. Но если смотреть наоборот, почему программист не разрабатывает свои «детали реализации» таким же чистым и стабильным, как и его публичный API? Должен ли он использовать private, чтобы он мог небрежно структурировать свой «частный» код? Может быть, подумать, что он может убрать его позже, потому что никто не заметит? - Нет.

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

Много (фреймворк) кода, который я вижу, использует непоследовательное использование private: protected, не конечные методы, которые едва ли делают что-то большее, чем делегирование частному методу обычно обнаруживается. protected, не конечные методы, контракт которых может быть выполнен только через прямой доступ к закрытым полям.

Эти методы не могут быть логически переопределены /расширены, хотя технически нет ничего, что могло бы сделать это (компилятор) очевидным.

Хотите расширения и наследования? Не делайте ваши методы private.

Не хотите ли изменить поведение вашего класса? Сделайте ваши методы final.

Неужели не может быть вызван ваш метод за пределами определенного, четко определенного контекста? Сделайте свой метод private и /или подумайте о том, как вы можете сделать требуемый четко определенный контекст доступным для повторного использования с помощью другого метода оболочки protected.

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

Для полей private не очень плохо. Пока поле (ы) можно разумно «использовать» с помощью соответствующих методов (это not getXX() или setXX()!) .

ответил JimmyB 11 MarpmFri, 11 Mar 2016 16:47:08 +03002016-03-11T16:47:08+03:0004 2016, 16:47:08
-1
  

Знаете ли вы о важном прецеденте, когда частный, а не   защищенный - хороший инструмент, или два варианта «защищенные и общедоступные» будут   достаточно для языков ООП?

Частный : когда у вас есть что-то, что никогда не будет полезно для любого подкласса для вызова или переопределения.

Защищенный : если у вас есть что-то, что имеет реализацию /константу подкласса.

Пример:

public abstract Class MercedesBenz() extends Car {
  //Might be useful for subclasses to know about their customers
  protected Customer customer; 

  /* Each specific model has its own horn. 
     Therefore: protected, so that each subclass might implement it as they wish
  */
  protected abstract void honk();

  /* Taken from the car class. */
  @Override
  public void getTechSupport(){
     showMercedesBenzHQContactDetails(customer);
     automaticallyNotifyLocalDealer(customer);
  }

  /* 
     This isn't specific for any subclass.
     It is also not useful to call this from inside a subclass,
     because local dealers only want to be notified when a 
     customer wants tech support. 
   */
  private void automaticallyNotifyLocalDealer(){
    ...
  }
}
ответил Arnab Datta 18 MarpmFri, 18 Mar 2016 13:12:21 +03002016-03-18T13:12:21+03:0001 2016, 13:12:21
-2

Мне было трудно понять этот вопрос, поэтому я хотел бы поделиться своим опытом:

  • Что такое защищенная область? Это не более , чем поле, к которому нельзя получить доступ за пределами класса, т. Е. публично , как это: $classInstance->field. И трюк, что это «это он». У ваших детей класса будет доступ к нему полный , потому что это их законная внутренняя часть.
  • Что такое частный ? Это true private для вашего собственного класса и для вашей собственной реализации этого класса. «Хранить в недоступном для детей месте», точно так же, как на бутылке с лекарством. У вас будет гарантия, что он будет недоступен для ваших производных, ваших методов - при вызове - будет иметь точный то, что вы объявили

ОБНОВЛЕНИЕ: практический пример реальной задачи, которую я решил. Вот он: у вас есть токен, например USB или LPT (это был мой случай), и у вас есть промежуточное программное обеспечение. Токен спрашивает вас о pincode, открывается, если это правильно, и вы можете отправить зашифрованную часть и несколько ключей для расшифровки. Клавиши хранятся в токене, вы не можете их прочитать, используйте их только. И были временные ключи для сеанса, подписанные ключом в токене, но хранящиеся в промежуточном программном обеспечении. Клавиша temp не должна была течь evey где-то снаружи, просто чтобы существовать на уровне драйвера. И я использовал частные поля для хранения этого временного ключа и некоторых связанных с аппаратным соединением данных. Таким образом, никакие производные не могли использовать не только открытый интерфейс, но и некоторые защищенные «подпрограммы», которые я выполнил для задачи, но не смогли открыть ящик с ключами и взаимодействие с HW. Имеет смысл?

ответил Alexey Vesnin 11 MarpmFri, 11 Mar 2016 23:24:38 +03002016-03-11T23:24:38+03:0011 2016, 23:24:38

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132