Здравствуйте, Igor Trofimov, Вы писали:

iT>IoC — это только способ вынесения зависимости в другое место. Какие это зависимости — по-прежнему зависит от тебя.
iT>И плюсы/минусы этих зависимостей остаются теми же.

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

Здравствуйте, adontz, Вы писали:

C>>Именно. Твои синглтоны ЗНАЮТ что, с ними "have occurred previously" — они знают про свои параметры инициализации, в частности.
A>Не-не, инициализация, очевидно, не в счёт. Иначе stateless объектами будет только константный мусор в памяти. Имеется ввиду только то что occured после инициализации и до текущего момента.
Именно. Stateless-объектов почти не существует (они бесполезны). У любого полезного объекта есть состояние, которое может за время жизни меняться или не меняться.

Бывают stateless-сервисы (т.е. логические сущности), которые при этом состоят из вполне себе stateful-объектов.

C>>Соответственно, у твоих "stateless"-синглтонов ровно те же проблемы, что и у "обычных".
A>Какие например? Методы можно дёргать откуда угодно и в любом порядке, какие тут могут быть проблемы?
Глобальность.

Здравствуйте, IT, Вы писали:

IT>>>А в Spring конфигуратор как реализован? Как синглетон? Или он конфигурируется другой внешней системой конфигурации?
C>>Как угодно. Например, ты можешь его положить в theadlocal-переменную, впрыскивать его в объекты или передавать явно.
IT>Т.е. на каждую поток у нас будет по одному конфигуратору? В чём смысл?
Бывает нужно иногда (я не говорю, что это очень хороший паттерн). Например, если надо передать конфигуратор через слой, который мы не контролируем, и в который мы не можем нормально его воткнуть.

IT>>>Кто их должен передавать?
C>>Объект, создающий данный объект.
IT>А кто будет создавать объект, создающий данный объект?
Объект, который будет создавать объект, который будет создавать объект. И так рекурсивно до функции main().

Здравствуйте, Cyberax, Вы писали:

C>Бывают stateless-сервисы (т.е. логические сущности), которые при этом состоят из вполне себе stateful-объектов.

по-моему, ты перемудрил.

C>Глобальность.

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

Здравствуйте, adontz, Вы писали:

C>>Бывают stateless-сервисы (т.е. логические сущности), которые при этом состоят из вполне себе stateful-объектов.
A>по-моему, ты перемудрил.
Не знаю. Просто stateless-объекты для меня больше похоже на нонсен.

C>>Глобальность.
A>Вообще-то синглтон затевался из-за глобальной точки доступа, так что называть глобальность недостатком достаточно странно.
Вот эта глобальность — и есть плохо. Я вообще предпочитаю всегда передавать все необходимые для вычисления данные в локальном контексте.

Здравствуйте, adontz, Вы писали:

A>Бумажное издание за 2006 год у меня на столе, так что видел, даже внутрь заглядывал.
Значит все-таки сознание изменяет что-то другое..

A> Для меня достаточно очевидно, что код делает тоже самое, что в книжке и при этом на порядок лучше.
Я тебе уже объяснил, почему ты заблуждаешься.. )

A>Нет, она перестаёт быть фабрикой.
С какой стати?

A>Жжёшь. Иван, ты похоже попросту не знаешь паттерна Factory Method.
Ну давай посмотрим, кто чего не знает "Factory Method — Define an interface for creating an object." Все, точка. Про то что object должен реализовывать какие-то интерфейсы не сказано ни слова. Рома, ты определенно читаешь либо не тот GoF, либо странным способом.

A>Обсуждать что-либо с тобой, соответственно, абсолютно бесполезно.


A>Factory Method порождает реализации для интерфейсов, не важно сколько реализций, важно что все они реализуют некоторый интерфейс.
Вот это как раз, абсолютно не важно, для того чтобы называться "фабричным методом", совершенно не обязательно порождать объекты реализующие определенный интерфейс. Берем твой любимый C++, там нет нарошной сущности для декларации публичного контракта, а значит любая фабрика все равно завязана на конкретный класс.

