Закрыть private переменные

Добрый день!

А есть ли способ закрыть возможность вывода приватных переменных объекта через print_r(), да и var_dump() и любым другим способом тоже?

Ну, т.е. не хочу, чтобы закрытые переменные класса можно было считать таким способом. __set_state(), __debugInfo() знаю. __debugInfo() только начиная с 5.6 работает. К тому же вряд ли она закроет print_r().

Нафига?
Говнокод прятать?

-----
Шта? Репозиторий?

Я давно заметил, что у части разработчиков с опытом развивается самокритика.

Но это не ответ на вопрос. Это даже не попытка... Потому что вопрос ты не понял. Ты можешь с помощью var_dump или print_r прочитать код?

Вопрос в том, зачем создавать private переменные, если их можно считать? Функцию ты не запустишь, а переменные - пожалуйста, вот они. В чем тогда смысл делать их приватными? Для чего разработчики php делили переменные на public, protected и private? Только, чтобы их нельзя было изменить?

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

(Отредактировано автором: 26 Апреля, 2015 - 14:31:35)

Ну вы бы ещё про сериализацию вспомнили. Там можно даже менять приватные переменные, не то что читать из значения.
А уж про возможность менять приватные члены в рантайме тупым closure::bindto я даже не говорю.
Если человек захочет сделать глупость - он её сделает. Поэтому не занимайтесь борьбой с ветряными мельницами. Если хочется влезть в потроха - это сделают.

-----
PostgreSQL DBA

Не. Это не борьба с мельницами. Я как раз спросил, чтобы понять - это мельница или нет?

Ну, и вопрос просто логики. Для чего нужны private переменные? В чем их суть?
(Добавление)


А static переменные можно каким-то способом считать?

Вот с этого стоило начинать.
Что бы это понять, нужно полнимать ООП, и в первую очередь - инкапсуляцию.
Можно начать с википедии https://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)

-----
self-banned

По-моему, вопрос как раз вызван тем, что подобное поведение противоречит принципам инкапсуляции:

Encapsulation can be used to hide data member and member function. Under this definition, encapsulation means that the internal representation of an object is generally hidden from view outside of the object's definition.

Я не прав?

Я все прекрасно понял. А Мелкий озвучил это явно.
Если нужно сокрытие кода ядра, только с предоставлением апи -- используй ион-куб и/или зенд-гвард.

-----
Шта? Репозиторий?

Мне не нужно сокрытие кода. Мне нужно сокрытие данных объекта. Кмк, ты путаешь класс и объект.

(Отредактировано автором: 26 Апреля, 2015 - 15:48:07)

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

-----
Шта? Репозиторий?

Читайте уж все ;)
Потом осмыслить неплохо бы.

-----
self-banned

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

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

Вывод 2. Вернее предположение. Переменные не будут видны извне:
- только внутри scope функции (традиционно)
- или если они объявлены внутри класса как private static (вот это как раз предположение), я во всяком случае не нашел способа к таким переменным продолбиться. Например,

Вопрос скрыть от всех что-то, он вообoе не вопрос языка программирования, это вопрос алгоритмов.

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

Есть, например, питон - неплохой ООП язык, в котором нет встроенных конструкций типа private/protected. И там неплохо обходятся соглашениями в наименованиях функций (подчеркивание перед названием).

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

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

(Отредактировано автором: 26 Апреля, 2015 - 20:29:33)

-----
self-banned

Да, можно.
Для 5.3, емнип, runkit даст делать глупости. Скорей всего рефлексия даст делать глупости.

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

-----
PostgreSQL DBA

(Добавление)


Спасибо! Щас все встало на свои места. Перестану донкихотствовать и начну жить