Почитай про петтерн синглтон - самый банальный и простой пример.

угу. вот тут понятно описан этот паттерн
http://www.irbis-team.com/15/23/1

А зачем нужно прятать как private статический член экземлпяра класса? Т.е. есть функция с помощью которой дается доступ к экземпляру класса, а зачем его скрывать с помощью private инкапсуляции? Просто те кто его используют наверняка знаю что нужно получать доступ через a::getInstance().
Или здесь имеется ввиду что инкапсуляция это как бы доступ к переменной через функцию, т.е. это инкапсуляция не в смысле применения private?

program90
Получить да, а вот изменить не смогут. В это суть этого паттерна.

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

Arni

program90
Объектов создается именно столько сколько ты сам создашь.

twin
Опрометчиво разрушать фундамент здания, если рухнет - по голове начальство не погладит.

Так получается что инкапсуляция нужна только для того чтобы программист не ошибся и ему было проще писать, обращаться с переменными? Только для этого? Может быть Страуструп придумал это не только для этого?...

Мериться объемом кода, всёравно что мериться пиписьками, у индусов всёравно длиннее.

linker
))))))Да. точно!

Arni
Написано, что в Javascript при создании объектов через prototype экономится память

Добавлю от себя немного
ООП предоставляет полиморфизм и др. свойства, так же дают большой инструмент для "сокрытия" сложных алгоритмов и возможных изменений как в архитектуре так и в требованиях от заказчика, что даёт безопасно изменять код и даже алгоритмы в работе определённых функций.
Ну а теперь к инкапсуляции переменной.
Вспомним что, если проект имеет большое количество кода (десятки тысяч строк, да ещё и в разных файлах), имеет так же и глобальные переменные, которые могут неожиданно себя повести, в зависимости от их использования. Решение проблемы в этом случае будет обходится на много дороже если эти данные не инкапсулировать в одном - двух классах, где легче и быстрее найти ошибку, а так же проследить логику использования переменной даже для непосвящённого во всю архитектуру программиста.
Возьмём случай с инкапсуляцией в функциях.
Переменные будут доступны только в пространстве функции (а это уже хардкод и уменьшает гибкость логики архитектуры в разы) и если эти данные понадобятся в других не связанных функциях их нужно либо заново воспроизводить ну или же делать глобальными.
Вот и вернулись в начало
С ув. Greg1978

Greg1978
Спасибо

А мне нравится private, public, как то структурированно всё, создается некая иерархия в классах. В которых всё красиво описанно, что можно внешне брать, что нельзя.
Инкапсуляция - это как в капсуле. Т.е к примеру есть класс Car там есть куча методов, и свойств как приватных, так и публичных. Например чтобы завести машину, нужно у обьекта вызвать какой то метод. Но для работы этого метода в классе например можно создать ещё приватные методы, например: Подать электросигнал,отдать топливо, и т.п. Может при других ситуациях не надо полностью заводить машину а просто включить дворники. Тогда в паблик методе вызывать приватный метод - подать электросигнал (ведь нельзя из обьекта просто подать электросигнал), и т.д. Анологично и свойства. И всё это хозяйство инкапсулировано. А дальше создаешь хоть завод по сборке автомобилей.
Берёшь и аккуратненько складываешь классы в свою супер библиотеку. Так и собираешь свой автомобиль
Для этого они и создавались, наверно)

fallow
Спасибо!

Спасибо

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

Синглтон аналог глобальной переменной???

ExpJ
Чтобы подобную фигню больше не писать нужно разобраться в обоих вопросах. А то услышали звон, да не знаете где он.

ExpJ по сути то прав. Дело в том, что ООП в своей идее опирается на локализацию функционала. А не всегда это выгодно и интересно. И вот, вместо того, чтобы пользоваться обычным глобальным пространством, и был придуман этот костыль - синглетон. Потому как общим пространством пользоваться вера не позволяет.

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

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

Мало того, отследить состояние свойства объекта синглетон несколько сложнее, чем состояние переменной в глобальном пространстве. Поясню.

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

$CONFIG = array( 'password' => '12345',
.........

Когда в тексте программы встречаются такие переменные, сразу понятно - где то они используются с конструкцией global и изменять их не след. Только для чтения. А свойство объекта синглетон обозначить так нельзя, ибо они все такие.

Так что не все то золото, что блестит.

Вся проблема в том, что глобальные переменные - они супер глобальные. Их может изменять, удалять, создавать кто угодно, когда угодно и где угодно. В результате появляется неразбериха и тот самое чувство отвращения к глобальным данным. Суть синглтона в том, чтобы никто, нигде и никогда не смог подменить значение этой "глобальной" сущности. А теперь twin под раздачу попадёт:

class DB
{
    private static $_instance = null;
    private $link = null;
    
    private function __construct()
    {
        $this->link = mysql_connect(...);
    }

    private function __clone() {}

    public function __destruct()
    {
        mysql_close($this->link);
    }

    public static function getInstance()
    {
        return self::$_instance instanceof self ? self::$_instance : self::$_instance = new self();
    }

    public static function destroy()
    {
        self::$_instance = null;
    }
}

$o = DB::getInstance();
unset($o); // Так убивается только ссылка, а не оригинальный объект
DB::destory(); // А вот так убиваем синглтон
DB::getInstance(); // А так опять создаём и получаем его

Как можешь заметить, закрытие соединения происходит в деструкторе оригинального объекта, а следовательно при любом первом попавшемся DB::getInstance() соединение вновь будет открыто и плевать в каком месте приложения был вызван DB::destroy(), мы всегда получаем нужный нам объект со всеми нужными соединениями.