Ну да фиг с ним. Это все буквоедство и словоблудие, важно другое. Бедулька в том, что ты не знаешь общепринятой терминологии и в место того, чтобы просто уточнить и согласовать набор терминов, становишся в неимоверно пафосную позу и начинаешь спорить не разобравшись.
В данном случае твое заблуждение состоит в том, что ты не в курсе довольно известного факта: the term factory method is often used to refer to any method whose main purpose is creation of objects. И именно в этом смысле я употреблял термин "фабрика" (самостоятельная сущность, задача которой порождать объекты, конкретный паттерн factory method здесь вообщем-то не причем), и понятно это было вообщем-то всем, кроме, как выяснилось, тебя.

A>1. Отрицаешь возможность реализации stateless синглтонов.
Хм.. Смотря что иметь ввиду под stateless. Через твою терминологию я боюсь не продраться.

A>2. Не понимаешь паттерна Factory Method
Здесь, я надеюсь, ты уже осознал свое заблуждение. Можешь не извеняться..

A> и путаешь с ним Си++ код выше в этом сообщении.
Это ты путаешь, про связность сишных френдов я тебе уже рассказывал..

A>Все три пункта страшное заблуждение.
Поправочка. Все три пункта — твое страшное заблуждение..

A> Люди годами инкапсулировали, а пришёл добрый дядя Ваня и раскапсулировал всё нафиг, потому что нефиг
Новый термин выучил? Перечитай еще раз внимательно, что это такое, а главное, для чего его используется и медитируй над тем, зачем придумали паттерн IoC... Осознаешь — приходи..

Здравствуйте, Igor Trofimov, Вы писали:

iT>Конечно! Он позволяет создать еще один экземпляр, что увеличивает количество на 1.
Ну тебе-то, надеюсь, не надо разжевывать, что означает слово "контроль"?

iT>И что — это не будет похоже на глобальную переменную в плане разделения состояния?
Нет, не будет.

iT>IoC — это только способ вынесения зависимости в другое место.
Угу. В то место, где я могу явным образом контролировать эти зависимости.

iT>И плюсы/минусы этих зависимостей остаются теми же.
Минусов заметно меньше.

iT>Теперь здесь. Я надеюсь, ты не включаешь в понятие "публичного контракта класса" конфиг IoC, в котором написано, какие компоненты нужно к нему прицепить?
Дело не в публичном контракте, а в том, что существует место где можно явно увидеть все зависимости и поменять их не трогая код реализации, если возникнет такая необходимость.

iT>Если проблема проявляется не только в синглтоне, то не нужно приписывать ее синглтону как таковому,
Вот странный ты. А кому же еще ее приписывать? Синглтон обладает очевидным недостатком => синглтон плохой. Даже если кто-то еще обладает этим недостатком синглтон от этого лучше не станет.

iT>Именно. Вешай ярлыки, но осторожно
Можешь привести цитату, где я повесил на синглтон ярлык?

Здравствуйте, Константин Л., Вы писали:

КЛ>неправда. adontz уже показал почему.
Гм.. Повторить сможешь? Увы, но Роме это не удалось...

КЛ>А почему мы не знаем его текущее состояние? Че за лажа?
Господи, ну что за манеры... Выйди из класса, и зайди как учили.
"- Иван Дмитриевич, объясните пожалуйста, почему нам не очевидно состояние глобальной переменной". Давай, я жду... Дневник оставь.

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

Здравствуйте, IB, Вы писали:

A>>Жжёшь. Иван, ты похоже попросту не знаешь паттерна Factory Method.
IB>Ну давай посмотрим, кто чего не знает "Factory Method — Define an interface for creating an object." Все, точка. Про то что object должен реализовывать какие-то интерфейсы не сказано ни слова. Рома, ты определенно читаешь либо не тот GoF, либо странным способом.

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

Паттерн Factory Method

Название и классификация паттерна

Фабричный метод — паттерн, порождающий классы.

Назначение

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

Известен также под именем

Virtual Constructor (виртуальный конструктор).

Для тех кто в танке, я ключевые моменты выделил.

A>>Factory Method порождает реализации для интерфейсов, не важно сколько реализций, важно что все они реализуют некоторый интерфейс.
IB>Вот это как раз, абсолютно не важно, для того чтобы называться "фабричным методом", совершенно не обязательно порождать объекты реализующие определенный интерфейс.

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

IB>Ну да фиг с ним. Это все буквоедство и словоблудие, важно другое. Бедулька в том, что ты не знаешь общепринятой терминологии и в место того, чтобы просто уточнить и согласовать набор терминов, становишся в неимоверно пафосную позу и начинаешь спорить не разобравшись.

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

IB>В данном случае твое заблуждение состоит в том, что ты не в курсе довольно известного факта: the term factory method is often used to refer to any method whose main purpose is creation of objects. И именно в этом смысле я употреблял термин "фабрика" (самостоятельная сущность, задача которой порождать объекты, конкретный паттерн factory method здесь вообщем-то не причем), и понятно это было вообщем-то всем, кроме, как выяснилось, тебя.

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

IB>Хм.. Смотря что иметь ввиду под stateless. Через твою терминологию я боюсь не продраться.

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

A>>2. Не понимаешь паттерна Factory Method
IB>Здесь, я надеюсь, ты уже осознал свое заблуждение. Можешь не извеняться..

Можешь и дальше юродствовать, если по существу сказать нечего.

A>> и путаешь с ним Си++ код выше в этом сообщении.
IB>Это ты путаешь, про связность сишных френдов я тебе уже рассказывал...

На мой взгляд излишней связности нет, а если есть то покажи.

A>> Люди годами инкапсулировали, а пришёл добрый дядя Ваня и раскапсулировал всё нафиг, потому что нефиг
IB>Новый термин выучил? Перечитай еще раз внимательно, что это такое, а главное, для чего его используется и медитируй над тем, зачем придумали паттерн IoC... Осознаешь — приходи..

IoC это не паттерн, хотя вряд ли ты это понимаешь...

Здравствуйте, adontz, Вы писали:

A>ага, пошло цитирование неизвестно чего, неизвестно откуда,
Известно чего..

A>лишь бы не признать своей неправоты.
Лишь бы до тебя хоть что-то донести. Тебе уже пора бы приплачивать мне за науку..

A>Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать. Фабричный метод позволяет классу делегировать инстанцирование подклассам.
....
A>Учи матчасть, порождать объекты реализующие определенный интерфейс очень даже объязательно. Цитаты выше.
Я прям даже теряюсь... Ты сам-то хоть понял, что процитировал и что сказал? В твоей цитате речь про фабричный метод, то есть, про порождающую сущность, а пишешь ты про интерфейс порождаемой сущности... Это даже не теплое с мягким, это просто винегрет какой-то.

A>Для тех кто в танке, я ключевые моменты выделил.
Да. Те кто в танке сказали ровно тоже что и я, но, очевидно, не разобравшись, по запарке.
Еще раз, по буквам, это если в танке люк заварен. Есть порождающая сущность (фабрика), есть порождаемая (объект). Смысл конкретно паттерна "фабричный метод" предоставить интерфейс фабрики для создания объекта. Об этом же и говорит второе название "виртуальный конструктор", понимаешь, конструктор виртуальный, а не объект.
Это если формализмом заниматься. Реально, как я уже говорил, в данном определении "интерфейс" понятие довольно условное, и в некоторых языках "из-за их убогости/недоразвитости"(с) недостижимое.

A>Я по крайне мере умею читать
Рома, прости, но вот данное утверждение после ряда дискуссий с тобой, вызывает очень серьезные сомнения в своей истинности. У меня суровое подозрение, что ты себе льстишь..

A>Забавно, когда дело касается синглтона ты занимаешься буквоедством,
Остаюсь верен себе, просто называю вещи своими именами..

A> а когда фабричного метода довольно свободно трактуешь.
Фабричного метода я вообще не касался, это ты про него речь завел. Да и трактовка не моя, а википедии, что касается общепринятого мнения — это достаточно надежный источник. Так что все претензии туда, если общепринятое определение, почему-то не совпадает с твоим.

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

A>На мой взгляд излишней связности нет, а если есть то покажи.
Доступ к приватным полям тебя не смущает? А кто тут дефирамбы инкапсуляции пел?

A>IoC это не паттерн, хотя вряд ли ты это понимаешь...
"- Малчик?
— Нет.
— А кто?!!"
Ок, буквоед ты наш, назови это "архитектурный принцип", на вопрос-то можешь ответить?

Здравствуйте, IB, Вы писали:

A>>Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать. Фабричный метод позволяет классу делегировать инстанцирование подклассам.
IB>....
A>>Учи матчасть, порождать объекты реализующие определенный интерфейс очень даже объязательно. Цитаты выше.
IB>Я прям даже теряюсь... Ты сам-то хоть понял, что процитировал и что сказал? В твоей цитате речь про фабричный метод, то есть, про порождающую сущность, а пишешь ты про интерфейс порождаемой сущности... Это даже не теплое с мягким, это просто винегрет какой-то.

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

Применимость

Используйте паттерн фабричный метод, когда:

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

IB>Еще раз, по буквам, это если в танке люк заварен. Есть порождающая сущность (фабрика), есть порождаемая (объект). Смысл конкретно паттерна "фабричный метод" предоставить интерфейс фабрики для создания объекта. Об этом же и говорит второе название "виртуальный конструктор", понимаешь, конструктор виртуальный, а не объект.

см цитату выше.

A>>На мой взгляд излишней связности нет, а если есть то покажи.
IB>Доступ к приватным полям тебя не смущает? А кто тут дефирамбы инкапсуляции пел?

template <typename T>
class singleton
{
    public:
        static const T & get_instance()
        {
            static T instance;
            
            return instance;
        }
};

class worker
{
    friend singleton<worker>;
    
    private:
        worker()
        {
        }
};

singleton<worker> s;
    
const worker & w = s.get_instance();

Где тут доступ к приватным полям? Тут полей вообще нет. Доступ из singleton<worker> к приватному конструктору worker::worker() это фича, а не недостаток.

IB>Ок, буквоед ты наш, назови это "архитектурный принцип", на вопрос-то можешь ответить?

Если по простому, IoC придумали чтобы избежать циклических зависимостей, для разрешения которых приходится, обычно, порождать лишние модули (попутно, там, обычно, особенности реализации наружу торчат). IoC бывает двух видов, dependecy injection и колбеки.

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

node * get_first();
node * get_next();
data * get_data(node *);

породив помимо модулей linked_list и application, модуль linked_list_declarations описывающий тип node от которого зависят linked_list и application, а могу как

enumerate_nodes(bool (* enum_proc)(data *));

и это очевидно лучше, потому что

1. Клиент больше не зависит от типа node.
   
2. Нет вспомогательных модулей.
   
3. Клиент больше не доступны несущественные детали реализации.

Dependency injection ИМХО зло, я уже говорил, что кортежи внедрённых зависимостей в параметрах каждого метода (запоминать нельзя, мало ли...) ни к чему хорошему не приводит. Настроили журналирование в файл на самом высоком уровне (функция main если угодно) и давай этот объект тащить до низу. Особенно весело, если раньше журналирования не было и надо весь проект переписать, чтобы оно вдруг было. Так как весь проект переписывать лень, появляются хаки (всякие thread local переменные, описанные Cyberax). В этом смысле singleton выглядет куда привлекательнее, так как позволяет добавлять в нижние уровни функциональность контроллируемую в верхних уровнях, не протаскивая её через все промежуточные уровни.
Callback'и на мой взгляд более приемлемое решение (особенно делегатами), но практическая реализация нередко затруднена. Кроме того этот самый указатель/делегат надо опять таки передать через все уровни и реальная разница в сложности реализации и поддержки между Dependency injection и Callback стирается.
В целом вырисовывается следующая картина:

// singleton
void level3()
{
    singleton<logger>::log("level 3!");
}
void level2()
{
    level3();
}
void level1()
{
    level2();
}
int main()
{
    singleton<logger>::initialize(bla-bla-bla);
    level1();
}
// dependency injection
void level3(logger log)
{
    log.log("level 3!");
}
void level2(logger log)
{
    level3(log);
}
void level1(logger log)
{
    level2(log);
}
int main()
{
    logger log;

    log.initialize(bla-bla-bla);

    level1(log);
}

Нередко level1 и level2 написаны вообще не мной, это может быть, например, код какой-то библиотеки которая вызывает level3 как callback. В такой ситуации синглтон оказывается очень кстати.
Сервисы это круто, особенно их .Net реализация с автоматическим приведением типов, но эти сервисы надо где-то регистрировать и откуда-то брать. А когда начинаешь думать где регистрировать, откуда брать... Хорошо если есть главный объект-контейнер, а если нет такого объекта?

Здравствуйте, adontz, Вы писали:

A>В целом вырисовывается следующая картина:

А так?

void level3()
{
    log.log("level 3!");
}
void level2()
{
    level3();
}
void level1()
{
    level2();
}

logger log;

int main(logger pLog)
{
    log = pLog;
    level1();
}

Здравствуйте, adontz, Вы писали:

A>Вообще-то синглтон затевался из-за глобальной точки доступа, так что называть глобальность недостатком достаточно странно.

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

Здравствуйте, IB, Вы писали:

Могу предложить решение как уббрать сингелтон из глобального поля видимости.

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


P,S, Сингелтоны не использую и не защищаю .

Здравствуйте, IT, Вы писали:

IT>А так?

void level3()
{
    log.log("level 3!");
}
void level2()
{
    level3();
}
void level1()
{
    level2();
}

logger log;

int main(logger pLog)
{
    log = pLog;
    level1();
}

Так не скомпилируется, у функции main параметрами могут быть только (int argc, char ** argv)

logger log;

void level3()
{
    log.log("level 3!");
}
void level2()
{
    level3();
}
void level1()
{
    level2();
}

int main( pLog)
{
    logger log;

    log.initialize(bla-bla-bla);

    level1(log);
}

Тоже не будет работать. level1, level2, level3 будут в разных единицах компиляции и иметь общую глобальную переменную им не светит.

Здравствуйте, minorlogic, Вы писали:

A>>Вообще-то синглтон затевался из-за глобальной точки доступа, так что называть глобальность недостатком достаточно странно.
M>А я думал чтобы обеспечить единственность экземпляра.

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

Паттерн Singleton

Назначение

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

Применимость

Используйте паттерн одиночка, когда:

• должен быть ровно один экземпляр некоторого класса, легко доступный
  всем клиентам;
  
• единственный экземпляр должен расширяться путем порождения подклас-
  сов, и клиентам нужно иметь возможность работать с расширенным экземп-
  ляром без модификации своего кода.

учи матчасть.

Похоже что ты даже то что сам написал не читаеш. Прочти еще раз назначение патерна.

И ты серьезно считаешь что доступность можно обеспечить только через глобальность ? Учи матчасть , примерно с основ структурного програмирования.

Здравствуйте, minorlogic, Вы писали:

M>И ты серьезно считаешь что доступность можно обеспечить только через глобальность?

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

Здравствуйте, adontz, Вы писали:

M>>И ты серьезно считаешь что доступность можно обеспечить только через глобальность?

A>Нет не думаю, это твои бредовые слова не мои. Доступно можно ещё, например, через broadcast сообщения о поиске обеспечить (если конечно есть некоторая общедоступная система обмена сигналами).

Тогда прочти предыдущий свой пост , где ты пишешь про голобальность.

Здравствуйте, minorlogic, Вы писали:

M>Тогда прочти предыдущий свой пост , где ты пишешь про голобальность.

И что там не так?