MVK>Прочитал всю ветку. Адепты использования синглетонов — в частности впечатление таковых создают kuj и ArtDenis — в начаде своих рассуждений об удобоваримости синглетонов бездоказательно используют один тезис, который в общем случае неверен. Тезис таков: если объект должен быть только один — значит его разумно сделать в виде синглетона. Ни у одного из вышеупомянутых товарищей я так и не нашел развернутой защиты или доказательства этого тезиса, а ведь этот факт ой-как неочевиден. В качестве примера цитата kuj:
K>2) Приведите хотя бы пару примеров где РЕАЛЬНО помогает реализация данного паттерна?
MVK>Там, где гарантированно должен существовать только один экземпляр класса.
MVK>Бездумное взятие на вооружение таких вот утверждений и приводит к печальным последствиям.
Ничего не следует делать бездумно. Я уже об этом писал.
MVK>Это все тем более странно, что на вопрос "Как можно добиться единственности экземпляра класса?" обычно любой вменяемый программист способен привести несколько вариантов.
Приведите, будьте так любезны. А так же просьба объяснить чем именно эти варианты лучше паттерна Singleton.
MVK>P.S. Кстати, господа синглетонисты, по-вашему, какой вопрос имеет больший приоритет с точки зрения проектирования: MVK>В чьи обязанности будет входить создание экземпляра класса?
Некорректно поставленный вопрос.
MVK>или Какой способ выбрать, что добиться единственности экземпляра класса?
Паттерн Singleton.
Здравствуйте, Kazna4ey, Вы писали:
K>Ради интереса начал думать где в своих проектах я мог бы реализовать singleton, чтобы попробовать и сравнить с тем как было без него. Нашел несколько мест. K>Например есть MDI-приложение, и кое-какая форма должна открываться только в единственном экземпляре, при этом не запрещая параллельную работу с остальными формами. K>Скажите, такая реализация singleton — нормальная?
Нет, не нормальная. Не дело это, когда форма сама решает одна она будет или несколько. Пусть решает тот, кто ее создает. Раз он зачем-то ее создает, значит он и знает сколько и зачем ему эти формы нужны.
Здравствуйте, WolfHound, Вы писали:
kuj>>Таки офигенное, т.к. не плодит лишние сущности, а следовательно экономит ресурсы системы. WH>Какие еще ресурсы? WH>1 new это настолько малая величина что об этом даже разговаривать не стоит. WH>Это просто ничто.
ну-ну.
kuj>>Очень часто нужен именно один. WH>А ели выяснится что таки нужно два?
Не выяснится.
kuj>Приведите, будьте так любезны. А так же просьба объяснить чем именно эти варианты лучше паттерна Singleton.
Допустим, у нас есть некая реализация контейнера:
container.bind(MyInterface.class, new MyInterfaceMock());
Тем самым мы облегчим тестирование зависимых классов. Или даже так (переход от синглтона к неограниченному числу объектов):
container.bindFactory(MyInterface.class, new MyInterfaceFactory()); // на каждое обращение к get возвращает новый объект
Это опять же, неплохо при запуске набора тестов: можно смело корежить состояние объекта, потому что следующему тесту будет выдан новый.
Или скажем так:
ACL acl = ...
// создает один объект на нить, возвращает объект с контролем доступа в ACL
container.bind(MyInterface.class, new MyInterfaceFactory(), ThreadPolicy.LOCAL, acl);
Ну и т.д. Хотя самый простой способ заменить синглтон на что-то ещё — IoC.
Singleton.getInstance() -> private Singleton foo; getFoo(), setFoo()
А IoC-контейнер уже разберется, кому что раздать. Рефакторить такой код потом намного проще.
Здравствуйте, Left2, Вы писали:
L>Ну свой MyCoolContainer, к примеру. MyVector там или MyMultiMap.
А зачем им логгер?
L>Да логгер по большому счёту всем нужен. Если система большая и сложная — то рано или поздно практически все классы начнут хотеть писАть в лог.
Если задумыватся о проектировании не начнут.
L>Но в принципе конечно умерить аппетиты классов, разбив их на "утилитные классы которые всегда работают и в лог ничего не пишут потому что они уже отлажены и ломаться в них нечему" и
Во-во. Один раз написал смартпоинтер или контейнер какойнибудь, обложил юниттестами и все.
L>"классы бизнес-логики которые могут поломаться и логгер для них необходим" вполне возможно и даже наверное полезно
А им наверняка нужны будут еще и другие сервисы и контекст тянуть по любому...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, MaximVK, Вы писали:
MVK>Нет, не нормальная. Не дело это, когда форма сама решает одна она будет или несколько. Пусть решает тот, кто ее создает. Раз он зачем-то ее создает, значит он и знает сколько и зачем ему эти формы нужны.
Особенно забавно будет смотреть, как эту не по годам умную формочку будут делить два экземпляра программы, запущенные в рамках одной виртуальной машины.
Здравствуйте, _FRED_, Вы писали:
kuj>>Я уже ответил Вам по существу. На бесплатные консультации у меня, к сожалению, времени нет. В Интернет есть масса источников, где разжеван ответ на каждый из Ваших вопросов. Потрудитесь поискать.
_FR>Ну хоть ссылкой поделитьсь, что, очень жалко? _FR>Я же в такой же манере тоже мог ответить, мол, и "мои аргументы уже разжёваны людьми поумнее и пообразованнее нас с вами, так что зря клавир мучить…" ан нет,
Так Вы именно в такой манере и отвечаете. Я пока от Вас ничего конструктивного не видел. Повторять "абаснуй", "абаснуй" и попугай может.
_FR>>>>>Да, и перед чем преимущество? kuj>>>>Ваш вопрос ^. _FR>>>У синглетона _возможно_ есть преимущество перед new, но есть ли перед альтернативными способами получения ссылки наобъект: фабрикой, DC, SL?
kuj>>Абсолютно те же самые преимущества, что уже были перечислены мной.
_FR>Где? Всё, что я видел, это
Здравствуйте, Blondy, Вы писали:
B>1. System.DBNull вроде singleton
Это еще и stateless singleton. Для stateless синглтонов большинство критики недействительно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Left2, Вы писали:
L>Ну просто в более-менее большой системе как правило куча классов, и большинство из них хоть что-то да выплёвывают в лог. К примеру, есть у тебя класс SMSSender, который отсылает SMS. Ты ему явно в конструкторе передаёшь логгер?
См Re[3]: Singleton против static class c# 2
L>Или там к примеру есть какие-то свои контейнеры — они тоже логгер принимают в конструкторе?
Какие еще контейнеры?
L>А если обьект небольшой (смартпоинтер из С++), но ему нужен логгер — ты идёшь на увеличение размера обьекта только для того чтобы он всегда знал свой логгер?
Зачем смартпоинтеру логгер?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Kazna4ey, Вы писали:
K>1) В чем преимущество этого паттерна перед классом со статическими методами?
Позволяет использовать контролируемое число экземпляров (а не только один). Можно передать, можно унаследоваться.
K>3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton? http://rsdn3.rsdn.ru/forum/message/2615563.1.aspx
Здравствуйте, MaximVK, Вы писали:
MVK>Если внимательно прочитать мой пост, то станет ясно, что я не просил отвечать на вопросы. Т.к. очевидно, что однозначно ответить на эти вопросы невозможно, все зависит от ситуации(хотя второй ты просто-таки разделал под орех ). Я хотел подвести тебя к мысли, что решая одну задачу единственности экземпляра класса, синглетон автоматически навязывает программисту решение другой, а именно кто будет отвечать за создание экземпляра. А это совершенно разные аспекты и не хотелось бы их увязывать между собой. Иногда, конечно, получается удачно, как в примере с DBNull.Value приведенным Blondy, но увы только иногда. Собственно, все это следствие нарушения синглетоном SRP.
На самом деле это не так, достаточно в классе синглетона иметь методы CreateInstance/DestroyInstance и GetInstance. CreateInstance вызывается логическим владельцем синглетона, а GetInstance всеми остальными клиентами. При этом клиент должен быть готов, что GetInstance может провалиться, хотя на практике это обозначает, что объект-синглетон создается/уничтожается в неправильном месте. Это же позволяет решить тонкие проблемы с доступом из разных потоков — CreateInstance вызывается до создания первого рабочего потока, а DestroyInstance — после удаления последнего. В качестве синглетонов у меня обычно оформляются фасады подсистем. Например, очень хорошо срабатывает это в случае System Layer.
Здравствуйте, Kazna4ey, Вы писали:
K>Объясните пожалуйста.
Представьте простую программу: таймер — по запуску отображаются часы с секундной стрелкой и запускается отсчет времени. Чтобы отсчитывать секунды форма подписывается на события некоторого таймера-счетчика, который периодически шлет ей событие с указанием отсчитанного времени: по этому событию форма перерисует текущее положение секундной стрелки. И пусть форма будет, как в приведенном выше коде, Singleton-ом. Допустим, пользователь открыл таймер, отсчитал 30 секунд а потом, случайно так, снова нажал дважды-быстро на ярлыке программы. В итоге мы получим (в этом примере, конечно, запустятся разные экземпляры виртуальных машин, но это уже тонкости): форма — 1 шт., таймер-счетчик — 2 шт. — причем каждый со своим видением на то, сколько секунд уже натикало. В итоге, вторая форма не откроется, зато в уже открытой секундная стрелка будет скакать как бешеная туда-сюда. Вот такое групповое изнасилование формочки.
Здравствуйте, Kazna4ey, Вы писали:
K>>>Скажите, такая реализация singleton — нормальная? GIV>>Не а GIV>>Я как то пока совсем не вижу необходимости в реализации синглетона. Но так как задачи не знаю — оставлю за скобками.
K>Задача: K>Форма может вызываться из разных мест в программе. Однако нужно чтобы она была всегда одна, т.е. не вызывалось 2 формы.
Нет, это не задача. Пример того что можно назвать задачей: Есть прога в которой можно открыть много документов (MDI), для текущего (активного) документа должна отображаться история изменений (кем, когда). Окно для отображения истории документа должно буть в единственном экземпляре.
В такой постановке я не стал бы делать форму синглетоном. А сделал бы следующее:
— контроллер отслуживает активацию\деакивацию представления "Документ"
— контроллер по этим событиям обновляет ссылку на документ в представлении "История изменений" из ставшего активным представления "Документ"
Соотвественно контроллер содержит ссылки на все представления "Документ" и на представление "История изменений".
Он же занимается отправкой команд на мигание\показать\спрятать и всего прочего.
Как видишь обошлись без синглетонов...
GIV>>//Ты определись — либо тут реализация синглетона, либо мигалка. Черевато боком.
K>Чем мигание мешает реализации синглтона? Если кроме самого понятия синглтона класс не будет ничего делать, зачем тогда такой синглтон?
Нельзя получить ссылку на инстанс синглетона без побочных эффектов (мигания)
K>>>Ну и вызываю конечно так: K>>>[c#] K>>> UpdaterForm p = UpdaterForm.GetInstance(); GIV>>//а вот это совсем жесть K>>> p.MdiParent = MDIParent; K>>> p.Show(); GIV>>//Потом напишем someVar = p; то есть сохраним ссылку на синглетон GIV>>//И позовем его откуда то еще (тот же код), наверно ничего хорошего не выйдет если попользоваться someVar?
K>Не понимаю в чем проблема? Если этот код вызовем в другом месте — ничего плохого не произойдет, форма мигнет, давая понять что она уже открыта.
Проблема в MDIParent и в Show() — синглетон с состоянием — это жесть. В обном месте ему устанавливают одно состояние в другом другое, о чем в первом месте конечно никто не догадывается и считает что все ок.
Здравствуйте, kuj, Вы писали:
K>>1) В чем преимущество этого паттерна перед классом со статическими методами? kuj>В том, что не надо делать new.
И в чём же преемущество? Да, и перед чем преимущество?
K>>2) Приведите хотя бы пару примеров где РЕАЛЬНО помогает реализация данного паттерна? kuj>Там, где гарантированно должен существовать только один экземпляр класса. Примеры: много принтеров, но только один спуллер, kuj>различные IoC контейнеры, логгеры и т.д.
Сделать "IoC-контейнер" синглетоном…
K>>3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton? kuj>Потому, что они не знают как и где его применять.
Это те "не знают как и где его применять", кто "ещё", а те же, кто "уже", не применяют потому что "знают"
... << RSDN@Home 1.2.0 alpha rev. 717>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
kuj>>P.S. Если желаете продолжать данный спор просьба отвечать по существу, либо не отвечать совсем. Ответы в стиле: синглтон — зло точка оставьте пожалуйста при себе. _FR>Тогда ответьте по-существу мне, без всяких недомолвок:
Я уже ответил Вам по существу. На бесплатные консультации у меня, к сожалению, времени нет. В Интернет есть масса источников, где разжеван ответ на каждый из Ваших вопросов. Потрудитесь поискать.
_FR>>>Да, и перед чем преимущество? kuj>>Ваш вопрос ^. _FR>У синглетона _возможно_ есть преимущество перед new, но есть ли перед альтернативными способами получения ссылки наобъект: фабрикой, DC, SL?
Абсолютно те же самые преимущества, что уже были перечислены мной.
_FR>>>Сделать "IoC-контейнер" синглетоном… kuj>>В некоторых случаях IoC-контейнер должен быть синглтоном. Не во всех, далеко не во всех, ясное дело.
_FR>Расскажите, что это за "некоторые", "не все"?
kuj>>Не применяете потому, что не знаете как применять.
_FR>Расскажите, как надо применять.
kuj>>Добавлю еще: для singleton`а в отличии от monostate-класса можно делать subclassing
_FR>Когда и в чём это поможет?
Здравствуйте, minorlogic, Вы писали:
M>Есть такой литературный прием ? метафора там и все такое , не слышали ? Проблемы хуже тем , что авторы сих сингелтонов опираются в своей уверенности на авторитетных авторов.
авторы каких синглетонов? вы бы код привели, а то нам сложно оценить насколько ваше мнение обьективное,
но я лично по своему опыту знаю, что синглетоны очень часто юзабельны и без них просто никак.
Прочитал всю ветку. Адепты использования синглетонов — в частности впечатление таковых создают kuj и ArtDenis — в начаде своих рассуждений об удобоваримости синглетонов бездоказательно используют один тезис, который в общем случае неверен. Тезис таков: если объект должен быть только один — значит его разумно сделать в виде синглетона. Ни у одного из вышеупомянутых товарищей я так и не нашел развернутой защиты или доказательства этого тезиса, а ведь этот факт ой-как неочевиден. В качестве примера цитата kuj:
K>2) Приведите хотя бы пару примеров где РЕАЛЬНО помогает реализация данного паттерна?
Там, где гарантированно должен существовать только один экземпляр класса.
Бездумное взятие на вооружение таких вот утверждений и приводит к печальным последствиям. Это все тем более странно, что на вопрос "Как можно добиться единственности экземпляра класса?" обычно любой вменяемый программист способен привести несколько вариантов.
P.S. Кстати, господа синглетонисты, по-вашему, какой вопрос имеет больший приоритет с точки зрения проектирования:
В чьи обязанности будет входить создание экземпляра класса? или Какой способ выбрать, что добиться единственности экземпляра класса?
Здравствуйте, Sni4ok, Вы писали:
S>но я лично по своему опыту знаю, что синглетоны очень часто юзабельны и без них просто никак.
Я луюбой код с синглетоном могу переписать без синглетона.
При этом он как правило становится проще (и никогда не становится сложнее) и всегда улучшается расширяемость и возможность повторного использования.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Baudolino, Вы писали:
kuj>>Приведите, будьте так любезны. А так же просьба объяснить чем именно эти варианты лучше паттерна Singleton. B>Допустим, у нас есть некая реализация контейнера:
B>
Где гарантии, что Вася Пупкин за соседним компьютером не сделает MyInterface instance = new MyInterfaceSingleton() вместо
MyInterface instance = container.get(MyInterface.class)?
B>Хорошо тем, что потом можно написать так: B>
B>container.bind(MyInterface.class, new MyInterfaceMock());
B>
B>Тем самым мы облегчим тестирование зависимых классов. Или даже так (переход от синглтона к неограниченному числу объектов):
B>Ну и т.д. Хотя самый простой способ заменить синглтон на что-то ещё — IoC. B>Singleton.getInstance() -> private Singleton foo; getFoo(), setFoo() B>А IoC-контейнер уже разберется, кому что раздать. Рефакторить такой код потом намного проще.
kuj>Где гарантии, что Вася Пупкин за соседним компьютером не сделает MyInterface instance = new MyInterfaceSingleton() вместо kuj>MyInterface instance = container.get(MyInterface.class)?
Вася Пупкин за соседним компом может написать что угодно, но если у MyInterfaceSingleton видимость отличная от public, то код не скомпилируется.
Плюс ограничения системы безопасности на создание объектов (в Java).
kuj>Для mocking`а есть более удобные средства. kuj>
Здравствуйте, WolfHound, Вы писали:
kuj>>Очень часто нужен именно один. WH>А ели выяснится что таки нужно два?
Надоели невнимательные читатели, которые приводят это как недостаток синглтона... "А если таки надо 2-а", то открываем Паттерны от GOF и читаем как сделать singleton, который контролирует число отличное от 1(изменения незначительны). Побеждайте лень.
Здравствуйте, COFF, Вы писали:
COF>Так а запрашиваете-то у кого? Или сам контейнер должен быть оформлен в виде синглетона, или его надо тянуть через все приложение.
Протащить контекст гораздо проще и дешевле чем разбиратся с теми макаронами что случаются из-за применения синглетонов.
Просто решение само по себе получается гораздо болие гибким.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
WH>>Если задумыватся о проектировании не начнут. A>Это смешно, делать подобные утверждения. На самом деле ты увеличиваешь связность.
Если уметь проектировать системы то нет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Заранее всего не предусмотреть. Чем меньше кода затрагивает конкретное изменение, тем лучше.
И я о томже... вот только ты не понимаешь что именно мое решение требует переделок меньше чем решение на синглетонах.
Факт многократно подтвержденный и не только мной.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>У тебя, насколько я понял, убогая система логгирования, невпихуемая в один объект. Он бы и был синглтоном, например. WH>Конечно конечно... ты тут один де'Артаньян, а все остальные... WH>Верь в это. WH>Да и не логгером единым...
Вообще-то, разработчиком того же log4net являюсь не я. Так что аргумент, мягко говоря, мимо кассы. Правда, log4net не является системой журналирования с очень развитой фильтрацией, но всё же как пример известной, широко применяемой библиотеки, которую написал не я, сойдёт
A>>Демагогию начал ты, заявив, что могут понадобиться два принт-спулера. WH>А что нет? WH>Ты в этом так уверен? WH>Можешь доказать?
Я абсолютно уверен что на одном компьютере не могут быть одновременно запущенны, корректно функционировать и не знать друг о друге два принт-спулера, два планировщика задач, два и более любых других однотипных сервиса, управляющих одними и теми же аппаратными ресурсами компьютера.
Твой подход заключатся в том, чтобы понасоздавать каждому принтеру по персональному принт-спулеру и разруливать всё внешними механизмами, дублирующими внутрение. Что же тут хорошего? Логгер, принт-спулер, и т.д. должен быть один. То, что часть сообщений пишется в один файл, а часть в другой, то, что часть документов печатается на одном принтере, а часть на другом — это внутренние настройки и их функциональность неправильно дублировать создавая по несколько спулеров, логеров и т.д. Неправильно потому что дублировать что-либо (речь, конечно, не о повышении отказоустойчивости) неправильно по сути своей. Если тебе надо записать лог, то просто пошли сообщение и не думай куда его послать и как сконфигурированно то, куда я его послал. Это же основная идеология инкапсуляции, а ты распотрошил логгер, а теперь утверждаешь, что синглтон из него плохой. Да из него и логгер вобщем-то теперь уже плохой.
Здравствуйте, WolfHound, Вы писали:
WH>Например есть такая хрень называется LibJPEG. WH>Вся ее функциональность в общем случае нафиг не нужна. WH>Но ее API такое что WH>Например для работы с этой либой напрямую необходимо использовать setjump/longjump... WH>И что по твоему для этого безобразия не нужно делать обертки? WH>Или может быть ты предложешь читать/писать jpeg'и ручками?
Не делай вид, как будто не понял о чём я говорю. Я говорил о том, что есть, например, имеет место API вида.
class JpegReader
{
void LoadJpeg(string path, LPVOID * lplpData);
}
class JpegWriter
{
void SaveJpeg(string path, LPVOID lpData);
}
тем более, предоставлять только одну из них — неправильно.
A>>Мне достаточно видеть дизайн множества хороших успешных библиотек журналирования чтобы знать как хорошо, а так же написать свою, пройдя множество ошибок дизайна, чтобы понять почему это хорошо. WH>А может ты просто не видел действительно хороших?
Ну так опубликуй её, напиши статью о правильном дизайне библиотек журналирования. А то как-то странно, куча программистов на многих языках многе годы пользуется однотипными библиотеками с неправильной архитектурой, а внезапно достигший нирваны WolfHound жмотится и не хочет делиться знаниями. Нехорошо с твоей стороны.
Здравствуйте, adontz, Вы писали:
WH>>Это по твоему хороший API? WH>>Мда...
A>>>Ну так опубликуй её, напиши статью о правильном дизайне библиотек журналирования. WH>>Лень.
A>Слив защитан. Скучно с вами сударь.
Я конечно дико извиняюсь, что вмешиваюсь, но, ИМО, сливаешь ты
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, WolfHound, Вы писали:
A>>Да я как погляжу есть очень много "очевидных" истин известных только тебе. WH>Это не известно только тебе. WH>А то что lighttpd под нагрузкой живет намного лучше чем апач является фактом. WH>lighttpd иногда даже ставят перед апачем для того чтобы система написанная под апач не задыхалась. WH>И это тоже факт. WH>Отрицать его бесполезно.
Ну если производительность это тот единственный фактор по которому ты так резво делишь веб-сервера на хорошие и плохие, да ещё и фыркаешь на сообщество Apache, то остаётся тебе только посочувствовать потому что в веб-серверах ты не понимаешь нихрена.
WH>Да не обязан. WH>Но ведь жилающие есть... но только аргументов у них нет.
А те у кого есть, не хотят с тобой связываться так как у них, как людей знающих, а следовательно занятых, нет времени на обучение упёртых личностей. Не думал об этом? Просто как вариант. Ты ведь не просишь сравнительный анализ, не просишь что-то объяснить, ты говришь "Unix — говно. А ну ка кто докажет, что нет?".
WH>Я пишу под эту хрень системы живущие под огромной нагрузкой. WH>На RSDN по сравнению с ними вобще никто не ходит.
Можешь назвать хоть одну? Просто интересно оценить огромность нагрузки. Без технических подробностей, конечно, которые ты, наверняка, всё равно не имеешь права разглашать. Кстати RSDN с его блокировками вообще не аргумент. Я когда с веб-интерфейса отправляю сообщения и тут же в другом окне делаю рефреш, у меня пока сообщение не отправиться, ветка не загружается. С такими подходами делать РСДН точкой отсчёта явно не стоит.
WH>Ибо обосновать очевидные маразмы типа необходимости склонировать текущий процесс (клонирование процессов само по собе маразм) для того чтобы запустить новый нререально.
fork'ом надо просто правильно пользоваться чтобы новый дочерний процесс всё из родительского использовал в режиме read-only иначе COW тебя поимеет. Вообще в Unix и Windows понятия процесса слишком уж различны.
WH>Про различные архитектуры я знаю не хуже тебя. WH>Вот только сколько процентов железок работают с чемто отличным от 8ми битового байта?
Даже если меньше 1%, универсальный стандарт должен это учесть.
WH>При больших нагрузках по побитым логам ничего не понять. WH>А при перегрузках (ботнет пришол) данных до общего лога доходит еще меньше.
Это старвейшен подкрался. Я бы приём сообщения из сети и запись разделил на две независимые асинхронно работающие системы. Ещё можно промежуточные релеи делать, которыу будут балансировать нагрузку, да и без них через NLB или его аналог работать. Вобщем было бы желание.
Здравствуйте, adontz, Вы писали:
WH>>С функцилональностью вобщемто тоже. A>По сравнению с Апачем? Бу-го-га!
А что апач умеет такого важного чего нет у лайти?
Функциональность лайти болие чем достаточно для создания высоконагруженных систем.
A>Советую высказать их в форуме Низкоуровневое программирование в максимально вопросительной форме и посмотреть что тебе ответят.
Данный вопрос к низкоуровнему программированию отношения не имеет.
Это исключительно архитектурный вопрос.
A>Во второй версии, по сравнению с первой, изменений гораздо больше чем просто отказ от fork.
Так зачем было от форка то отказываться?
Он же рулит!
A>Вот, учитывает этот 1% Так же как и все почтовые протоколы (SMTP, POP3, IMAP4), которые шлют только Printable ASCII, на 33% увеличивая общий почтовый трафик, если явно не указана поддержка другого (расширение 8BITMIME, например). Ты же не думаешь что это было сделано совсем без причины?
Назави мне железки (не вымершиме много лет назад) которые не способны отправить пачку октетов?
A>Переходи на другой канальный уровень.
Зачем?
A>Я не думаю, что для оргазацизации с БД в 10Тб принципиальная проблема кинуть локальное оптоволокно.
Оно не нужно.
Болие того система прекрасно живет на толстых SATA винтах.
Причем без рейдов. Ибо рейды ненадежны.
Гораздо надежние делать ручную репликацию данных между машинами.
Это в отличии от рейдов спасает от выгорания целой машины.
Кстати ответь на вопрос: Сколько винтов должно сгореть чтобы потерять данные с RAID5?
A>У нас (в Грузии) его делают фирмы с на порядки меньшим масштабом IT-инфраструктуры. 500Гб суточного трафика вполне влезут в 100Мб фул-дуплекс эзернет. В гигабитный влезут с очень большим запасом.
Не говори о том чего не понимаешь.
Я бы расказал про то какое железо тут стоит и что с ним происходит при перегрузках сети но NDA.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, _FRED_, Вы писали:
A>>Да вобщем-то синглтон и так создаётся по требованию _FR>Проблема синглетона не в том, как он создаётся, а в нарушении SRP.
Это лечится на раз внешним шаблонным создавателем.
Здравствуйте!
Есть несколько вопросов по поводу subj'а.
1) В чем преимущество этого паттерна перед классом со статическими методами?
2) Приведите хотя бы пару примеров где РЕАЛЬНО помогает реализация данного паттерна?
3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton?
Спасибо.
Re: По поводу паттерна singleton и не только
От:
Аноним
Дата:
18.09.07 09:09
Оценка:
Здравствуйте, Kazna4ey, Вы писали:
K>3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton?
Глобальные переменные плохи тем, что доступ к ним слабо контролируем. Синглтон-класс — немногим лучше.
Для себя вывел правило: синглтон может безопасно существовать в системе, но использующие его модули НЕ должны знать, что это синглтон. Т.е. модуль должен при инициализации получать экземпляр класса MyClass как провайдера требуемого функционала (dependency injection или типа того), но НЕ дложен звать всякие статик-методы типа MyClass::getInstance() или getMyClassSingleton().
Ибо условия задачи могут (и будут) поменяться, и вместо использования синглтона может потребоваться доступ к нескольким разным экземплярам класса MyClass, где бывший синглтон-экземпляр — всего лишь дефолтный вариант. И вычищать логику, опиравшуюся на статик-методы, ой как неприятно и муторно потом.
>Глобальные переменные плохи тем, что доступ к ним слабо контролируем.
Т.е.? Можно подробнее?
>K>3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton? http://rsdn3.rsdn.ru/forum/message/2615563.1.aspx
Прочитал, уши повяли. Простите — разные уровни. Можете, кратко объяснить в расчете на программиста с 2х летним опытом?
Ради интереса начал думать где в своих проектах я мог бы реализовать singleton, чтобы попробовать и сравнить с тем как было без него. Нашел несколько мест.
Например есть MDI-приложение, и кое-какая форма должна открываться только в единственном экземпляре, при этом не запрещая параллельную работу с остальными формами.
Скажите, такая реализация singleton — нормальная?
public class UpdaterForm : System.Windows.Forms.Form
{
private static UpdaterForm pInstance;
...
public static UpdaterForm GetInstance()
{
if (pInstance == null || pInstance.IsDisposed)
pInstance = new UpdaterForm();
else
{
// Форма "мигает" чтобы пользователь видел что она уже открыта
pInstance.WindowState = FormWindowState.Minimized;
pInstance.WindowState = FormWindowState.Normal;
}
return pInstance;
}
private UpdaterForm()
{
InitializeComponent();
}
...
}
Ну и вызываю конечно так:
UpdaterForm p = UpdaterForm.GetInstance();
p.MdiParent = MDIParent;
p.Show();
Здравствуйте, Kazna4ey, Вы писали:
K>Ради интереса начал думать где в своих проектах я мог бы реализовать singleton, чтобы попробовать и сравнить с тем как было без него. Нашел несколько мест. K>Например есть MDI-приложение, и кое-какая форма должна открываться только в единственном экземпляре, при этом не запрещая параллельную работу с остальными формами. K>Скажите, такая реализация singleton — нормальная?
Не а
Я как то пока совсем не вижу необходимости в реализации синглетона. Но так как задачи не знаю — оставлю за скобками.
K>
K>public class UpdaterForm : System.Windows.Forms.Form
K>{
K> private static UpdaterForm pInstance;
K> ...
K> public static UpdaterForm GetInstance()
K> {
K> if (pInstance == null || pInstance.IsDisposed)
K> pInstance = new UpdaterForm();
K> else
K> {
//Ты определись - либо тут реализация синглетона, либо мигалка. Черевато боком.
K> // Форма "мигает" чтобы пользователь видел что она уже открыта
K> pInstance.WindowState = FormWindowState.Minimized;
K> pInstance.WindowState = FormWindowState.Normal;
K> }
K> return pInstance;
K> }
K> private UpdaterForm()
K> {
K> InitializeComponent();
K> }
K> ...
K>}
K>
K>Ну и вызываю конечно так: K>
K> UpdaterForm p = UpdaterForm.GetInstance();
//а вот это совсем жесть :(
K> p.MdiParent = MDIParent;
K> p.Show();
//Потом напишем someVar = p; то есть сохраним ссылку на синглетон
//И позовем его откуда то еще (тот же код), наверно ничего хорошего не выйдет если попользоваться someVar?
K>
K>>3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton?
А>Глобальные переменные плохи тем, что доступ к ним слабо контролируем. Синглтон-класс — немногим лучше. А>Для себя вывел правило: синглтон может безопасно существовать в системе, но использующие его модули НЕ должны знать, что это синглтон. Т.е. модуль должен при инициализации получать экземпляр класса MyClass как провайдера требуемого функционала (dependency injection или типа того), но НЕ дложен звать всякие статик-методы типа MyClass::getInstance() или getMyClassSingleton().
Там, где этого легко добиться, то так и надо делать. Но если синглетон должен быть использован где-то глубоко внутри реализации, то, выигрывая в расширяемости, мы проигрываем в сложности кода, так как нам надо будет тянуть все необходимые синглетоны через все иерархии классов, или прийдется создавать что-то типа сервиса именования и все-равно для каждого объекта тянуть глобальный контекст. А это не всегда возможно — есть унаследованный и сторонний код. В общем, избавляясь от одних сложностей, мы получаем другие, не меньшие.
Для себя я использую два правила:
1. Оформлять в синглетон можно только логические подсистемы приложения (что-то типа фасадов, за которыми скрыта обособленная функциональность).
2. Синглетон отвечает только за доступ к функциональности; инициализация и деинициализация соответствующих объектов все-равно должна выполняться явно.
А>Ибо условия задачи могут (и будут) поменяться, и вместо использования синглтона может потребоваться доступ к нескольким разным экземплярам класса MyClass, где бывший синглтон-экземпляр — всего лишь дефолтный вариант. И вычищать логику, опиравшуюся на статик-методы, ой как неприятно и муторно потом.
Ну это вопрос архитектуры. Такое может произойти, но надо всегда взвешивать шансы. Там где это более вероятно, то синглетон конечно использовать не стоит.
K>Ради интереса начал думать где в своих проектах я мог бы реализовать singleton, чтобы попробовать и сравнить с тем как было без него. Нашел несколько мест. K>Например есть MDI-приложение, и кое-какая форма должна открываться только в единственном экземпляре, при этом не запрещая параллельную работу с остальными формами. K>Скажите, такая реализация singleton — нормальная?
Нет, я бы сделал так — контроллер, который создает формы (например, в ответ на команды), очевидно должен иметь список созданных и активных форм, а каждый класс (фабрика) формы должен иметь признак — допускается ли одновременное существование нескольких форм данного вида; если нет, то перед созданием формы в списке ищется форма того же класса, она же и используется. Синглетон тут совершенно излишен.
Здравствуйте, Kazna4ey, Вы писали:
K> Есть несколько вопросов по поводу subj'а.
K>1) В чем преимущество этого паттерна перед классом со статическими методами?
В том, что не надо делать new.
K>2) Приведите хотя бы пару примеров где РЕАЛЬНО помогает реализация данного паттерна?
Там, где гарантированно должен существовать только один экземпляр класса. Примеры: много принтеров, но только один спуллер,
различные IoC контейнеры, логгеры и т.д.
K>3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton?
Потому, что они не знают как и где его применять.
K>>Скажите, такая реализация singleton — нормальная? GIV>Не а GIV>Я как то пока совсем не вижу необходимости в реализации синглетона. Но так как задачи не знаю — оставлю за скобками.
Задача:
Форма может вызываться из разных мест в программе. Однако нужно чтобы она была всегда одна, т.е. не вызывалось 2 формы.
GIV>//Ты определись — либо тут реализация синглетона, либо мигалка. Черевато боком.
Чем мигание мешает реализации синглтона? Если кроме самого понятия синглтона класс не будет ничего делать, зачем тогда такой синглтон?
K>>Ну и вызываю конечно так: K>>[c#] K>> UpdaterForm p = UpdaterForm.GetInstance(); GIV>//а вот это совсем жесть K>> p.MdiParent = MDIParent; K>> p.Show(); GIV>//Потом напишем someVar = p; то есть сохраним ссылку на синглетон GIV>//И позовем его откуда то еще (тот же код), наверно ничего хорошего не выйдет если попользоваться someVar?
Не понимаю в чем проблема? Если этот код вызовем в другом месте — ничего плохого не произойдет, форма мигнет, давая понять что она уже открыта.
K>>Скажите, такая реализация singleton — нормальная?
MVK>Нет, не нормальная. Не дело это, когда форма сама решает одна она будет или несколько. Пусть решает тот, кто ее создает. Раз он зачем-то ее создает, значит он и знает сколько и зачем ему эти формы нужны.
Если так рассуждать, то паттерн синглтон получился бы совсем не нужным, программист бы сам всегда решал "сколько и зачем". А тут как раз уже все решено — форма должна быть только одна — и в этом решении помогает реализация синглтона. Что не так?
R>Особенно забавно будет смотреть, как эту не по годам умную формочку будут делить два экземпляра программы, запущенные в рамках одной виртуальной машины.
COF>Нет, я бы сделал так — контроллер, который создает формы (например, в ответ на команды), очевидно должен иметь список созданных и активных форм, а каждый класс (фабрика) формы должен иметь признак — допускается ли одновременное существование нескольких форм данного вида; если нет, то перед созданием формы в списке ищется форма того же класса, она же и используется. Синглетон тут совершенно излишен.
Такой вариант абсолютно возможен. Только чем излишен синглтон, если его реализация добавляет 5 строк кода и решает задачу?
Здравствуйте, Kazna4ey, Вы писали:
COF>>Нет, я бы сделал так — контроллер, который создает формы (например, в ответ на команды), очевидно должен иметь список созданных и активных форм, а каждый класс (фабрика) формы должен иметь признак — допускается ли одновременное существование нескольких форм данного вида; если нет, то перед созданием формы в списке ищется форма того же класса, она же и используется. Синглетон тут совершенно излишен.
K>Такой вариант абсолютно возможен. Только чем излишен синглтон, если его реализация добавляет 5 строк кода и решает задачу?
На самом деле, можно и синглетон. Просто это решает несколько другую задачу — или в системе должна существовать одна форма, или в контроллере. Часто это одно и то же, но может быть и нет — тут уже приводили пример. На самом деле, я допускаю, что может существовать задача, когда форма вообще может быть одна на все инстанции приложения. Но в этом случае контроллер, получив эту форму от фабрики, обязательно должен проверить, кому принадлежит эта форма — никому, ему или другому контроллеру и действовать соответственно, например вывести сообщение о том, что форма не может быть показана, так как она уже открыта где-то еще. Самое интересное, что реализация с синглетоном оказывается ничуть не проще, чем без него.
Здравствуйте, Kazna4ey, Вы писали:
MVK>>Пусть решает тот, кто ее создает. Раз он зачем-то ее создает, значит он и знает сколько и зачем ему эти формы нужны.
K>Если так рассуждать, то паттерн синглтон получился бы совсем не нужным, программист бы сам всегда решал "сколько и зачем".
Совершенно верно — он не нужен здесь.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, _FRED_, Вы писали:
K>>>1) В чем преимущество этого паттерна перед классом со статическими методами? kuj>>В том, что не надо делать new.
_FR>И в чём же преемущество?
В отсутствии overhead`а и в простой логичности подхода. Читая код, легко распознается singleton, сложно — monostate-class. _FR>Да, и перед чем преимущество?
Ваш вопрос ^.
K>>>2) Приведите хотя бы пару примеров где РЕАЛЬНО помогает реализация данного паттерна? kuj>>Там, где гарантированно должен существовать только один экземпляр класса. Примеры: много принтеров, но только один спуллер, kuj>>различные IoC контейнеры, логгеры и т.д.
_FR>Сделать "IoC-контейнер" синглетоном…
В некоторых случаях IoC-контейнер должен быть синглтоном. Не во всех, далеко не во всех, ясное дело.
K>>>3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton? kuj>>Потому, что они не знают как и где его применять.
_FR>Это те "не знают как и где его применять", кто "ещё", а те же, кто "уже", не применяют потому что "знают"
Не применяете потому, что не знаете как применять.
Добавлю еще: для singleton`а в отличии от monostate-класса можно делать subclassing
В singleton "встроенна" защита от т.н. "infinite circular initialization", когда у вас два разных monostate-класса обращаются к статическим свойствам друг друга. Редкая ситуация — согласен, ошибка в проектировании — согласен, но ведь языки программирования для того и нужны, чтоб защищать нас — людей от врожденного порока — допускать ошибки.
P.S. Если желаете продолжать данный спор просьба отвечать по существу, либо не отвечать совсем. Ответы в стиле: синглтон — зло точка оставьте пожалуйста при себе.
Начну-ка с kuj>P.S. Если желаете продолжать данный спор просьба отвечать по существу, либо не отвечать совсем. Ответы в стиле: синглтон — зло точка оставьте пожалуйста при себе.
Тогда ответьте по-существу мне, без всяких недомолвок:
_FR>>Да, и перед чем преимущество? kuj>Ваш вопрос ^.
У синглетона _возможно_ есть преимущество перед new, но есть ли перед альтернативными способами получения ссылки наобъект: фабрикой, DC, SL?
_FR>>Сделать "IoC-контейнер" синглетоном… kuj>В некоторых случаях IoC-контейнер должен быть синглтоном. Не во всех, далеко не во всех, ясное дело.
Расскажите, что это за "некоторые", "не все"?
kuj>Не применяете потому, что не знаете как применять.
Расскажите, как надо применять.
kuj>Добавлю еще: для singleton`а в отличии от monostate-класса можно делать subclassing
Когда и в чём это поможет?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, kuj, Вы писали:
kuj>Я уже ответил Вам по существу. На бесплатные консультации у меня, к сожалению, времени нет. В Интернет есть масса источников, где разжеван ответ на каждый из Ваших вопросов. Потрудитесь поискать.
Ну хоть ссылкой поделитьсь, что, очень жалко?
Я же в такой же манере тоже мог ответить, мол, и "мои аргументы уже разжёваны людьми поумнее и пообразованнее нас с вами, так что зря клавир мучить…" ан нет,
_FR>>>>Да, и перед чем преимущество? kuj>>>Ваш вопрос ^. _FR>>У синглетона _возможно_ есть преимущество перед new, но есть ли перед альтернативными способами получения ссылки наобъект: фабрикой, DC, SL?
kuj>Абсолютно те же самые преимущества, что уже были перечислены мной.
Здравствуйте, minorlogic, Вы писали:
M>Почитайте "Рефакторинг с использованием шаблонов" там про анонимный клуб бывших любителей сингелтонов.
------
Singletonitis, a term I coined, means "addiction to the Singleton pattern." The intent of a Singleton is to "ensure a class only has one
instance, and provide a global point of access to it" [DP, 127]. You're infected with Singletonitis when the Singleton pattern fixes itself so
deeply into your skull that it begins lording it over other patterns and simpler design ideas, causing you to produce way too many
Singletons.
I've rid myself of Singletonitis and am now considering starting "Singletons Anonymous," a place where recovering Singleton abusers can
support each other on the slow journey back to using simple, nonglobal objects. The Inline Singleton refactoring is a useful step on that
journey. It helps rid your systems of unnecessary Singletons. This leads to the obvious question: When is a Singleton unnecessary?
Short answer: Most of the time.
Long answer: A Singleton is unnecessary when it's simpler to pass an object resource as a reference to the objects that need it, rather than
letting objects access the resource globally. A Singleton is unnecessary when it's used to obtain insignificant memory or performance
improvements. A Singleton isn't necessary when code deep down in a layer of a system needs to access a resource but the code doesn't
belong in that layer to begin with. I could go on. The point is that Singletons aren't necessary when you can design or redesign to avoid
using them.
------
По-моему, никто и не спорит — бездумно лепить синглтоны это зло. Но то же самое можно сказать о всех патернах проектирования.
Синлтон, как и любой другой патерно можно и нужно использовать, но делать это надо с умом — придерживаясь принципа минимальной достаточности.
Проблема с сингелтонами есть, а точнее с их ЗЛОУПОТРЕБЛЕНИЕМ.
Сингелтон ОЧЕНЬ часто лепят чтобы иметь глобальный доступ и только за этим, пытаясь прикрыть другой мотивацией. Но изначально то мотивация совершенно другая.
В результате мы гребем все проблемы связанные с глобальными объектами но только в квадрате.
Здравствуйте, Kazna4ey, Вы писали:
K>1) В чем преимущество этого паттерна перед классом со статическими методами?
Не понял. Обхясни на примере.
K>2) Приведите хотя бы пару примеров где РЕАЛЬНО помогает реализация данного паттерна?
Любой пример, где требуется:
1. Некоторое количество глобальных объектов в одиничном количестве
2. Гарантия существования этих объектов в момент любого обращения к объектам
Здравствуйте, Lloyd, Вы писали:
L>Благодаря этой "тонкости" рушатся все ваши дальнейшие умопостроения.
Вы ни разу не видели программы, которые повзоляют открыть несколько экземпляров представлений одного типа?
Здравствуйте, ArtDenis, Вы писали:
AD>Любой пример, где требуется: AD>1. Некоторое количество глобальных объектов в одиничном количестве AD>2. Гарантия существования этих объектов в момент любого обращения к объектам
Здравствуйте, Sni4ok, Вы писали:
S>Здравствуйте, minorlogic, Вы писали:
M>>В результате мы гребем все проблемы связанные с глобальными объектами но только в квадрате.
S>подскажите ваши рассуждение, каким вы образом степень вычеслили
Есть такой литературный прием ? метафора там и все такое , не слышали ? Проблемы хуже тем , что авторы сих сингелтонов опираются в своей уверенности на авторитетных авторов.
Здравствуйте, Sni4ok, Вы писали:
S>авторы каких синглетонов? вы бы код привели, а то нам сложно оценить насколько ваше мнение обьективное, S>но я лично по своему опыту знаю, что синглетоны очень часто юзабельны и без них просто никак.
У меня нет желания тебя переубедить , свое мнение и аргументы я высказал. Если хочешь исследовать тему, поищки информацию, например туже книгу "рефакторинг с использованием шаблонов"
Здравствуйте, Kazna4ey, Вы писали:
K>Здравствуйте! K> Есть несколько вопросов по поводу subj'а.
K>1) В чем преимущество этого паттерна перед классом со статическими методами? K>2) Приведите хотя бы пару примеров где РЕАЛЬНО помогает реализация данного паттерна? K>3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton?
K>Спасибо.
1. System.DBNull вроде singleton
2. В отличии от просто статических методов в случае singleton-а можно организовать полиморфизм. Из моей практики:
2.1 Разрабатывается трех-звенка, есть общая сборка, которая распологается и на сервере, и на клиенте. В этой сборке требуются глобальные настроичные параметры и методы. Реализация этих методов различна на сервере и на клиенте.
2.2. Разрабатывается несколлько продуктов, у которых есть общая функциональность. Общая функциональность выделяется в отдельную сборку. И опять таки, требуются настроичные глобальные методы и свойства.
В общей сборке делаем класс
public abstract class HomeBase
{
private static HomeBase instanceBase;
protected internal static HomeBase InstanceBase
{
internal get
{
return instanceBase;
}
set
{
instanceBase = value;
}
}
public abstract string[] GetLanguageCodes();
//тут может быть много абстрактных и не авбстрактных методов
}
В основной программе наследуем этот класс
public class Home : HomeBase
{
private Home()
{
}
private static Home instance = new Home();
public static Home Instance
{
get
{
return instance;
}
}
public void Init()
{
InstanceBase = this;
}
public override string[] GetLanguageCodes()
{
throw new NotImplementedException();
}
//...
}
Здравствуйте, minorlogic, Вы писали:
S>>авторы каких синглетонов? вы бы код привели, а то нам сложно оценить насколько ваше мнение обьективное, S>>но я лично по своему опыту знаю, что синглетоны очень часто юзабельны и без них просто никак.
M>У меня нет желания тебя переубедить , свое мнение и аргументы я высказал. Если хочешь исследовать тему, поищки информацию, например туже книгу "рефакторинг с использованием шаблонов"
Здравствуйте, kuj, Вы писали:
K>>1) В чем преимущество этого паттерна перед классом со статическими методами? kuj>В том, что не надо делать new.
Просто офигенное преимущество. Я плакал.
kuj>Примеры: много принтеров, но только один спуллер,
А ну-ну...
Сегодня один завтра понадобится два и привет... kuj>различные IoC контейнеры,
Вот уж где точно не место синглетонам. kuj>логгеры и т.д.
Очень часто нужно больше одного логгера.
kuj>Потому, что они не знают как и где его применять.
Во-во... я не знаю ни одного случая где снглетон дает преимущества но вот проблемы он создает ВСЕГДА!
Безвредны лишь именованные константы заданные во время компиляции.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
K>>>1) В чем преимущество этого паттерна перед классом со статическими методами? kuj>>В том, что не надо делать new. WH>Просто офигенное преимущество. Я плакал.
Таки офигенное, т.к. не плодит лишние сущности, а следовательно экономит ресурсы системы.
kuj>>различные IoC контейнеры, WH>Вот уж где точно не место синглетонам.
Ну-ну.
kuj>>логгеры и т.д. WH>Очень часто нужно больше одного логгера.
Очень часто нужен именно один.
kuj>>Потому, что они не знают как и где его применять. WH>Во-во... я не знаю ни одного случая где снглетон дает преимущества но вот проблемы он создает ВСЕГДА!
Не знаете — ваши проблемы. В будущем может и узнаете. Не теряйте надежды.
Здравствуйте, kuj, Вы писали:
kuj>Таки офигенное, т.к. не плодит лишние сущности, а следовательно экономит ресурсы системы.
Какие еще ресурсы?
1 new это настолько малая величина что об этом даже разговаривать не стоит.
Это просто ничто.
kuj>Очень часто нужен именно один.
А ели выяснится что таки нужно два?
kuj>Не знаете — ваши проблемы. В будущем может и узнаете. Не теряйте надежды.
Ну хоть один пример можно?
Вы ведь знаете.
А если знаете то в чем проблема?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, kuj, Вы писали:
kuj>Ничего не следует делать бездумно. Я уже об этом писал.
Отлично. Тогда можно привести аргументацию в защиту отквоченного мной в предыдущем посте тезиса?
kuj>Приведите, будьте так любезны. А так же просьба объяснить чем именно эти варианты лучше паттерна Singleton.
В начале топика есть пост IB, в котором он дал ссылку http://rsdn3.rsdn.ru/forum/message/2615563.1.aspx
. По этой ссылке ты найдешь всю интересующую тебя информацию. Если что непонятно — спрашивай.
MVK>>P.S. Кстати, господа синглетонисты, по-вашему, какой вопрос имеет больший приоритет с точки зрения проектирования: MVK>>В чьи обязанности будет входить создание экземпляра класса? kuj>Некорректно поставленный вопрос. MVK>>или Какой способ выбрать, что добиться единственности экземпляра класса? kuj>Паттерн Singleton.
Если внимательно прочитать мой пост, то станет ясно, что я не просил отвечать на вопросы. Т.к. очевидно, что однозначно ответить на эти вопросы невозможно, все зависит от ситуации(хотя второй ты просто-таки разделал под орех ). Я хотел подвести тебя к мысли, что решая одну задачу единственности экземпляра класса, синглетон автоматически навязывает программисту решение другой, а именно кто будет отвечать за создание экземпляра. А это совершенно разные аспекты и не хотелось бы их увязывать между собой. Иногда, конечно, получается удачно, как в примере с DBNull.Value приведенным Blondy, но увы только иногда. Собственно, все это следствие нарушения синглетоном SRP.
kuj>Где гарантии, что Вася Пупкин за соседним компьютером не сделает MyInterface instance = new MyInterfaceSingleton() вместо kuj>MyInterface instance = container.get(MyInterface.class)?
Контролировать такие вещи значительно проще, чем разгребать последствия синглетонов.
kuj>Для mocking`а есть более удобные средства. kuj>
Я думаю, тут все в курсе
А вот теперь расскажи нам, как ты будешь делать mock-объект для PrinterSpoolerSingleton с помощью того-же RhinoMocks, если тебе надо написать тесты для MyClass?
public class MyClass
{
public void DoSomething()
{
...
PrinterSpoolerSingleton.Print();
...
}
}
kuj>И в чем причина штанов, полных радости? Узнали нечто новое для себя?
Нет, конечно. Дело в том, что я не писал о средствах создания моки и был несколько удивлен тем, что вы так круто перевели разговор на эту тему. Простите, вырвалось. Не в средствах дело, а в том, как подружить моки с синглтонами. Пример ниже вам привели.
Здравствуйте, John Grey, Вы писали:
JG>Надоели невнимательные читатели, которые приводят это как недостаток синглтона... "А если таки надо 2-а", то открываем Паттерны от GOF и читаем как сделать singleton, который контролирует число отличное от 1(изменения незначительны). Побеждайте лень.
Когда я говорю 2 логгера я говорю не два объекта, а два разных логгера. С разными настройками, с разным уровнем логгирования, с разными файликами куда все пишется,...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, John Grey, Вы писали:
JG>>Надоели невнимательные читатели, которые приводят это как недостаток синглтона... "А если таки надо 2-а", то открываем Паттерны от GOF и читаем как сделать singleton, который контролирует число отличное от 1(изменения незначительны). Побеждайте лень. WH>Когда я говорю 2 логгера я говорю не два объекта, а два разных логгера. С разными настройками, с разным уровнем логгирования, с разными файликами куда все пишется,...
Угу... А что мешает различия положить стратегии и инициализировать логеры разными стратегиями(общий то интерфейс один)?
А говоря по сути синглтон это шаблон контроля количества объектов одного типа в системе, а предоставление доступа отовсюду к этим объектам уже дополниельная фишка, которую каждый может использовать по желанию, а может и не использовать если руки прямые и головы хватает на переосмысление идей других людей.
Здравствуйте, John Grey, Вы писали:
JG>Угу... А что мешает различия положить стратегии и инициализировать логеры разными стратегиями(общий то интерфейс один)?
А нафига мне этот геморой если я просто в конфиге прописываю что-то типа
И все!
Дальше просто запрашиваю компонент по имени и кастую к интерфейсу.
JG>А говоря по сути синглтон это шаблон контроля количества объектов одного типа в системе, а предоставление доступа отовсюду к этим объектам уже дополниельная фишка, которую каждый может использовать по желанию, а может и не использовать если руки прямые и головы хватает на переосмысление идей других людей.
А накой черт это все вобще надо?
Какую задачу это решает?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, COFF, Вы писали:
COF>Так а запрашиваете-то у кого? Или сам контейнер должен быть оформлен в виде синглетона, или его надо тянуть через все приложение.
А может сделаем все данные глобальными ? Знаете как удобно!!! и тащить не надо не в один модуль!
Здравствуйте, COFF, Вы писали:
COF>На самом деле это не так, достаточно в классе синглетона иметь методы CreateInstance/DestroyInstance и GetInstance. CreateInstance вызывается логическим владельцем синглетона, а GetInstance всеми остальными клиентами. При этом клиент должен быть готов, что GetInstance может провалиться, хотя на практике это обозначает, что объект-синглетон создается/уничтожается в неправильном месте. Это же позволяет решить тонкие проблемы с доступом из разных потоков — CreateInstance вызывается до создания первого рабочего потока, а DestroyInstance — после удаления последнего. В качестве синглетонов у меня обычно оформляются фасады подсистем. Например, очень хорошо срабатывает это в случае System Layer.
Ну метод CreateInstance живет в синглетоне, правильно? Перемести этот CreateInstance в другой класс и все будет намного проще. А делать фасад к подсистеме в виде синглетона — это жестоко. Сначала думаем, как бы нам систему разбить на слабо-связанные подсистемы, а потом надежно приколачиваем одну подсистему к другой синглетонами.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, COFF, Вы писали:
COF>>Так а запрашиваете-то у кого? Или сам контейнер должен быть оформлен в виде синглетона, или его надо тянуть через все приложение.
M>А может сделаем все данные глобальными ? Знаете как удобно!!! и тащить не надо не в один модуль!
А может поименуем все-все объекты в программе, положим их в контейнер и любое обращение будем делать через него? Знаете как гибко!!!
MVK>Ну метод CreateInstance живет в синглетоне, правильно? Перемести этот CreateInstance в другой класс и все будет намного проще. А делать фасад к подсистеме в виде синглетона — это жестоко. Сначала думаем, как бы нам систему разбить на слабо-связанные подсистемы, а потом надежно приколачиваем одну подсистему к другой синглетонами.
Я же не говорю, что всегда надо так делать Потом, использование синглетонов — это уровень реализации, а протаскивание контейнера — это уровень интерфейса. Предположим, я хочу сделать логгирование. В варианте с синглетоном я делаю трейд-офф и получаю простой и быстрый доступ к логу взамен на довольно неопределенные перспективы появления нескольких объектов логгирования в будущем. В варианте без синглетона появляется необходимость включать ссылку на лог или на контейнер в интерфейс класса (т.е. происходит по сути глобальное зацепление всех классов на класс лога/контейнера), при этом в варианте с контейнером каждая запись в лог — это поиск по контейнеру, потом динамическое приведение типов. Положим, если я пишу на яве, объектов в контейнере немного и лог сразу скидывается в файл, то это не критично, но на C++ и записи в память — это может быть довольно затратно, например если лог используется для профилирования. Потом, в варианте с синглетонов мне никто не запрещает открывать и другие логи по необходимости.
Да, под подсистемами я как раз и имел в виду что-то общесистемное типа лога. Например, я могу создать интерфейс записи в файл, сделать его синглетоном и все обращения к файловой системе делать только через него.
Здравствуйте, COFF, Вы писали:
COF>Я же не говорю, что всегда надо так делать Потом, использование синглетонов — это уровень реализации, а протаскивание контейнера — это уровень интерфейса.
Это тоже уровень интерфейса, только неявный.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
COF>>Я же не говорю, что всегда надо так делать Потом, использование синглетонов — это уровень реализации, а протаскивание контейнера — это уровень интерфейса. AJD>Это тоже уровень интерфейса, только неявный.
В принципе, и да, и нет Теоретически — наверное, да. А вот практически, особенно на C++ — скорее нет. Например, я могу скрыть обращение к синглетону за макросом, а потом, изменив макрос, вообще отключить лог безо всякого оверхеда . Если же я сделаю ссылку на контейнер/лог членом класса, то так просто этот вариант уже не пройдет. Т.е. я бы сравнил синглетоны с множественным наследованием — это просто удобный элемент низкоуровнего дизайна системы. Вроде бы без них обойтись можно, но иногда удобнее с ними
COF>>Так а запрашиваете-то у кого? Или сам контейнер должен быть оформлен в виде синглетона, или его надо тянуть через все приложение. WH>Протащить контекст гораздо проще и дешевле чем разбиратся с теми макаронами что случаются из-за применения синглетонов.
Интересно. И что — таскаете логгеры повсюду? Лично я ни разу такого не видел. Всегда считал что подсистема логгирования — это единственный достойный кандидат на имплементацию синглтоном, во всех остальных случаях синглтон это красивый расписной титановый костыль для кривоногой программы.
Здравствуйте, Left2, Вы писали:
L>Интересно. И что — таскаете логгеры повсюду? Лично я ни разу такого не видел.
Таскаю я их конечно не по отдельности, а в некотором контейнере.
L>Всегда считал что подсистема логгирования — это единственный достойный кандидат на имплементацию синглтоном, во всех остальных случаях синглтон это красивый расписной титановый костыль для кривоногой программы.
Например у меня сейчас 3 логгера. На следующей неделе скорей всего добавлю еще один.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
L>>Интересно. И что — таскаете логгеры повсюду? Лично я ни разу такого не видел. WH>Таскаю я их конечно не по отдельности, а в некотором контейнере.
Ну просто в более-менее большой системе как правило куча классов, и большинство из них хоть что-то да выплёвывают в лог. К примеру, есть у тебя класс SMSSender, который отсылает SMS. Ты ему явно в конструкторе передаёшь логгер? Или там к примеру есть какие-то свои контейнеры — они тоже логгер принимают в конструкторе? А если обьект небольшой (смартпоинтер из С++), но ему нужен логгер — ты идёшь на увеличение размера обьекта только для того чтобы он всегда знал свой логгер?
Грамотно, решение нравится Видел такой подход в COM, но тогда не оценил глубины идеи.
L>>Или там к примеру есть какие-то свои контейнеры — они тоже логгер принимают в конструкторе? WH>Какие еще контейнеры?
Ну свой MyCoolContainer, к примеру. MyVector там или MyMultiMap.
L>>А если обьект небольшой (смартпоинтер из С++), но ему нужен логгер — ты идёшь на увеличение размера обьекта только для того чтобы он всегда знал свой логгер? WH>Зачем смартпоинтеру логгер?
Да логгер по большому счёту всем нужен. Если система большая и сложная — то рано или поздно практически все классы начнут хотеть писАть в лог. Но в принципе конечно умерить аппетиты классов, разбив их на "утилитные классы которые всегда работают и в лог ничего не пишут потому что они уже отлажены и ломаться в них нечему" и "классы бизнес-логики которые могут поломаться и логгер для них необходим" вполне возможно и даже наверное полезно
Здравствуйте, COFF, Вы писали:
COF>В принципе, и да, и нет Теоретически — наверное, да. А вот практически, особенно на C++ — скорее нет. Например, я могу скрыть обращение к синглетону за макросом, а потом, изменив макрос, вообще отключить лог безо всякого оверхеда.
"Теоретически — наверное, да." (c) . Практически это вылевается в жуткий геморрой.
COF>Если же я сделаю ссылку на контейнер/лог членом класса, то так просто этот вариант уже не пройдет. Т.е. я бы сравнил синглетоны с множественным наследованием — это просто удобный элемент низкоуровнего дизайна системы. Вроде бы без них обойтись можно, но иногда удобнее с ними
Но просто надо не забывать, что наследование — это самый высокий тип связанности (coupling).
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, COFF, Вы писали:
COF>В принципе, и да, и нет Теоретически — наверное, да. А вот практически, особенно на C++ — скорее нет. Например, я могу скрыть обращение к синглетону за макросом, а потом, изменив макрос, вообще отключить лог безо всякого оверхеда . Если же я сделаю ссылку на контейнер/лог членом класса, то так просто этот вариант уже не пройдет. Т.е. я бы сравнил синглетоны с множественным наследованием — это просто удобный элемент низкоуровнего дизайна системы. Вроде бы без них обойтись можно, но иногда удобнее с ними
Мне кажется вы совсем не про сингелтон говорите, а про глобальную точку входа.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, COFF, Вы писали:
COF>>В принципе, и да, и нет Теоретически — наверное, да. А вот практически, особенно на C++ — скорее нет. Например, я могу скрыть обращение к синглетону за макросом, а потом, изменив макрос, вообще отключить лог безо всякого оверхеда . Если же я сделаю ссылку на контейнер/лог членом класса, то так просто этот вариант уже не пройдет. Т.е. я бы сравнил синглетоны с множественным наследованием — это просто удобный элемент низкоуровнего дизайна системы. Вроде бы без них обойтись можно, но иногда удобнее с ними
M>Мне кажется вы совсем не про сингелтон говорите, а про глобальную точку входа.
То же самое, вид сбоку Зайдите на гугл и наберите global access point pattern
Здравствуйте, WolfHound, Вы писали:
WH>Когда я говорю 2 логгера я говорю не два объекта, а два разных логгера. С разными настройками, с разным уровнем логгирования, с разными файликами куда все пишется,...
Это плохой пример и дело даже не в синглтоне, а в том, что ты фильтрацию сообщений выносишь за пределы системы журналирования и вместо того чтобы настроить "эти сообщения в первый журнал, эти во второй, эти в оба" начинаешь писать велосипеды. Вместо того чтобы управлять через конфиги, начинаешь писать if'ы. В этом смысле да, логгер должен быть один, а будет ли это синглтон уже отдельный вопрос.
ИМХО пусть будет, потому что если мне журналирование нужно, то у меня в любом случае будет зависимость на некоторую Logger.dll и я от динамики только проигрываю. Мне удобнее написать Logger.Log("message") понимая, что иногда сообщение вообще никуда не будет записано, чем каждый раз получать его из IServiceProvider, заодно проверяя а не null ли результат.
Здравствуйте, WolfHound, Вы писали:
WH>Протащить контекст гораздо проще и дешевле чем разбиратся с теми макаронами что случаются из-за применения синглетонов. WH>Просто решение само по себе получается гораздо болие гибким.
Злоупотребление IServiceProvider не лучше. Программист "садится" на этот подход и начинает пихать в IServiceProvider не только опциональные зависимости, но и объязательные. В результате у нас не видно снаружи что реально требуется внутри и внутри появляется куча проверок if (service != null). Смысла в этом решительно никакого нет, код пухнет, смысла не добавляется. IServiceProvider имеет смысл использовать только как контейнер для передачи опциональных зависимостей. Причём достаточно неудобный контейнер, так как невозможно передать два однотипных объекта. возвращаясь к твоему примеру, ты не можешь передать два ILogger через IServiceProvider, и даже два FileLogger тоже не сможешь.
Объязательные зависимости конфигурируемые снаружи передаются вно, типизированными параметрами. объязательные зависимости не конфигурируемые снаружи (журналирование), особенно общие для нескольких компонент, надо делать синглтонами. Так лгче их поддерживать. Если у меня, например, есть две библиотеки, для SMTP и POP3, то мне удобнее не грузить приложение тем, что они что-то журналируют, пусть сами получают логеер-синглтон. Заодно я точно буду знать, что какой-нибудь гений неразобравшись не создаст им два разных экземпляра синглтона журналирования, хотя реальная фильтрация производится не рна уровне объектов, а на уровне источника сообщения "network.tcp.client.smtp", "network.tcp.client.pop3"
Здравствуйте, WolfHound, Вы писали:
L>>Да логгер по большому счёту всем нужен. Если система большая и сложная — то рано или поздно практически все классы начнут хотеть писАть в лог. WH>Если задумыватся о проектировании не начнут.
Это смешно, делать подобные утверждения. На самом деле ты увеличиваешь связность.
К примеру, реальная ситуация. Делаю систему отслыки почтовых сообщений, всё многократно протестированно, всё хорошо. В некоторой далёкой стране, есть старый почтовый сервер не поддерживающий RFC. Программа с ним не работает. То есть по твоей логике мне надо либо перелопатить всё сверху до низу, чтобы с верхнего уровня протащить в SmtpClient объект-логгер? Зачем? У меня логгер — синглтон. Изменил код только в том месте, где реально понадобилось журналирование. Отослал кастом-билд, узнал, что не поддерживается команда EHLO и надо пользовать устаревшую HELO. На всё ушли сутки. Если бы мне пришлось протаскивать логгер через все уровни, ушло бы гораздо больше времени. Плюс, по факту решения проблемы, я журналирования из исходников потёр. Тоже без последствий для вышестоящих уровней. А проносить все зависимости сверху до ниху практика весьма и весьма плохая.
Здравствуйте, adontz, Вы писали:
A>Злоупотребление IServiceProvider не лучше. Программист "садится" на этот подход и начинает пихать в IServiceProvider не только опциональные зависимости, но и объязательные. В результате у нас не видно снаружи что реально требуется внутри и внутри появляется куча проверок if (service != null).
А для этого нужно использовать для создания объектов фабрики, которые автоматически разрешают нужные зависимости.
Здравствуйте, Cyberax, Вы писали:
A>>Злоупотребление IServiceProvider не лучше. Программист "садится" на этот подход и начинает пихать в IServiceProvider не только опциональные зависимости, но и объязательные. В результате у нас не видно снаружи что реально требуется внутри и внутри появляется куча проверок if (service != null). C>А для этого нужно использовать для создания объектов фабрики, которые автоматически разрешают нужные зависимости.
В итоге ты опять получишь синглтон, только в крайне извращённой форме. Правой рукой левое ухо...
Здравствуйте, adontz, Вы писали:
A>Злоупотребление IServiceProvider не лучше. Программист "садится" на этот подход и начинает пихать в IServiceProvider не только опциональные зависимости, но и объязательные.
Вобще говоря все зависимости нужно конфигурить... так что...
A>В результате у нас не видно снаружи что реально требуется внутри и внутри появляется куча проверок if (service != null). Смысла в этом решительно никакого нет, код пухнет, смысла не добавляется. IServiceProvider имеет смысл использовать только как контейнер для передачи опциональных зависимостей. Причём достаточно неудобный контейнер, так как невозможно передать два однотипных объекта. возвращаясь к твоему примеру, ты не можешь передать два ILogger через IServiceProvider, и даже два FileLogger тоже не сможешь.
IServiceProvider это лишь пример. Вместо него можно использовать что-то другое.
A>Объязательные зависимости конфигурируемые снаружи передаются вно, типизированными параметрами.
А потом их станет больше...
И все переписывать...
A>объязательные зависимости не конфигурируемые снаружи (журналирование), особенно общие для нескольких компонент, надо делать синглтонами.
Оно таки конфигурируемое.
Например путь к логу, период логротейта, уровень логгирования...
A>Так лгче их поддерживать.
Нифига подобного.
A>Если у меня, например, есть две библиотеки, для SMTP и POP3, то мне удобнее не грузить приложение тем, что они что-то журналируют, пусть сами получают логеер-синглтон.
А самим получить логгер из контейнера не судьба?
A>Заодно я точно буду знать, что какой-нибудь гений неразобравшись не создаст им два разных экземпляра синглтона журналирования, хотя реальная фильтрация производится не рна уровне объектов, а на уровне источника сообщения "network.tcp.client.smtp", "network.tcp.client.pop3"
Ты вобще сейчас о чем?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Это плохой пример и дело даже не в синглтоне, а в том, что ты фильтрацию сообщений выносишь за пределы системы журналирования и вместо того чтобы настроить "эти сообщения в первый журнал, эти во второй, эти в оба" начинаешь писать велосипеды. Вместо того чтобы управлять через конфиги, начинаешь писать if'ы. В этом смысле да, логгер должен быть один, а будет ли это синглтон уже отдельный вопрос.
Нет никаких if'ов.
Все конфигурится конфигом.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Злоупотребление IServiceProvider не лучше. Программист "садится" на этот подход и начинает пихать в IServiceProvider не только опциональные зависимости, но и объязательные. WH>Вобще говоря все зависимости нужно конфигурить... так что...
ЗАчем конфигурировать объязательные зависимости?
A>>Объязательные зависимости конфигурируемые снаружи передаются вно, типизированными параметрами. WH>А потом их станет больше... WH>И все переписывать...
Если это объязательные зависимости, то тебе придётся переписывать далеко не только сигнатуры методов.
WH>Оно таки конфигурируемое. WH>Например путь к логу, период логротейта, уровень логгирования...
Этон е серьёзно. Надо делать фильтрацию сообщений.
A>>Если у меня, например, есть две библиотеки, для SMTP и POP3, то мне удобнее не грузить приложение тем, что они что-то журналируют, пусть сами получают логеер-синглтон. WH>А самим получить логгер из контейнера не судьба?
А зачем из контейнера? А вдруг не предали? Опять if (logger != null)?
A>>Заодно я точно буду знать, что какой-нибудь гений неразобравшись не создаст им два разных экземпляра синглтона журналирования, хотя реальная фильтрация производится не рна уровне объектов, а на уровне источника сообщения "network.tcp.client.smtp", "network.tcp.client.pop3" WH>Ты вобще сейчас о чем?
Я о том, что нет смысла делать два экземпляра Logger каждый из которых сконфигурировать писать сообщения с источником "network.tcp.client.smtp" в файл smtp.log, а сообщения с источником "network.tcp.client.pop3" в pop3.log, если потом одному будут посылаться только SMTP сообщения, а другому только POP3.
Здравствуйте, WolfHound, Вы писали:
A>>Это плохой пример и дело даже не в синглтоне, а в том, что ты фильтрацию сообщений выносишь за пределы системы журналирования и вместо того чтобы настроить "эти сообщения в первый журнал, эти во второй, эти в оба" начинаешь писать велосипеды. Вместо того чтобы управлять через конфиги, начинаешь писать if'ы. В этом смысле да, логгер должен быть один, а будет ли это синглтон уже отдельный вопрос. WH>Нет никаких if'ов. WH>Все конфигурится конфигом.
Тогда не должно быть никаких двух логгеров. Конфигом конфигурируй какие сообщения куда слать.
Здравствуйте, WolfHound, Вы писали:
WH>>>Если задумыватся о проектировании не начнут. A>>Это смешно, делать подобные утверждения. На самом деле ты увеличиваешь связность. WH>Если уметь проектировать системы то нет.
Заранее всего не предусмотреть. Чем меньше кода затрагивает конкретное изменение, тем лучше.
Здравствуйте, adontz, Вы писали:
A>ЗАчем конфигурировать объязательные зависимости?
Как зачем?
Например есть некий компонент (А). Этому компоненту нужны некоторые настройки.
Этот необходим другому компоненту (Б) для работы. Этому компоненту тоже нужны свои настройки.
А тут могут возникнуть разные ситуации:
1)Нужно два компонента Б которые используют один и тотже компонент А.
2)Нужно два компонента Б которые используют разные компоненты А.
Я это решаю конфигами. Вернее это решают вобще не трогая меня.
Ты переписыванием системы.
A>Если это объязательные зависимости, то тебе придётся переписывать далеко не только сигнатуры методов.
Не придется.
A>А зачем из контейнера? А вдруг не предали? Опять if (logger != null)?
А тебе не приходило в голову что контейнер можно специализировать?
И хранить в этом контейнере не только сервисы но и некие другие настройки текущего контекста?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А тут могут возникнуть разные ситуации: WH>1)Нужно два компонента Б которые используют один и тотже компонент А. WH>2)Нужно два компонента Б которые используют разные компоненты А. WH>Я это решаю конфигами. Вернее это решают вобще не трогая меня. WH>Ты переписыванием системы.
Не, в примерах выше, я это решаю передачей А идентификатора Б и конфигами некоторого C — фильтра сообщений между всеми Б и всеми А (фактически там chain of responsibility). С другой стороны у меня нет отдельных сопрягающих конфигов и я могу строить очень сложные, динамически менямые зависимости когда много Б пишут во много А. Это более общее решение.
A>>Если это объязательные зависимости, то тебе придётся переписывать далеко не только сигнатуры методов. WH>Не придется.
Ну как же? А использовать? Или передать объект параметром — это цель, а обращаться к нему не объязательно?
WH>А тебе не приходило в голову что контейнер можно специализировать? WH>И хранить в этом контейнере не только сервисы но и некие другие настройки текущего контекста?
А какая принципиальная разница между специализированным контейнером и передайчей параметров? То есть какая принципиальная разница между
struct Container
{
public Service1 x;
public Service2 y;
}
void Action(Container container);
Здравствуйте, WolfHound, Вы писали:
A>>Заранее всего не предусмотреть. Чем меньше кода затрагивает конкретное изменение, тем лучше. WH>И я о томже... вот только ты не понимаешь что именно мое решение требует переделок меньше чем решение на синглетонах. WH>Факт многократно подтвержденный и не только мной.
Здравствуйте, adontz, Вы писали:
A>Не, в примерах выше, я это решаю передачей А идентификатора Б и конфигами некоторого C — фильтра сообщений между всеми Б и всеми А (фактически там chain of responsibility). С другой стороны у меня нет отдельных сопрягающих конфигов и я могу строить очень сложные, динамически менямые зависимости когда много Б пишут во много А. Это более общее решение.
Рома ты вобще о чем?
Что куда пишет? Какие еще сообщения? Какой еще С? Зачем динамически что-то менять если это менять не нужно?
Это как минимум овердизайн, а то и просто деверсия.
A>Ну как же? А использовать? Или передать объект параметром — это цель, а обращаться к нему не объязательно?
Использовать его будут там где он нужен.
И менять я буду только это место.
A>А какая принципиальная разница между специализированным контейнером и передайчей параметров? То есть какая принципиальная разница между
Вот такая
struct Container
{
public Service1 x;
public Service2 y;
public Service11 x1;
public Service21 y1;
public Service12 x2;
public Service22 y2;
}
void Action(Container container);
А если учесть что цепочка вызовов может быть весьма не маленькой...
И это вполне реальная ситуация. Я в одном месте начал с двух сервисов, а сейчас там уже 6.
И старый код которому нужно только 2 первых ни разу не менялся.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А если учесть что цепочка вызовов может быть весьма не маленькой... WH>И это вполне реальная ситуация. Я в одном месте начал с двух сервисов, а сейчас там уже 6.
Это понятно, что сервисов вообще говоря будет много, а то и очень много.
WH>И старый код которому нужно только 2 первых ни разу не менялся.
Очень хорошо. С одной стороны у нас часть сервисов передаётся на низлежащие уровни, где они не нужны вообще, часть сервисов создаётся на уровне гораздо выше, чем реально используется. Нарушено время жизни. Это далеко не всегда принципиально, но всё же это следует учитывать. Кроме того, если тебе что-то понадобилось на нижнем уровне, тебе надо поменять класс ServiceContainer, поковыряться в верхнем уровне и добавить туда инициализацию, прекомпилировать все промежуточные уровни. По сравнению с plug'n'play синглтоном, ситуация уже. Другое дело, что чрезмерное использование синглтона вредно, как впрочем и чрезмерное использование чего угодно. вобщем я за решения принимаемые исходя из контекста задачи, а не из идеологии. Никто ведь не закладывает возможность двух принт-спулеров, потому что такое никогда не может понадобиться. Совсем никогда. Это даже не overkill, с расчётом на слетлое будущее, это абсолютное непонимание предметной области. Всё равно как выделить некоторый участок мозга на случай если вдруг родится человек с тремя глазами.
Здравствуйте, adontz, Вы писали:
A>Очень хорошо. С одной стороны у нас часть сервисов передаётся на низлежащие уровни, где они не нужны вообще,
И? На одном уровне не нужно. А на уровне ниже нужно.
И в чем проблема передать эти сервисы через уровень где они не нужны на уровень где они нужны?
Или скажем у меня есть интерпретатор в котором некоторые комманды используют одни сервисы, а некоторые другие.
Этот интерпретатор работает в несколько потоков и в каждом потоке нужны свои копии сервисов.
A>часть сервисов создаётся на уровне гораздо выше, чем реально используется. Нарушено время жизни.
Это еще с чего?
Сервисы создаются на том уровне который должен отвечать за время жизни этого сервиса.
Скажем сервисы уровня сессии создаются вместе с самой сессией и передаются в контексте дальше.
A>Это далеко не всегда принципиально, но всё же это следует учитывать.
Что именно?
A>Кроме того, если тебе что-то понадобилось на нижнем уровне, тебе надо поменять класс ServiceContainer, поковыряться в верхнем уровне и добавить туда инициализацию, прекомпилировать все промежуточные уровни. По сравнению с plug'n'play синглтоном, ситуация уже.
Упал до стол.
A>Другое дело, что чрезмерное использование синглтона вредно, как впрочем и чрезмерное использование чего угодно.
Его использование вобще всегда вредно.
Другое дело что этот вред не всегда сразу бросается в глаза но рано или поздно обязательно всплывает.
A>вобщем я за решения принимаемые исходя из контекста задачи, а не из идеологии.
А мне еще ни разу не попадался контекст где синглетон давал бы хоть что-то и во всех контекстах которые я анализировал он создавал проблемы.
A>Никто ведь не закладывает возможность двух принт-спулеров, потому что такое никогда не может понадобиться. Совсем никогда. Это даже не overkill, с расчётом на слетлое будущее, это абсолютное непонимание предметной области. Всё равно как выделить некоторый участок мозга на случай если вдруг родится человек с тремя глазами.
Завязывай с демогогией. Со мной не проходит.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>вобщем я за решения принимаемые исходя из контекста задачи, а не из идеологии. WH>А мне еще ни разу не попадался контекст где синглетон давал бы хоть что-то и во всех контекстах которые я анализировал он создавал проблемы.
У тебя, насколько я понял, убогая система логгирования, невпихуемая в один объект. Он бы и был синглтоном, например.
A>>Никто ведь не закладывает возможность двух принт-спулеров, потому что такое никогда не может понадобиться. Совсем никогда. Это даже не overkill, с расчётом на слетлое будущее, это абсолютное непонимание предметной области. Всё равно как выделить некоторый участок мозга на случай если вдруг родится человек с тремя глазами. WH>Завязывай с демогогией. Со мной не проходит.
Демагогию начал ты, заявив, что могут понадобиться два принт-спулера.
Здравствуйте, adontz, Вы писали:
A>У тебя, насколько я понял, убогая система логгирования, невпихуемая в один объект. Он бы и был синглтоном, например.
Конечно конечно... ты тут один де'Артаньян, а все остальные...
Верь в это.
Да и не логгером единым...
A>Демагогию начал ты, заявив, что могут понадобиться два принт-спулера.
А что нет?
Ты в этом так уверен?
Можешь доказать?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Вообще-то, разработчиком того же log4net являюсь не я. Так что аргумент, мягко говоря, мимо кассы. Правда, log4net не является системой журналирования с очень развитой фильтрацией, но всё же как пример известной, широко применяемой библиотеки, которую написал не я, сойдёт
От того что кто-то чего-то както-то написал ничего не следует.
A>Я абсолютно уверен что на одном компьютере не могут быть одновременно запущенны, корректно функционировать и не знать друг о друге два принт-спулера,
Почему? A>два планировщика задач,
Правда?
А ты знаешь что есть системы где по планировщику на ядро?
А у меня есть демон у которого просто по планировщику на поток ОС и в каждом потоке ОС есть куча потоков уровня пользователя...
A>два и более любых других однотипных сервиса, управляющих одними и теми же аппаратными ресурсами компьютера.
Угу... верь в это.
A>Твой подход заключатся в том, чтобы понасоздавать каждому принтеру по персональному принт-спулеру и разруливать всё внешними механизмами, дублирующими внутрение.
Какие внутренние?
A>Что же тут хорошего?
А чего тут плохого?
A>Логгер, принт-спулер, и т.д. должен быть один.
Кому должен?
A>То, что часть сообщений пишется в один файл, а часть в другой, то, что часть документов печатается на одном принтере, а часть на другом — это внутренние настройки и их функциональность неправильно дублировать создавая по несколько спулеров, логеров и т.д.
Почему? Уж не по тому ли что ты в это веришь?
A>Неправильно потому что дублировать что-либо (речь, конечно, не о повышении отказоустойчивости) неправильно по сути своей.
Где дублирование?
A>Если тебе надо записать лог, то просто пошли сообщение и не думай куда его послать и как сконфигурированно то, куда я его послал.
Да я и не думаю.
A>Это же основная идеология инкапсуляции, а ты распотрошил логгер, а теперь утверждаешь, что синглтон из него плохой. Да из него и логгер вобщем-то теперь уже плохой.
Верь в это.
Кстати ты постоянно пытаешься забыть что есть масса других сервисов при реализации которых так просто стрелки (типа так все делают) не перевести.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Почему? A>>два планировщика задач, WH>Правда? WH>А ты знаешь что есть системы где по планировщику на ядро? WH>А у меня есть демон у которого просто по планировщику на поток ОС и в каждом потоке ОС есть куча потоков уровня пользователя... A>>два и более любых других однотипных сервиса, управляющих одними и теми же аппаратными ресурсами компьютера. WH>Угу... верь в это.
Ты случайно пропустил "ничего не знающих друг о друге" или есть основания подозревать тебя в использовании грязных приёмов?
A>>Твой подход заключатся в том, чтобы понасоздавать каждому принтеру по персональному принт-спулеру и разруливать всё внешними механизмами, дублирующими внутрение. WH>Какие внутренние?
Те внутренние, которые уже есть в принт-спулере, позволяют ему работать с множеством принтеров, и не используюстя тобой, потому что ты готов дублировать код ради непонятной, но несомненно важной для тебя, идеологии. Хотя, на самом деле, надо было просто приглядется к спулеру и понять что он может и что, учитывая его возможности, второй никогда не может понадобится. Кстати создавая несколько спулеров ты неявно делаешь их зависисмыми, так как раньше спулер сам решал как распределять ресурсы и т.п., а теперь ты вынужден получать список принтеров, назначать им спулеры, следить чтобы каждый прнтер получил по спулеру и т.п. Налицо бессмысленное усложнение.
A>>То, что часть сообщений пишется в один файл, а часть в другой, то, что часть документов печатается на одном принтере, а часть на другом — это внутренние настройки и их функциональность неправильно дублировать создавая по несколько спулеров, логеров и т.д. WH>Почему? Уж не по тому ли что ты в это веришь?
Потому что куда и как пишутся журналы это дело системы журналирования, а не приложения отсылающего сообщения. Если понадобится писатьв другой файл, то мы оба поменяем настройки, а если придётся часть сообщений дублировать в syslog, то я как раз поменяю конфиг, а тебе писать и писать...
A>>Неправильно потому что дублировать что-либо (речь, конечно, не о повышении отказоустойчивости) неправильно по сути своей. WH>Где дублирование?
Система журналирования (нормальная) и так умеет делать то, что ты эмулируешь создавая два экземпляра логгера с разными настройками.
WH>Кстати ты постоянно пытаешься забыть что есть масса других сервисов при реализации которых так просто стрелки (типа так все делают) не перевести.
Журналирование это простой и понятный большинству пример. Я в принципе могу привести другие примеры, но они могут быть кому-то непонятны и от того наша, публичная заметь, дискуссия потеряет ценность для аудитории.
Здравствуйте, adontz, Вы писали:
A>Те внутренние, которые уже есть в принт-спулере, позволяют ему работать с множеством принтеров, и не используюстя тобой, потому что ты готов дублировать код ради непонятной, но несомненно важной для тебя, идеологии.
Откуда они там есть?
Правильно какойто любитель синглетонов понапихал...
A>Хотя, на самом деле, надо было просто приглядется к спулеру и понять что он может и что, учитывая его возможности, второй никогда не может понадобится. Кстати создавая несколько спулеров ты неявно делаешь их зависисмыми, так как раньше спулер сам решал как распределять ресурсы и т.п., а теперь ты вынужден получать список принтеров, назначать им спулеры, следить чтобы каждый прнтер получил по спулеру и т.п.
Нам по любому нужно сказать на каком принтере печатать...
A>Налицо бессмысленное усложнение.
Где?
A>Потому что куда и как пишутся журналы это дело системы журналирования, а не приложения отсылающего сообщения. Если понадобится писатьв другой файл, то мы оба поменяем настройки, а если придётся часть сообщений дублировать в syslog, то я как раз поменяю конфиг, а тебе писать и писать...
Нефига подобного.
Это ты придумал.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Те внутренние, которые уже есть в принт-спулере, позволяют ему работать с множеством принтеров, и не используюстя тобой, потому что ты готов дублировать код ради непонятной, но несомненно важной для тебя, идеологии. WH>Откуда они там есть?
А какая разница? Важно, что функциональность уже есть, а откуда она там взялась не важно.
WH>Правильно какойто любитель синглетонов понапихал...
Это перпендикуряно синглтонам.
WH>Нам по любому нужно сказать на каком принтере печатать...
А вот и фиг. Ты сейчас мало того что переиспользовал спулеры, так ещё и жёстко забил сценарий использования, гд принтер жёстко задаётся. Я вполне могу захотеть печатать (и это поддерживается в реальной жизни, это не фантазии!) на любом свободном принтере. То есть понятие "свободный принтер" перестаёт быть внутренним для спулера и наружу (непонятно зачем) выносятся все детали реализации очереди печати. Я могу захотеть печатать на любом свободном принтере в котором есть непустой лоток для листов А3. Это всё спулер уже умеет, но ты решил эту функциональность продублировать. Вот это и есть дублирование и усложнение.
A>>Потому что куда и как пишутся журналы это дело системы журналирования, а не приложения отсылающего сообщения. Если понадобится писатьв другой файл, то мы оба поменяем настройки, а если придётся часть сообщений дублировать в syslog, то я как раз поменяю конфиг, а тебе писать и писать... WH>Нефига подобного. WH>Это ты придумал.
Это реалия жизни. Спроси у любого админа, как ему удобнее работать с журналами и их конфигами.
Здравствуйте, adontz, Вы писали:
A>А какая разница? Важно, что функциональность уже есть, а откуда она там взялась не важно.
Спуллер должен спулить задания для принтера.
Знать про несколько принтеров не его работа.
A>А вот и фиг. Ты сейчас мало того что переиспользовал спулеры, так ещё и жёстко забил сценарий использования, гд принтер жёстко задаётся. Я вполне могу захотеть печатать (и это поддерживается в реальной жизни, это не фантазии!) на любом свободном принтере. То есть понятие "свободный принтер" перестаёт быть внутренним для спулера и наружу (непонятно зачем) выносятся все детали реализации очереди печати. Я могу захотеть печатать на любом свободном принтере в котором есть непустой лоток для листов А3. Это всё спулер уже умеет, но ты решил эту функциональность продублировать. Вот это и есть дублирование и усложнение. http://en.wikipedia.org/wiki/Spooling
Те spool это просто очередь к медленному девайсу.
Все остальное придумали мегаархитекторы которые смешали все в одном.
A>Это реалия жизни. Спроси у любого админа, как ему удобнее работать с журналами и их конфигами.
Спрашивал.
Их тут у меня 7 штук сидит...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Спуллер должен спулить задания для принтера. WH>Знать про несколько принтеров не его работа.
Мы фантазируем или говорим про реальный принт-спулер, скажем, встроенный в Microsoft Windows? Потому что ты не можешь написать все-на-свете-программы и надо учитывать реальные возможности уже существующих систем, а не то как ты бы хотел их видеть.
WH>Все остальное придумали мегаархитекторы которые смешали все в одном.
Не важно, важно что это уже есть, но ты пишешь копию (удорожая создание и поддержку проекта) из эстетических соображений. Это не адекватное поведение. Если система поддерживает некоторую функциональность, даже если лично тебе кажется, что функциональность выходит за видимые тобой идеальные рамки для данной системы, её лучше повторно использовать, а не бороться с некими мифическими мегаархитекторами расплачиваясь человеко-часами за "красивую" архитектуру. Спулер уже поддерживает работу с множеством принтеров. Не важно нравится тебе это или нет. Предлагаемый тобой подход похож на поведение начинающих, которые не разобравшись с большой и сложной библиотекой начинают писать нелепые обёртки и велосипеды. В итоге получаем код вида
потому что у идеологически правильного DateTime не должно быть перегруженных методов ToString. Да кого это волнует? Бери готовый рабочий код из библиотеки и не выпендривайся!
WH>Спрашивал. WH>Их тут у меня 7 штук сидит...
Здравствуйте, adontz, Вы писали:
A>>>Злоупотребление IServiceProvider не лучше. Программист "садится" на этот подход и начинает пихать в IServiceProvider не только опциональные зависимости, но и объязательные. В результате у нас не видно снаружи что реально требуется внутри и внутри появляется куча проверок if (service != null). C>>А для этого нужно использовать для создания объектов фабрики, которые автоматически разрешают нужные зависимости. A>В итоге ты опять получишь синглтон, только в крайне извращённой форме. Правой рукой левое ухо...
Не обязательно. Фабрику можно настроить, чтобы она штамповала новые объекты по требованию и т.п.
Здравствуйте, Cyberax, Вы писали:
A>>В итоге ты опять получишь синглтон, только в крайне извращённой форме. Правой рукой левое ухо... C>Не обязательно. Фабрику можно настроить, чтобы она штамповала новые объекты по требованию и т.п.
Да вобщем-то синглтон и так создаётся по требованию
Здравствуйте, adontz, Вы писали:
A>Мы фантазируем или говорим про реальный принт-спулер,
Мы говорим про правильную архитектуру.
A>Не важно, важно что это уже есть, но ты пишешь копию (удорожая создание и поддержку проекта) из эстетических соображений.
Где я сказал что я пишу свой спуллер для принтера?
A>Это не адекватное поведение.
За то ты у нас очень адекватный.
A>Плохо спрашивал. A>RFC 3164 — The BSD Syslog Protocol
хъ A>и много думать о нормальных системах журналирования. SysLog, кстати, считается одной из простейших систем.
Мои логгеры это умеют.
А еще они умеют слать данные в это самый SysLog...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Мы фантазируем или говорим про реальный принт-спулер, WH>Мы говорим про правильную архитектуру.
Правильная архитектура, на мой взгляд, разрабатывается исходя из текущей обстановки. То есть разбиение на модули далеко не всегда академическое, если часть модулей уже готова (legacy, 3rd party, etc.). В этой обстановке утверждать что некоторый паттерн А всегда лучше паттерна Б абсолютно неправильно. Иногда лучше таскать зависимости через контейнеры, иногда лучше следать синглтон. Хорошо что мы пришли к единому пониманию понятия хорошо (когда изменени затрагивает минимум кода), плохо что ты подход хороший часто рассматриваешь как подход хороший всегда.
A>>Не важно, важно что это уже есть, но ты пишешь копию (удорожая создание и поддержку проекта) из эстетических соображений. WH>Где я сказал что я пишу свой спуллер для принтера?
Ты утверждал что их может понадобиться два и это надо объязательно предусмотреть. Я постарался объяснить почему не может. Очень жаль, если ты не понял.
A>>Это не адекватное поведение. WH>За то ты у нас очень адекватный.
Не переходи грань интересной дискуссии. Пособачиться можно в СВ.
WH>Мои логгеры это умеют. WH>А еще они умеют слать данные в это самый SysLog...
Если твои логгеры действительно это умеют, непонятно зачем заводит их два... Что-то они, наверное, всё же, не умеют.
Здравствуйте, adontz, Вы писали:
A>Правильная архитектура, на мой взгляд, разрабатывается исходя из текущей обстановки. То есть разбиение на модули далеко не всегда академическое, если часть модулей уже готова (legacy, 3rd party, etc.). В этой обстановке утверждать что некоторый паттерн А всегда лучше паттерна Б абсолютно неправильно.
И превратить систему в макароны?
Нет уж спасибо. Насмотрелся.
A>Иногда лучше таскать зависимости через контейнеры, иногда лучше следать синглтон.
Нет случаев когда синглетон лучше.
Вобще нет.
A>Хорошо что мы пришли к единому пониманию понятия хорошо (когда изменени затрагивает минимум кода), плохо что ты подход хороший часто рассматриваешь как подход хороший всегда.
Я рассматриваю синглетоны как всегда плохой подход.
A>Ты утверждал что их может понадобиться два и это надо объязательно предусмотреть. Я постарался объяснить почему не может. Очень жаль, если ты не понял.
Все твое объеснение свелось к тому что так сделано в венде.
A>Не переходи грань интересной дискуссии. Пособачиться можно в СВ.
Я чтоли про неадекватное певедение начал?
A>Если твои логгеры действительно это умеют, непонятно зачем заводит их два... Что-то они, наверное, всё же, не умеют.
Все они умеют.
Просто они спроектированны по умному.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Правильная архитектура, на мой взгляд, разрабатывается исходя из текущей обстановки. То есть разбиение на модули далеко не всегда академическое, если часть модулей уже готова (legacy, 3rd party, etc.). В этой обстановке утверждать что некоторый паттерн А всегда лучше паттерна Б абсолютно неправильно. WH>И превратить систему в макароны? WH>Нет уж спасибо. Насмотрелся.
Ну тогда раз WinAPI спроектирован не лучшим образом откажемся от него и всё напишем сами. А ещё .Net Framework местами кривоват, тоже в топку. MFC/VCL/Qt? Все всякого сомнения не без огрех. Напишем всё сами. Угадал? Ты что, действительно пользуешься только библиотеками внутренней разработки? Это даже не смешно.
A>>Иногда лучше таскать зависимости через контейнеры, иногда лучше следать синглтон. WH>Нет случаев когда синглетон лучше. WH>Вобще нет.
Верь в это, ага. Сие есть догма.
A>>Хорошо что мы пришли к единому пониманию понятия хорошо (когда изменени затрагивает минимум кода), плохо что ты подход хороший часто рассматриваешь как подход хороший всегда. WH>Я рассматриваю синглетоны как всегда плохой подход.
Сначала ты не знаешь, что нельзя делать то-тоПотом знаешь, что нельзя делать то-тоПотом ты понимаешь, что иногда таки можно делать то-тоНу а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться желаемого, и все из них практически равноправны.Когда тебя спрашивают "как мне добиться желаемого", ты быстро перебираешь в уме эти шестьдесять шесть способов, прикидываешь то общее, что в них есть, вздыхаешь и говоришь: "вообще-то, главное — гармония."На вопрос обиженных учеников: "а как ее добиться?", ты говоришь: "никогда не делайте то-то".
Только я пока не понял, ты на втором шаге или на шестом.
A>>Ты утверждал что их может понадобиться два и это надо объязательно предусмотреть. Я постарался объяснить почему не может. Очень жаль, если ты не понял. WH>Все твое объеснение свелось к тому что так сделано в венде.
Дело не в винде, а в том что есть готовая реализация и лучше использовать её, чем писать что-то своё, потому что ты борешься не за новую функциональность и не баги обходишь, а добиваешься внутреней гармонии за счёт удорожания проекта.
A>>Не переходи грань интересной дискуссии. Пособачиться можно в СВ. WH>Я чтоли про неадекватное певедение начал?
Даже если не ты, продолжив, ты не стал менее причастен.
A>>Если твои логгеры действительно это умеют, непонятно зачем заводит их два... Что-то они, наверное, всё же, не умеют. WH>Все они умеют. WH>Просто они спроектированны по умному.
Для меня, одно только то что их надо два, свидетельствует о плохом дизайне.
Здравствуйте, adontz, Вы писали:
A>Напишем всё сами. Угадал? Ты что, действительно пользуешься только библиотеками внутренней разработки? Это даже не смешно.
Зачем переписать?
Можно просто обернуть в правильный интерфейс.
Времени занимает не много за то потом экономит кучу внемени и нервов.
A>Верь в это, ага. Сие есть догма.
К сожелению практика.
A>Я с тобой не согласен, хотя бы потому что не может быть нечто плохим или хорошим всегда. Этот спор напомнил мне одно сообщение...
Не так.
Есть вещи которые плохие всегда
A>Только я пока не понял, ты на втором шаге или на шестом.
Ты действительно хочешь перейти на личности?
A>Дело не в винде, а в том что есть готовая реализация и лучше использовать её, чем писать что-то своё, потому что ты борешься не за новую функциональность и не баги обходишь, а добиваешься внутреней гармонии за счёт удорожания проекта.
Ты это откуда взял?
A>Для меня, одно только то что их надо два, свидетельствует о плохом дизайне.
Смелое заявление особенно учитывая что ты не видил их дизайн...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Напишем всё сами. Угадал? Ты что, действительно пользуешься только библиотеками внутренней разработки? Это даже не смешно. WH>Зачем переписать? WH>Можно просто обернуть в правильный интерфейс.
Если у обёртки функциональность меньше, то этон е правильно вообще говоря.
WH>Времени занимает не много за то потом экономит кучу внемени и нервов.
A>>Для меня, одно только то что их надо два, свидетельствует о плохом дизайне. WH>Смелое заявление особенно учитывая что ты не видил их дизайн...
Мне достаточно видеть дизайн множества хороших успешных библиотек журналирования чтобы знать как хорошо, а так же написать свою, пройдя множество ошибок дизайна, чтобы понять почему это хорошо.
Здравствуйте, adontz, Вы писали:
A>Если у обёртки функциональность меньше, то этон е правильно вообще говоря.
Например есть такая хрень называется LibJPEG.
Вся ее функциональность в общем случае нафиг не нужна.
Но ее API такое что
Например для работы с этой либой напрямую необходимо использовать setjump/longjump...
И что по твоему для этого безобразия не нужно делать обертки?
Или может быть ты предложешь читать/писать jpeg'и ручками?
A>Мне достаточно видеть дизайн множества хороших успешных библиотек журналирования чтобы знать как хорошо, а так же написать свою, пройдя множество ошибок дизайна, чтобы понять почему это хорошо.
А может ты просто не видел действительно хороших?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Не делай вид, как будто не понял о чём я говорю.
Мы вроде говорили о заворачивание плохого API в хороший.
Или как?
A>Я говорил о том, что есть, например, имеет место API вида. A>
A>class JpegReader
A>{
A> void LoadJpeg(string path, LPVOID * lplpData);
A>}
A>class JpegWriter
A>{
A> void SaveJpeg(string path, LPVOID lpData);
A>}
A>
В данном случае могут быть загружены, отмасштабированны и сохранены все 3 формата. resize как и все остальные алгоритмы сохранаяет информацию о формате.
Менеджер опрашивает провайдеры могут ли они загрузить данный формат. Тот провайдер который признается что может загружает картинку.
ImageProviderUnknown служит исключительно для сохранения изображений формат которых не указан.
Сохраняет он его при помощи провайдера который передается ему в конструкторе.
Кстати провайдеры про файлы ничего не знают. Они работают с абстрактным хранилищем которое имеет произвольный доступ.
A>Ну так опубликуй её, напиши статью о правильном дизайне библиотек журналирования.
Лень.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Всё ещё не понимаешь о чём я говорил?
Ну так ты скажи внятно что ты сказать то хотел?
A>Слив защитан. Скучно с вами сударь.
Прав тот кто первым сказал "слив засчитан"? Да Рома ты крут.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Всё ещё не понимаешь о чём я говорил? WH>Ну так ты скажи внятно что ты сказать то хотел?
Я хотел сказать что толстые обёртки неотражающие структуру оборачиваемой сущности зачастую (да чего уж там, практически всегда) приводят к перерасходу ресурсов. В примере выше, представь себе что функция StartJpeg очень долго выполняется или инициализирует внутренние структуры потребляющие много ресурсов. Разделили идеологически на Reader и Writer (типа так правильно) или просто сперва написали Reader потому что надо было только читать, а когда захотелось писать не стали везде переименовывать и просто сделали Writer поимев проблемы с производительностью на ровном месте. Отсюда следует, что надо хорошо понимать суть оборачиваемой сущности. А как только это понимание настанет, желание обрачивать кривую архитектуру сразу отпадёт, потому что нельзя вот так бесплатно поменять принципы работы построив новый фасад к старому дому.
A>>Слив защитан. Скучно с вами сударь. WH>Прав тот кто первым сказал "слив засчитан"? Да Рома ты крут.
log4net общедоступен, Nabu.Logging общедоступна. Все они по твоему мнению бредовые библиотеки, потому что там можно обойтись (не теряя функциональности, удобства, и т.д.) одним Root Logger, хотя конечно технически сделать два и более ничто не мешает. Представить свой правильный вариант ты отказался. Ну и кто сливает? Где же описание этой хвалённой "правильной" архитектуры? Тебе видите ли лень? Извини это не аргумент.
Здравствуйте, AndrewJD, Вы писали:
A>>>>Ну так опубликуй её, напиши статью о правильном дизайне библиотек журналирования. WH>>>Лень. A>>Слив защитан. Скучно с вами сударь. AJD>Я конечно дико извиняюсь, что вмешиваюсь, но, ИМО, сливаешь ты
Чего это я сливаю, когда WolfHound утверждает что щасте есть, но показать отказывается?
Здравствуйте, AndrewJD, Вы писали:
AJD>WolfHound привел пример, как он видит счастье. Пройди по пунктам и напиши почему он не прав, с аргументами
Эээммм ты вообще внимательно за ветками следишь? Всё что сказал WolfHound так это то что синглтоны плохие, потому что любая сущность нужная сейчас в одном экземпляре может потом понадобиться в нескольких и переделки обойдутся дорого. Я в принципе согласен с тем, что переделки обойдутся дорого, я не согласен что любая сущность может потребоваться в нескольких экземплярах. Далее какие-то смутные рассказы о двух логгерах с его стороны и примеры конкретных систем (сорцы, архитектура) с моей. Как раз конкретного примера счастья (архитектура его логгера) со стороны WolfHound я так и не добился. Только пространные размышления о чужом плохом коде который надо обрачивать в свой хороший и негодяях-мегаархитекторах написавших чужой плохой код. Все пидарасты и только WolfHound — д'Артаньян.
Объяснить почему один логгер — хорошо в кратце достаточно просто: удобство (читай дешевизна) поддержки ПО. Это отражено, например, в программе презентации группы Universal Logging Protocol (ULP по идее должен заменить SysLog).
In other words, ULP configuration would not be available at the 'user' level, it would be a system service.
Обобщая, синглтоновость не надо сводить исключительно к синхронизации доступа к аппаратным ресурсам, как это имеет место в спулере принтера, TCP/IP стеке (уверен WolfHound захочет иметь два параллельно работающих стека) или ещё чем-то. Даже аппаратно-независимые сущности вполне могут по чисто идеологическим сображениям быть реализованы в единственном экземпляре. И не надо давить авторитетом умных книжем, мощью IoC уменьшающего связность и кучей других не имеющих отношения к сути вопроса паттернов, потому что паттерн сам по себе это всего лишь инструмент, который надо уметь применять адекватно, а не всегда когда удаётся. Нельзя паять молотком, даже если он самый расчудесный. Да, его можно накалить, да к нему даже прилипнет олово, но вот не надо им паять, он для другого. Так что комрад WolfHound вместе с другими искателями панацей и серебрянных пуль, конечно, может заблуждаться дальше, но есть объективно проверенные, проверенные многолетним использованием в множестве приложений на разных языках и платформах, архитектурные решения и оспаривать их у него пока аргументации не хватает, да впрочем и авторитета.
Я не хочу наезжать лично на WolfHound, общий уровень бескультурия проявился в голосовании 1912
16 из 24 проголосовавших либо не пользуются стандартными библиотеками журналирования ("Вручную пишу в файл, OutputDebugString и т. п. по мере необходимости"), либо пользуюся велосипедами, что не лучше ("Пользуюсь библиотекой собственной разработки"). log4net или syslog используют только 6 проголосовавших, другие бибиотеки даже не упомянуты. Нет, подобное бескультурие вне всякого сомнения беда системная и массовая, удивляться что кто-то не знаком с тем "как это вообще правильно делается" не надо. А вот огорчиться что некто не хочет взглянуть на уже накопленный опыт размахивая флажком IoC как индульгенцией, конечно стоит. Печально это.
Здравствуйте, adontz, Вы писали:
A>Я в принципе согласен с тем, что переделки обойдутся дорого, я не согласен что любая сущность может потребоваться в нескольких экземплярах.
Практика показывает что таки бывает нужно.
A>Далее какие-то смутные рассказы о двух логгерах с его стороны и примеры конкретных систем (сорцы, архитектура) с моей.
Ни разу не аргумент.
Ибо столько фигни понаписали...
A>Как раз конкретного примера счастья (архитектура его логгера) со стороны WolfHound я так и не добился.
Писать статьи мне мягко говоря лень.
A>Только пространные размышления о чужом плохом коде который надо обрачивать в свой хороший и негодяях-мегаархитекторах написавших чужой плохой код.
Есть 3 варианта:
1)Все переписать.
Это не наш путь.
Хотя иногда нет выхода.(существующие решения не работают) Например я так и не нашол ни одной библиотеки которая бы масштабировала картинки без артефактов. Про качество болие сложных алгоритмов и говорить не приходится.
2)Мучаться с уродским API.
Лично мне мягко говоря не хочется постоянно писать setjump/jongjump при работе с LibJPEG.
3)Взять дурацкое API и обернуть.
A>Все пидарасты и только WolfHound — д'Артаньян.
В бан захотел?
В прочем тебе не пивыкать.
A>Объяснить почему один логгер — хорошо в кратце достаточно просто: удобство (читай дешевизна) поддержки ПО.
Откуда это следует?
A>Это отражено, например, в программе презентации группы Universal Logging Protocol (ULP по идее должен заменить SysLog).
Бу-га-га. >- A lightweight client implementation must be easy to achieve.
Это правильно.
>- Is the model that each (client) host has one ULP server? In other words, ULP configuration would not be available at the 'user' level, it would be a system service.
Ага. Щаз.
Сервис которым я не могу толком управлять идет в лес сразу.
>- Should ULP use TCP or UDP?
А почему не оба?
Иногда мне хватит UDP, а иногда мне нужно TCP.
>- It should be a String based protocol.
Ой не факт.
Строковое представление имеет смысл только при выводе в файл. И то не всегда.
А гонять внутри либы строки это мягко говоря не разумно.
>- Security (bidirectional authentication? encryption? overcoming risks of denial of service attacks?)
Это нужно рещать на уровне транспорта.
>- Management: Should a ULP server be configurable via SNMP? An ULP client? How does ULP tie in with RMON2?
Да как угодно.
При нормальном проектирование можно сделать все сразу и болие того дать пользователю возможность легко прикрутить свои методы управления.
Скажем по http.
...
A>Обобщая, синглтоновость не надо сводить исключительно к синхронизации доступа к аппаратным ресурсам, как это имеет место в спулере принтера, TCP/IP стеке (уверен WolfHound захочет иметь два параллельно работающих стека) или ещё чем-то.
Обязательно захочу.
A>Даже аппаратно-независимые сущности вполне могут по чисто идеологическим сображениям быть реализованы в единственном экземпляре.
Что за идеология такая?
A>И не надо давить авторитетом умных книжем,
Так это ты тут чужим "авторитетом" давить пытаешься...
A>мощью IoC уменьшающего связность и кучей других не имеющих отношения к сути вопроса паттернов, потому что паттерн сам по себе это всего лишь инструмент, который надо уметь применять адекватно, а не всегда когда удаётся.
Где я сказал что я пытаюсь применять IoC везде? Опять придумываешь?
Я просто синглетоны не применяю.
Ибо они никогда ничего не дают и почти всегда создают проблемы.
A>Нельзя паять молотком, даже если он самый расчудесный.
А каменный топор при наличии современных инструментов вобще не имеет смысла.
A>Да, его можно накалить, да к нему даже прилипнет олово, но вот не надо им паять, он для другого. Так что комрад WolfHound вместе с другими искателями панацей и серебрянных пуль, конечно, может заблуждаться дальше, но есть объективно проверенные, проверенные многолетним использованием в множестве приложений на разных языках и платформах, архитектурные решения
Опять прячишся за чужим авторитетом... аргументов кроме "так делают крутые дядьки" опять нет...
Проблема ПО в том что тут могут работать такие ужастики что...
Скажем если ты сделаешь квадратные колеса из стекла то первый же выезд на дорогу покажет полную бредовость этой идеи.
Но ПО гораздо прочнее. И постоянно находятся некие несознательные личности которые показывают пальцем на очередную поделку на квадратных колесах и говорят ездит же...
A>и оспаривать их у него пока аргументации не хватает, да впрочем и авторитета.
Ессно не хватает. Ты же их игнорируешь.
A>Я не хочу наезжать лично на WolfHound,
Да ты постоянно этим занимаешься.
A>общий уровень бескультурия проявился
A>А вот огорчиться что некто не хочет взглянуть на уже накопленный опыт размахивая флажком IoC как индульгенцией, конечно стоит. Печально это.
Взглянул.
Понял что накопили мягко говоря не то что нужно копить и пошол дальше.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Я хотел сказать что толстые обёртки неотражающие структуру оборачиваемой сущности зачастую (да чего уж там, практически всегда) приводят к перерасходу ресурсов.
Правда?
Вот уж не замечал.
А если ты про пару лишних вызовов на обработку здорой картинки то это вобще ничто.
A>В примере выше, представь себе что функция StartJpeg очень долго выполняется или инициализирует внутренние структуры потребляющие много ресурсов.
Представил.
В моем случае она будет вызвана один раз при создании ImageProviderJpeg.
A>Разделили идеологически на Reader и Writer (типа так правильно)
Откуда следует что это правильно?
Опять придумаешь всякие глупости с которыми сам споришь?
A>или просто сперва написали Reader потому что надо было только читать, а когда захотелось писать не стали везде переименовывать и просто сделали Writer поимев проблемы с производительностью на ровном месте.
Хватит придумывать.
A>Отсюда следует, что надо хорошо понимать суть оборачиваемой сущности.
А с этим никто не спорит.
A>А как только это понимание настанет, желание обрачивать кривую архитектуру сразу отпадёт,
Как правило усиливается.
A>потому что нельзя вот так бесплатно поменять принципы работы построив новый фасад к старому дому.
ПО штука очень прочная... так что можно. И нужно ибо потом экономит кучу времени.
A>log4net общедоступен,
Nabu.Logging — библиотечка журналирования, родилась ещё на 1.1 когда я понял, что log4net это глюк.
(С) adontz
A>Nabu.Logging общедоступна.
Что-то svn://svn.subversion.ru/usr/local/svn/nabu не работает.
A>Представить свой правильный вариант ты отказался.
Делать мне больше нечего чем статьи по проектирования писать.
A>Ну и кто сливает?
Ты конечно.
Аргументов 0.
За том много демагогии. Из серии придумать глупость и потом ее долго опровергать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>log4net общедоступен, WH>
Nabu.Logging — библиотечка журналирования, родилась ещё на 1.1 когда я понял, что log4net это глюк.
WH>(С) adontz
Nabu.Logging родилась когда log4net ещё не было для .Net 2.0, а писать логи было надо. Можно было конечно портировать log4net, но это и так сделали бы без меня, а время и желание поковыряться были. Глючным, а точнее официально неработающим тогда был только DebugOutputAppender. Откуда ты взял эту "цитату" я не знаю.
A>>Nabu.Logging общедоступна. WH>Что-то svn://svn.subversion.ru/usr/local/svn/nabu не работает.
Здравствуйте, adontz, Вы писали:
A>Nabu.Logging родилась когда log4net ещё не было для .Net 2.0, а писать логи было надо. Можно было конечно портировать log4net, но это и так сделали бы без меня, а время и желание поковыряться были.
Так и запишем: Увеличивал стоимость проекта но ровном месте.
A>Глючным, а точнее официально неработающим тогда был только DebugOutputAppender.
Так и починил бы.
Всяко быстрее чем новою либу написать.
A>Откуда ты взял эту "цитату" я не знаю.
Хочешь сказать я ее придумал?
A>А у тебя не ноль, но показать их ты отказываешься. Существенная разница
Может и изложу если у меня будет несколько свободных дней и графоманское настроение.
A>Мой самый важный аргумент это ссылка на многолетний опыт.
Если это самый важный твой аргумент то слив себе можешь засчитывать автоматически.
ЗЫ Что касается оборачивания кривого API я так понимаю ты признаешь что слил?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Далее какие-то смутные рассказы о двух логгерах с его стороны и примеры конкретных систем (сорцы, архитектура) с моей. WH>Ни разу не аргумент. WH>Ибо столько фигни понаписали...
Семейство библиотек log4* используется в огромном количестве проектов. А хотя да, все ошибаются...
A>>Как раз конкретного примера счастья (архитектура его логгера) со стороны WolfHound я так и не добился. WH>Писать статьи мне мягко говоря лень.
Ну да, ну да. Тайное знание унесёшь с собой в могилу. Прямо Gреорат Сиона
A>>Все пидарастыи только WolfHound — д'Артаньян. WH>В бан захотел? WH>В прочем тебе не пивыкать.
Ты это, без перехода на личности и грязных приёмчиков. А то если поиском по РСДН воспользоваться то пол команды РСДн придётся за этот словестный оборот посадить в бан
A>>Объяснить почему один логгер — хорошо в кратце достаточно просто: удобство (читай дешевизна) поддержки ПО. WH>Откуда это следует?
Из практики. На самом деле нужен вообще один глобальный системный логгер, в который будут писать все приложения и службы. чтоб там и пингуется ли DNS было и какая температура у материнской платы и сколько свободного места на винчестере. потому что на самом деле интересуют не сообщения некоторого модуля, а реконструкция состояния в некоторый промежуток времени. Может в почтовом сервере баг, а может интернет сдох. Как понять если там только сообщения почтового сервера, но нет диагностики сети?
>>- Is the model that each (client) host has one ULP server? In other words, ULP configuration would not be available at the 'user' level, it would be a system service. WH>Ага. Щаз. WH>Сервис которым я не могу толком управлять идет в лес сразу.
Ну да-да, IETF дураки. Чу-дес-но, так и запишем.
>>- Should ULP use TCP or UDP? WH>А почему не оба? WH>Иногда мне хватит UDP, а иногда мне нужно TCP.
Это оглавление презентации, обсуждаись преимущества и недостатки. Типа TCP потребляет много ресурсов (по сравнению с UDP), TCP сложно реализовать на embedded системах где мало памяти и процессорной мощности, UDP нифига не гаратирует. Обсуждалось важно ли знать что свзь между устройством и коллектором есть, даже если сообщения не шлются и т.д.
>>- It should be a String based protocol. WH>Ой не факт. WH>Строковое представление имеет смысл только при выводе в файл. И то не всегда. WH>А гонять внутри либы строки это мягко говоря не разумно.
Тут надо уточнить, речь больше о том чтобы использовать printable ASCII characters, потому что другие символы могут попросту отсутствовать или быть не стандартизированны.
>>- Security (bidirectional authentication? encryption? overcoming risks of denial of service attacks?) WH>Это нужно рещать на уровне транспорта.
Как ты на уровне TCP это решишь? Будешь к девайсу за 50 баксов ставить Цсику с ВПНом за 450 баксов?
A>>Даже аппаратно-независимые сущности вполне могут по чисто идеологическим сображениям быть реализованы в единственном экземпляре. WH>Что за идеология такая?
IETF'ная (configuration would not be available at the 'user' level, it would be a system service). Вестимо неправильная. Правда как правильно ты рассказать ленишься, но я верю в светлое будущее и надеюсь всем сердцем.
WH>Так это ты тут чужим "авторитетом" давить пытаешься...
В том то и дело что тото авторитет которым я давлю людской и без кавычек
WH>Где я сказал что я пытаюсь применять IoC везде? Опять придумываешь? WH>Я просто синглетоны не применяю. WH>Ибо они никогда ничего не дают и почти всегда создают проблемы.
Ты применяшь IoC вместо синглтона.
WH>Опять прячишся за чужим авторитетом... аргументов кроме "так делают крутые дядьки" опять нет...
Есть, так удобнее обслуживать, я уже написал об этом выше.
WH>Взглянул. WH>Понял что накопили мягко говоря не то что нужно копить и пошол дальше.
Здравствуйте, WolfHound, Вы писали:
A>>Nabu.Logging родилась когда log4net ещё не было для .Net 2.0, а писать логи было надо. Можно было конечно портировать log4net, но это и так сделали бы без меня, а время и желание поковыряться были. WH>Так и запишем: Увеличивал стоимость проекта но ровном месте.
Делал в свободное время Open Source. Интересно как я этим увеличил стоимость проекта?
A>>Глючным, а точнее официально неработающим тогда был только DebugOutputAppender. WH>Так и починил бы. WH>Всяко быстрее чем новою либу написать.
Интересно было поковыряться и получить новый опыт. Еси угодно, для самообразования. Библиотека много раз переписывалась, иногда на основе собственных мыслей, чаще по образу и подобию чего-то там (учитывая LGPLность с лицензией проблем было мало). Скоро опять будет переписана
A>>Откуда ты взял эту "цитату" я не знаю. WH>Хочешь сказать я ее придумал?
я подробно расшифровал, что имел ввиду. Потом глюки конкретного раннего порта log4j на .Net к архитектуре вообще отношения не имеют.
A>>А у тебя не ноль, но показать их ты отказываешься. Существенная разница WH>Может и изложу если у меня будет несколько свободных дней и графоманское настроение.
Если это действительно что-то стоящее, думаю тебе многие будут благодарны. Главное чтобы ты не обманывался.
WH>ЗЫ Что касается оборачивания кривого API я так понимаю ты признаешь что слил?
Слил в чём? Ты отрицаешь, что координально разные архитектуры обёртки и оборачиваемой сущности не могут не повлечь нерационального использования ресурсов?
Здравствуйте, adontz, Вы писали:
A>Семейство библиотек log4* используется в огромном количестве проектов. А хотя да, все ошибаются...
Ты даже не представляешь сколько и какого Г используется в огромном колличестве проектов...
Одно то что я не нашол ни одной библиотеки (ни бесплатной ни за деньги. Не считая варианта купить Adobe) которая бы работала с растровыми изображениями не убивая качество говорит о многом.
A>Из практики. На самом деле нужен вообще один глобальный системный логгер, в который будут писать все приложения и службы.
Ты не понимаешь о чем говоришь... у меня в спокойные дни логи гигами измеряются...
А что начинается когда приходит какойнибудь ботнет
A>Ну да-да, IETF дураки. Чу-дес-но, так и запишем.
Как я понял это очередной комитет.
Комитет умным не бывает.
A>Это оглавление презентации, обсуждаись преимущества и недостатки. Типа TCP потребляет много ресурсов (по сравнению с UDP), TCP сложно реализовать на embedded системах где мало памяти и процессорной мощности, UDP нифига не гаратирует. Обсуждалось важно ли знать что свзь между устройством и коллектором есть, даже если сообщения не шлются и т.д.
Так я о том и говорю.
Я должен иметь возможность конфигурировать систему так как я захочу.
В плоть до того что сообщения из одного и тогоже логгера отправлять разными путями.
Напримет все ошибки по TCP, а всякую ерунду типа отладочных сообщений по UDP.
A>Тут надо уточнить, речь больше о том чтобы использовать printable ASCII characters, потому что другие символы могут попросту отсутствовать или быть не стандартизированны.
А мне реально нужно в лог UTF8 писать.
Те из-за этого я уже не могу использовать эту поделку.
A>Как ты на уровне TCP это решишь? Будешь к девайсу за 50 баксов ставить Цсику с ВПНом за 450 баксов?
Не знаешь тривиальных приемов проектирования, а еще лезешь учить других...
Я просто между кодом который сериализует сообщения и кодом который пишет в сокет воткну код который шифрует данные.
Ну или как вариант сжимает их.
Или и то и другое последовательно.
И это будет легко конфигурироваться.
Причем пользовыатель сможет писать свои фильтры.
A>В том то и дело что тото авторитет которым я давлю людской и без кавычек
Чтоб ты знал: Авторитет аргументам не является и являтся не может.
A>Ты применяшь IoC вместо синглтона.
Не всегда.
A>Есть, так удобнее обслуживать, я уже написал об этом выше.
Да ничего подобного.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Интересно было поковыряться и получить новый опыт. Еси угодно, для самообразования. Библиотека много раз переписывалась, иногда на основе собственных мыслей, чаще по образу и подобию чего-то там (учитывая LGPLность с лицензией проблем было мало). Скоро опять будет переписана
И эти люди говорят о том что велосипедостроение это плохо...
A>Если это действительно что-то стоящее, думаю тебе многие будут благодарны.
Проблема в том что графоманское настроение у меня бывает редко. А свободное время еще реже.
A>Главное чтобы ты не обманывался.
Ты за меня не переживай.
A>Слил в чём? Ты отрицаешь, что координально разные архитектуры обёртки и оборачиваемой сущности не могут не повлечь нерационального использования ресурсов?
Если делать правильно то перерасход ресурсов будет (если вобще будет) пренебрежимо мал.
А ты всетки попробуй с LibJPEG напрямую поработать...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ты даже не представляешь сколько и какого Г используется в огромном колличестве проектов...
Знаю. Тут какое дело, зачем заведомое Г официально портировать на несколько языков? Да и комьюнити Apache у меня вызывает некоторое доверие.
A>>Из практики. На самом деле нужен вообще один глобальный системный логгер, в который будут писать все приложения и службы. WH>Ты не понимаешь о чем говоришь... у меня в спокойные дни логи гигами измеряются... WH>А что начинается когда приходит какойнибудь ботнет
Понимаю, в БД пиши логи. Хранилище надо соответствующее выбирать и всё будет хорошо
У меня был проект где логи писались на 250Гб рейд (иначе просто не успеют записаться) и раз в неделю бекапировались куда-то на кассеты. ИМХО маразм, потому что практической пользы от этого никакой не было, но 5-10Гб логов в сутки я видел. А вот как в них потом что-то найти, это целая наука, data mining называется.
WH>Как я понял это очередной комитет. WH>Комитет умным не бывает.
IETF это Internet Engineering Task Force (честно говоря я искрене удивлён, что ты не знаешь что такие IETF). Придумывают и утверждают всякие никому не нужные RFC, занимаются другими малополезными глупостями. Единного коммитета там нет, есть независимые рабочие группы занимающиеся конкретными вопросами. Такая структура, абсолютно неэффектина, но чего ещё ждать от дилетантов и безделиников.
A>>Это оглавление презентации, обсуждаись преимущества и недостатки. Типа TCP потребляет много ресурсов (по сравнению с UDP), TCP сложно реализовать на embedded системах где мало памяти и процессорной мощности, UDP нифига не гаратирует. Обсуждалось важно ли знать что свзь между устройством и коллектором есть, даже если сообщения не шлются и т.д. WH>Так я о том и говорю. WH>Я должен иметь возможность конфигурировать систему так как я захочу. WH>В плоть до того что сообщения из одного и тогоже логгера отправлять разными путями. WH>Напримет все ошибки по TCP, а всякую ерунду типа отладочных сообщений по UDP.
Вот это и обсуждалось. Никто и не говорит об однозначном выборе в пользу TCP или UDP. SysLog и большая часть реализаций SNMP работают по UDP. Так что действительно ли необходимо использовать TCP вопрос не очень простой.
WH>А мне реально нужно в лог UTF8 писать. WH>Те из-за этого я уже не могу использовать эту поделку.
SysLog тоже выкинь, там по стандарту тоже только Printable ASCII, да ещё и размер датаграмы не больше 1024 байт. Вообще-то base64/uue/UTF7 никто не отменял.
WH>Я просто между кодом который сериализует сообщения и кодом который пишет в сокет воткну код который шифрует данные. WH>Ну или как вариант сжимает их. WH>Или и то и другое последовательно. WH>И это будет легко конфигурироваться.
И не работать, потому что Printable ASCII...
A>>Ты применяшь IoC вместо синглтона. WH>Не всегда.
Вовремя ты признался...
A>>Есть, так удобнее обслуживать, я уже написал об этом выше. WH>Да ничего подобного.
Вообще-то это не моё мнение, а системных администраторов. Примером единого лога и единого хранилища может, например, служить NT Event Log, где ты сперва пишешь всё подрял а потом уже фильтруешь View. Под линукс практически всегда все серверы и рабочие станции пишут в единый SysLog сервер. Так что единый лог для всего — это общепринятая практика. Я не очень понимаю что ты тут собираешься оспаривать
Здравствуйте, WolfHound, Вы писали:
A>>Интересно было поковыряться и получить новый опыт. Еси угодно, для самообразования. Библиотека много раз переписывалась, иногда на основе собственных мыслей, чаще по образу и подобию чего-то там (учитывая LGPLность с лицензией проблем было мало). Скоро опять будет переписана WH>И эти люди говорят о том что велосипедостроение это плохо...
Зависит от преследуемой цели. Абсолютного зла нет.
A>>Слил в чём? Ты отрицаешь, что координально разные архитектуры обёртки и оборачиваемой сущности не могут не повлечь нерационального использования ресурсов? WH>Если делать правильно то перерасход ресурсов будет (если вобще будет) пренебрежимо мал. WH>А ты всетки попробуй с LibJPEG напрямую поработать...
Увы это не так. Например, если ты посмотришь на Ruby обёртку HTMLayout то увидишь не только перерасход объектов, но и (если хорошенько задуматься), его неизбежность. У .Net обёртки тоже свои проблемы вызванные исключительно архитектурными различиями. В частности, приходится хранить данные обо всех DOM-элементах на события которых подписывались, чтобы отписаться перед удалением. В зависимости от приложения это может быть как несущественно, так и очень заметно. Увы, далеко не всегда удаётся написать действительно эффективную обёртку с красивым интерфейсом. При этом, что самое смешное, с точки зрения Си интерфейс HTMLayout довольно толковый. У меня нарекания вызывают только названия некоторых функций и порядок следования параметров, что вобщем-то сущие пустяки.
Здравствуйте, adontz, Вы писали:
A>Знаю. Тут какое дело, зачем заведомое Г официально портировать на несколько языков?
А я откуда знаю.
A>Да и комьюнити Apache у меня вызывает некоторое доверие.
А у меня нет. Начем с того что апач плохой сервер... Всякие там lighttpd рвут его как тузик грелку.
A>Понимаю, в БД пиши логи. Хранилище надо соответствующее выбирать и всё будет хорошо
Какая нафиг БД?
От такого колличества логов оракл раком встанет.
Тут только плоские файлики выживают.
A>У меня был проект где логи писались на 250Гб рейд (иначе просто не успеют записаться) и раз в неделю бекапировались куда-то на кассеты.
А налету gzip'ить не догадался?
Логи ведь от gzip'а сильно меньше становятся...
И как следствие на винт гораздо быстрее записываются.
Ах да... Я же забыл... у тебя же логгер правильный... Printable ASCII и все такое...
A>А вот как в них потом что-то найти, это целая наука, data mining называется.
Это мелочи. Главное чтобы было в чем искать.
A>IETF это Internet Engineering Task Force хъ
Рад что ты это понимаешь.
A>Вот это и обсуждалось. Никто и не говорит об однозначном выборе в пользу TCP или UDP. SysLog и большая часть реализаций SNMP работают по UDP. Так что действительно ли необходимо использовать TCP вопрос не очень простой.
Он очень простой.
Нужно просто позволить конфигурить систему так как надо.
И все.
Нужна гарантированная доставка используем TCP не нужна UDP.
A>SysLog тоже выкинь, там по стандарту тоже только Printable ASCII, да ещё и размер датаграмы не больше 1024 байт.
Я вобще считаю UNIX и всех его потомков ошибкой природы.
A>Вообще-то base64/uue/UTF7 никто не отменял.
И как я тебе это буду глазками читать?
A>И не работать, потому что Printable ASCII...
Да маразм требовать это.
В любом случае я могу воткнуть преобразователь в base64 если транспорт будет этого требовать.
В прочем насколько я помню ни UDP ни TCP этого не требуют.
A>Вовремя ты признался...
А где я говорил что всегда буду использовать IoC в тех местах куда ты воткнешь синглетон?
И говорил и говорю что не использую синглетон.
A>Вообще-то это не моё мнение, а системных администраторов.
Ну значит у нас разные админы...
A>Под линукс практически всегда все серверы и рабочие станции пишут в единый SysLog сервер.
У нас тоже коечто так пишут.
Админы говорят ~30% записей до общего лога не доходят... Ибо UDP.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Знаю. Тут какое дело, зачем заведомое Г официально портировать на несколько языков? WH>А я откуда знаю.
Потому что не Г
A>>Да и комьюнити Apache у меня вызывает некоторое доверие. WH>А у меня нет. Начем с того что апач плохой сервер... Всякие там lighttpd рвут его как тузик грелку.
О_о. Мнда, интересные ты делаешь заявления.
WH>Какая нафиг БД? WH>От такого колличества логов оракл раком встанет. WH>Тут только плоские файлики выживают.
Помимо оракла есть другие БД. На нём свет клином не сошёлся и Оракл далеко не сама производительная БД. А вообще мы в MySQL/MyISAM писали.
WH>А налету gzip'ить не догадался?
А NTFS compression не проще включить? Вот об том я и говорю, нет чтоб исследовать текущую функциональность, всё тебя норовит написать что-то....
A>>IETF это Internet Engineering Task Force хъ WH>Рад что ты это понимаешь.
Вообще то это ты не знал что такое IETF, я то как раз давно знаю. Ещё есть IEEE и ISO Тоже бездельники.
WH>Он очень простой. WH>Нужно просто позволить конфигурить систему так как надо. WH>И все.
Совместимость, совместимость и ещё раз совместимость. На двухядерных атлонах свет клином не сошёлся и даже не на х86.
A>>SysLog тоже выкинь, там по стандарту тоже только Printable ASCII, да ещё и размер датаграмы не больше 1024 байт. WH>Я вобще считаю UNIX и всех его потомков ошибкой природы.
Смеялся. Шеридана что ли позвать... хотя нет, лучше сразу на башорг.
A>>Вообще-то base64/uue/UTF7 никто не отменял. WH>И как я тебе это буду глазками читать?
Вьювером. Почту ты как читаешь, она тоже base64 по TCP/IP гоняется. Ах да, это всё происки злодеев...
A>>И не работать, потому что Printable ASCII... WH>Да маразм требовать это.
Как я уже писал, х86 далеко не единственная платформа.
A>>Вовремя ты признался... WH>А где я говорил что всегда буду использовать IoC в тех местах куда ты воткнешь синглетон?
Ты приводил контрпримеры только с IoC чем и ввёл в заблуждение.
A>>Вообще-то это не моё мнение, а системных администраторов. WH>Ну значит у нас разные админы... A>>Под линукс практически всегда все серверы и рабочие станции пишут в единый SysLog сервер. WH>У нас тоже коечто так пишут. WH>Админы говорят ~30% записей до общего лога не доходят... Ибо UDP.
Ну не такие уж у нас и разные админы, если при потере 30% патеков всё равно пишут всё в один лог А идея, видимо, настолько хороша, что даже 30% потерь недостаточный стимул отказаться. А ты говоришь разные...
Здравствуйте, adontz, Вы писали:
WH>>А налету gzip'ить не догадался? A>А NTFS compression не проще включить? Вот об том я и говорю, нет чтоб исследовать текущую функциональность, всё тебя норовит написать что-то....
А потом этот файл его ручками зиповать, чтобы скачать или отправить по почте?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, adontz, Вы писали:
WH>>>А налету gzip'ить не догадался? A>>А NTFS compression не проще включить? Вот об том я и говорю, нет чтоб исследовать текущую функциональность, всё тебя норовит написать что-то....
AJD>А потом этот файл его ручками зиповать, чтобы скачать или отправить по почте?
100Гб по почте?! AndrewJD, вы опять контекст потеряли. Я уже говорил, бекапилось на кассету стриммера. Откуда вдруг взялась почта? И ведь кто-то, я искрене верю, не подумав, сделает GZip сжатие на тот случай если захотят отправить по почте 100Гб, чтоб всего 13Гб пришлось отправлять. Мнда... В страшное время живём.
Здравствуйте, adontz, Вы писали:
WH>>А у меня нет. Начем с того что апач плохой сервер... Всякие там lighttpd рвут его как тузик грелку. A>О_о. Мнда, интересные ты делаешь заявления.
А ты что не знал?
A>Помимо оракла есть другие БД. На нём свет клином не сошёлся и Оракл далеко не сама производительная БД. А вообще мы в MySQL/MyISAM писали.
В любом случае по производительности последовательной записи ничто не может сравниятся с плоским файлом.
Разве что запись прямо на неразмеченный раздел винта.
A>А NTFS compression не проще включить? Вот об том я и говорю, нет чтоб исследовать текущую функциональность, всё тебя норовит написать что-то....
Не везде есть NTFS.
И вобще закладыватся на особенности реализации конкретной платформы плохая идея.
Кстати если руки прямые то данная функциональность реализуется строк в 30... портабельно...
A>Совместимость, совместимость и ещё раз совместимость. На двухядерных атлонах свет клином не сошёлся и даже не на х86.
Какая еще нафиг совместимость?
Решение абсолютно портабельно.
A>Смеялся. Шеридана что ли позвать...
Зави.
A>хотя нет, лучше сразу на башорг.
Давай.
Только еще никто ниразу не смог объяснить почему аритектура UNIX это хорошо.
Да вобщем и не смогут ибо обосновать логически этот маразм нельзя.
A>Как я уже писал, х86 далеко не единственная платформа.
На каких платформах я немогу отослать пачку байт?
Просвети плиз.
A>Ну не такие уж у нас и разные админы, если при потере 30% патеков всё равно пишут всё в один лог А идея, видимо, настолько хороша, что даже 30% потерь недостаточный стимул отказаться. А ты говоришь разные...
То-то когда я хотел посмотреть как система вела себя и спросил где лежит этот общий лог админы послали мня анализировать локальные копии логов ибо там все данные...
А этот общий лог используется исключительно для того чтобы посмотреть как система работает прямо сейчас.
Для разбора полетов его не используют.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>А у меня нет. Начем с того что апач плохой сервер... Всякие там lighttpd рвут его как тузик грелку. A>>О_о. Мнда, интересные ты делаешь заявления. WH>А ты что не знал?
Да я как погляжу есть очень много "очевидных" истин известных только тебе.
A>>Помимо оракла есть другие БД. На нём свет клином не сошёлся и Оракл далеко не сама производительная БД. А вообще мы в MySQL/MyISAM писали. WH>В любом случае по производительности последовательной записи ничто не может сравниятся с плоским файлом. WH>Разве что запись прямо на неразмеченный раздел винта.
Лог потом надо читать. БД удобнее.
A>>А NTFS compression не проще включить? Вот об том я и говорю, нет чтоб исследовать текущую функциональность, всё тебя норовит написать что-то.... WH>Не везде есть NTFS. WH>И вобще закладыватся на особенности реализации конкретной платформы плохая идея. WH>Кстати если руки прямые то данная функциональность реализуется строк в 30... портабельно...
Сервер уже представлял собой ASP.Net веб-сервис, так что область применения сужена не была. А если на Windows Server нет NTFS, это неправильный Windows Server. Да и на рабочих станциях FAT32 делать нечего.
A>>Совместимость, совместимость и ещё раз совместимость. На двухядерных атлонах свет клином не сошёлся и даже не на х86. WH>Какая еще нафиг совместимость? WH>Решение абсолютно портабельно.
Это твое неправильное мнение. Почему, см. ниже.
A>>хотя нет, лучше сразу на башорг. WH>Давай. WH>Только еще никто ниразу не смог объяснить почему аритектура UNIX это хорошо. Да вобщем и не смогут ибо обосновать логически этот маразм нельзя.
Видишь ли, никто вобщем-то и не объязан объяснять тебе, предубеждённой личности, а, вернее, перебарывать уже сложившееся мнение, почему хороша та или иная архитектура ОС. Такие вещи вообще нельзя убедительно объяснить. До них надо дорости путём работы со многими ОС. Если не ошибаюсь, ты был большим поклонником Синерджи или как там эта управляемая ОС называлась со смешной сетевой производительностью? Ну вот тебе ещё рости и рости значит. Не обижайся, но заявление о плохости архитектуры Юникса при том что ты явно не входишь в число людей разбирающихся в Unix Kernel и пишущих дравера выглядит крайне по-дилетантски. Отвечать на него что либо нет абсолютно никакого желания, даже если бы была возможность.
A>>Как я уже писал, х86 далеко не единственная платформа. WH>На каких платформах я немогу отослать пачку байт? WH>Просвети плиз.
Embedded. Ты вообще абсолютно не в теме. Например, во всех почтовых RFC (скорее всего не только там, просто говорю о том, что сам читал) используется термин не байт, а октет. Знаешь почему? Есть платформы где байт не 8битовый. Вобщем ты бы сперва изучил вопрос, оторвался от PC-compatible, посмотрел что люди делают, задумался почему, а потом уже учил всех жить.
WH>А этот общий лог используется исключительно для того чтобы посмотреть как система работает прямо сейчас. WH>Для разбора полетов его не используют.
Здравствуйте, adontz, Вы писали:
A>Да я как погляжу есть очень много "очевидных" истин известных только тебе.
Это не известно только тебе.
А то что lighttpd под нагрузкой живет намного лучше чем апач является фактом.
lighttpd иногда даже ставят перед апачем для того чтобы система написанная под апач не задыхалась.
И это тоже факт.
Отрицать его бесполезно.
A>Лог потом надо читать. БД удобнее.
Дело в том что у меня сильно нагруженная система.
И втыкать туда лишнюю БД это самоубийство.
Пусть лучше анализ займет немного больше времени чем система сдохнет в продакшене.
A>Сервер уже представлял собой ASP.Net веб-сервис, так что область применения сужена не была. А если на Windows Server нет NTFS, это неправильный Windows Server. Да и на рабочих станциях FAT32 делать нечего.
Mono...
В любом случае при правильной архитектуре нужно былобы прописать одну строчку в конфиге...
A>Это твое неправильное мнение. Почему, см. ниже.
Нет там ничего.
A>Видишь ли, никто вобщем-то и не объязан объяснять тебе, предубеждённой личности, а, вернее, перебарывать уже сложившееся мнение, почему хороша та или иная архитектура ОС.
Да не обязан.
Но ведь жилающие есть... но только аргументов у них нет.
A>Такие вещи вообще нельзя убедительно объяснить.
Можно.
Нужно лишь перечислить плюсы и минусы того или иного решения.
И чтобы плюсов оказалось больше.
A>До них надо дорости путём работы со многими ОС.
Я работал и изучал архитектуры не одной ОС.
A>Если не ошибаюсь, ты был большим поклонником Синерджи или как там эта управляемая ОС называлась со смешной сетевой производительностью?
Вобще говоря это исследовательсякая ОС производительностью которой не занимались.
A>Ну вот тебе ещё рости и рости значит. Не обижайся, но заявление о плохости архитектуры Юникса при том что ты явно не входишь в число людей разбирающихся в Unix Kernel и пишущих дравера выглядит крайне по-дилетантски.
Я пишу под эту хрень системы живущие под огромной нагрузкой.
На RSDN по сравнению с ними вобще никто не ходит.
A>Отвечать на него что либо нет абсолютно никакого желания, даже если бы была возможность.
В том то и дело что никто не может ответить.
Ибо обосновать очевидные маразмы типа необходимости склонировать текущий процесс (клонирование процессов само по собе маразм) для того чтобы запустить новый нререально.
A>Embedded. Ты вообще абсолютно не в теме. Например, во всех почтовых RFC (скорее всего не только там, просто говорю о том, что сам читал) используется термин не байт, а октет. Знаешь почему? Есть платформы где байт не 8битовый. Вобщем ты бы сперва изучил вопрос, оторвался от PC-compatible, посмотрел что люди делают, задумался почему, а потом уже учил всех жить.
Про различные архитектуры я знаю не хуже тебя.
Вот только сколько процентов железок работают с чемто отличным от 8ми битового байта?
A>Мои используюст 100%. Я сам нередко использую.
Значит у тебя нагрузки никакие.
При больших нагрузках по побитым логам ничего не понять.
А при перегрузках (ботнет пришол) данных до общего лога доходит еще меньше.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Ну если производительность это тот единственный фактор по которому ты так резво делишь веб-сервера на хорошие и плохие, да ещё и фыркаешь на сообщество Apache,
Кроме производительности есть еще стабильность и функциональность.
Со стабильностью у лайти все в порядке.
С функцилональностью вобщемто тоже.
A>то остаётся тебе только посочувствовать потому что в веб-серверах ты не понимаешь нихрена.
О великий гуру раскажи мне про вебсерверы.
A>А те у кого есть, не хотят с тобой связываться так как у них, как людей знающих, а следовательно занятых, нет времени на обучение упёртых личностей.
Ктобы говорил про упертых личностей...
A>Не думал об этом? Просто как вариант. Ты ведь не просишь сравнительный анализ, не просишь что-то объяснить, ты говришь "Unix — говно. А ну ка кто докажет, что нет?".
Я не просто говорю что UNIX говно. Я говорю почему он говно.
И никто не смог опровргнуть мои аргументы.
A>Можешь назвать хоть одну? Просто интересно оценить огромность нагрузки. Без технических подробностей, конечно, которые ты, наверняка, всё равно не имеешь права разглашать.
Сотни миллионов запросов в сутки. Объем данных на сервере приближается к 10ТБ и будет рости дальше.
Кластер масштабируется линейно. Просто ставишь машины, наливаешь софт и вперед.
Плюс всякие там failover'ы, балансировка нагрузки, оптимизация трафика и прочие бла-бла-бла
A> Кстати RSDN с его блокировками вообще не аргумент. Я когда с веб-интерфейса отправляю сообщения и тут же в другом окне делаю рефреш, у меня пока сообщение не отправиться, ветка не загружается. С такими подходами делать РСДН точкой отсчёта явно не стоит.
У меня скорости нехватает чтобы это повторить.
A>fork'ом надо просто правильно пользоваться чтобы новый дочерний процесс всё из родительского использовал в режиме read-only иначе COW тебя поимеет. Вообще в Unix и Windows понятия процесса слишком уж различны.
Раскажи мне как правильно пользоваться форком.
Я думаю авторы апача тоже с удовольствием послушают...
Кстати задумайся над тем почему появился второй апач...
Ведь первый использовал супер пупер мегафичу fork!
A>Даже если меньше 1%, универсальный стандарт должен это учесть.
Printable ASCII то тут причем?
A>Это старвейшен подкрался. Я бы приём сообщения из сети и запись разделил на две независимые асинхронно работающие системы. Ещё можно промежуточные релеи делать, которыу будут балансировать нагрузку, да и без них через NLB или его аналог работать. Вобщем было бы желание.
А тебе не приходило в голову что из-за перегрузки сети просто напросто теряются пакеты и многие датаграммы просто недоходят?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>С функцилональностью вобщемто тоже.
По сравнению с Апачем? Бу-го-га!
WH>Я не просто говорю что UNIX говно. Я говорю почему он говно. WH>И никто не смог опровргнуть мои аргументы.
Советую высказать их в форуме Низкоуровневое программирование в максимально вопросительной форме и посмотреть что тебе ответят.
WH>Раскажи мне как правильно пользоваться форком. WH>Я думаю авторы апача тоже с удовольствием послушают... WH>Кстати задумайся над тем почему появился второй апач... WH>Ведь первый использовал супер пупер мегафичу fork!
Во второй версии, по сравнению с первой, изменений гораздо больше чем просто отказ от fork.
A>>Даже если меньше 1%, универсальный стандарт должен это учесть. WH>Printable ASCII то тут причем?
Вот, учитывает этот 1% Так же как и все почтовые протоколы (SMTP, POP3, IMAP4), которые шлют только Printable ASCII, на 33% увеличивая общий почтовый трафик, если явно не указана поддержка другого (расширение 8BITMIME, например). Ты же не думаешь что это было сделано совсем без причины?
WH>А тебе не приходило в голову что из-за перегрузки сети просто напросто теряются пакеты и многие датаграммы просто недоходят?
Переходи на другой канальный уровень. Я не думаю, что для оргазацизации с БД в 10Тб принципиальная проблема кинуть локальное оптоволокно. У нас (в Грузии) его делают фирмы с на порядки меньшим масштабом IT-инфраструктуры. 500Гб суточного трафика вполне влезут в 100Мб фул-дуплекс эзернет. В гигабитный влезут с очень большим запасом.
Здравствуйте, adontz, Вы писали:
AJD>>А потом этот файл его ручками зиповать, чтобы скачать или отправить по почте?
A>100Гб по почте?! AndrewJD, вы опять контекст потеряли. Я уже говорил, бекапилось на кассету стриммера. Откуда вдруг взялась почта? И ведь кто-то, я искрене верю, не подумав, сделает GZip сжатие на тот случай если захотят отправить по почте 100Гб, чтоб всего 13Гб пришлось отправлять. Мнда... В страшное время живём.
Здравствуйте, WolfHound, Вы писали:
WH>А что апач умеет такого важного чего нет у лайти? WH>Функциональность лайти болие чем достаточно для создания высоконагруженных систем.
А причём тут высоконагруженные системы? Речь шла о том, что ты не доверяешь log4net, потому что сообщество Апач выпускает дерьмовый веб-сервер.
A>>Советую высказать их в форуме Низкоуровневое программирование в максимально вопросительной форме и посмотреть что тебе ответят. WH>Данный вопрос к низкоуровнему программированию отношения не имеет. WH>Это исключительно архитектурный вопрос.
Поверь, что спросить лучше именно там. Так сложно попробовать?
WH>Так зачем было от форка то отказываться? WH>Он же рулит!
Где я сказал что форк рулит?
A>>Вот, учитывает этот 1% Так же как и все почтовые протоколы (SMTP, POP3, IMAP4), которые шлют только Printable ASCII, на 33% увеличивая общий почтовый трафик, если явно не указана поддержка другого (расширение 8BITMIME, например). Ты же не думаешь что это было сделано совсем без причины? WH>Назави мне железки (не вымершиме много лет назад) которые не способны отправить пачку октетов?
А зачем? Потом мы скатимся в длинный флуд на тему популярности и используемости данных железок. Не хочу. Я просто принимаю как факт их наличие. Кстати дело может быть не только в железке, но и в её кривом софте. 8бит, это ещё не уникод, между прочим, и от искажения символов не защищает.
WH>Оно не нужно. WH>Болие того система прекрасно живет на толстых SATA винтах. WH>Причем без рейдов. Ибо рейды ненадежны.
Ещё одно гениальное открытие WolfHound. Надо отказаться от рейдов, без них надёжнее! Гип-гип ура! Ещё одна попытка попасть на башорг?
WH>Гораздо надежние делать ручную репликацию данных между машинами. WH>Это в отличии от рейдов спасает от выгорания целой машины.
Ручную? А то всё об автоматической думал... Ещё правда есть кластеры SQL/DFS но видно для лохов. Ручная репликация рулит! Йоу!
WH>Кстати ответь на вопрос: Сколько винтов должно сгореть чтобы потерять данные с RAID5?
Зависит от того, сколько винтов было в рейде изначально, а что?
Здравствуйте, adontz, Вы писали:
A>А причём тут высоконагруженные системы? Речь шла о том, что ты не доверяешь log4net, потому что сообщество Апач выпускает дерьмовый веб-сервер.
Я не доверяю "авторитетам" которые типа очень крутые но почемуто не могут сделать нормальный сервер.
A>Поверь, что спросить лучше именно там. Так сложно попробовать?
Какое отношение имеет модель системы к низкоуровнему программированию?
A>Где я сказал что форк рулит?
fork'ом надо просто правильно пользоваться ...
Как еще это можно интерпритировать кроме: У тебя руки кривые, а у крутых пацанов в в ажуре!
A>А зачем? Потом мы скатимся в длинный флуд на тему популярности и используемости данных железок.
Ну хоть одну. A>Не хочу.
Не можешь. A>Я просто принимаю как факт их наличие. Кстати дело может быть не только в железке, но и в её кривом софте. 8бит, это ещё не уникод, между прочим, и от искажения символов не защищает.
Если протокол работает с потоком бит то о каких искажениях может идти речь?
A>Ещё одно гениальное открытие WolfHound. Надо отказаться от рейдов, без них надёжнее! Гип-гип ура! Ещё одна попытка попасть на башорг?
Это практика работы с большими кластерами.
Ибо когда выгорает контроллер рейда нужно найти точно такойже иначе данные недостать.
Болие того пока рейд будет мертв эти данные будет недоступны.
При ручной реализации аналога 0+1 (причем зеркала на разных машинах) этих (и многих других) проблем нет.
A>Ручную? А то всё об автоматической думал...
Ессно реплицирует программа.
Но она написанна под данную конкретную задачу.
A>Ещё правда есть кластеры SQL/DFS но видно для лохов.
DFS это Distributed File System?
Если до то:
1)Я не видель еще ни одной распределенной файловой системы которая бы устроила нас по надежности. (до производительности дело даже недошло)
Хотя GPFS подает надежды но и с ней пока не все ясно.
2)DFS это вобще смех на палочке.
3)Я не верю в эффективную работу SQL сервера поверх распределенной файловой системы.
Единственный вариант это на каждую ноду поставить по демону который будет работать с локальными дисками сам.
Если опять не веришь задумайся почему базы данных отключают кешь файловой системы и организуют свое кеширование.
A>Ручная репликация рулит! Йоу!
Именно так.
Ибо уневерсальные решения дохнут от нагрузки.
A>Зависит от того, сколько винтов было в рейде изначально, а что?
Раскажи как это зависит от колличества винтов в пятом рейде.
Мне просто интересно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>100Гб по почте?! AndrewJD, вы опять контекст потеряли. Я уже говорил, бекапилось на кассету стриммера. Откуда вдруг взялась почта? И ведь кто-то, я искрене верю, не подумав, сделает GZip сжатие на тот случай если захотят отправить по почте 100Гб, чтоб всего 13Гб пришлось отправлять. Мнда... В страшное время живём.
Вроде тут говорилось про архитектуру "правильного" логгера?
Пусть у меня логируется в сутки не 100 гиг, а жалкие 100 метров, то ты все равно предлагаешь мне использовать NTFS компрессию и сжатие логов ручками?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Вроде тут говорилось про архитектуру "правильного" логгера?
ТУТ говорилось про большие логи.
AJD>Пусть у меня логируется в сутки не 100 гиг, а жалкие 100 метров, то ты все равно предлагаешь мне использовать NTFS компрессию и сжатие логов ручками?
Как ни странно, это правильное решение, потому что я могу сживать разными способами с учётом того что на том конце могут разжать. GZip это всего лишь GZip и он ничем принципиально не лучше RAR, 7Zip и т.д. Если передача большого объёма данных это проблема, то выбор оптимального метода сжатия важен. Более того, я не буду посылать по почте, я дам скачать по HTTP/FTP, потому что в письме размер тех же данных за счёт base64 кодирования вырастет на треть. А если скачивать по HTTP, то там GZip опять сам сделается, а то и Deflate.
Здравствуйте, WolfHound, Вы писали:
A>>А причём тут высоконагруженные системы? Речь шла о том, что ты не доверяешь log4net, потому что сообщество Апач выпускает дерьмовый веб-сервер. WH>Я не доверяю "авторитетам" которые типа очень крутые но почемуто не могут сделать нормальный сервер.
Забавно, что все между бесплатным Apache и бесплатным light HTTPd выбирают Apache хотя он, по твоему мнению хочу. Я конечно могу предположить, что мир сошёл с ума, но мне кажется более правильным отмести эту версию и предположить, что ты не прав.
A>>Поверь, что спросить лучше именно там. Так сложно попробовать? WH>Какое отношение имеет модель системы к низкоуровнему программированию?
Вместо того чтобы написать там один топик, написал тут три о том что не надо писать один там. Жесть.
A>>Где я сказал что форк рулит? WH>
fork'ом надо просто правильно пользоваться ...
WH>Как еще это можно интерпритировать кроме: У тебя руки кривые, а у крутых пацанов в в ажуре!
Можно и нужно интерпретировать как "fork — опасный инструмент с помощью которого легко напортачить, но если быть очень осторожным этого не случиться". Не надо больше интепретировать мои слова, если не понял сразу. Лучше переспроси, а я уточню.
A>>Я просто принимаю как факт их наличие. Кстати дело может быть не только в железке, но и в её кривом софте. 8бит, это ещё не уникод, между прочим, и от искажения символов не защищает. WH>Если протокол работает с потоком бит то о каких искажениях может идти речь?
Например послал русский текст в win1251, получил в UTF-8/koi8-r.
A>>Ещё одно гениальное открытие WolfHound. Надо отказаться от рейдов, без них надёжнее! Гип-гип ура! Ещё одна попытка попасть на башорг? WH>Это практика работы с большими кластерами. WH>Ибо когда выгорает контроллер рейда нужно найти точно такойже иначе данные недостать. WH>Болие того пока рейд будет мертв эти данные будет недоступны. WH>При ручной реализации аналога 0+1 (причем зеркала на разных машинах) этих (и многих других) проблем нет.
У тебя какая-то неправильная практика. Например сейчас (буквально в этом месяце) у нас скупили всей такой техники (и много другой) на где-то 10% больше необходимого. по одной запасной штучке минимум. Даже не для того чтобы восстановить данные, а чтобы время ремонта сводилось ко времени замены детали. Плюс к этому все важные файлы храняться в DFS, так что отказ любого узла DFS кластера не отражается на пользователях. Вобщем все эти проблемы от сгорающих контроллёров от жадности.
A>>Ручную? А то всё об автоматической думал... WH>Ессно реплицирует программа. WH>Но она написанна под данную конкретную задачу.
Даже не представляю задачу на которую не хватит функциональности DFS и SQL кластеров.
WH>DFS это Distributed File System? WH>Если до то: WH>1)Я не видель еще ни одной распределенной файловой системы которая бы устроила нас по надежности. (до производительности дело даже недошло) WH>Хотя GPFS подает надежды но и с ней пока не все ясно.
Лично меня виндовый никогда не подводил. Некоторые личности, уж не буду называть , специально ломали выдёргивая сетевой кабель. Не вышло.
WH>2)DFS это вобще смех на палочке.
Да, серьёзный аргумент. Глубина мысли поражает.
WH>3)Я не верю в эффективную работу SQL сервера поверх распределенной файловой системы.
У SQL сервера есть свои failover кластеры, зачем их поверх DFS ставить? Чем больше я читаю то что ты пишешь, тем больше понимаю что в вопросе ты не сечёшь.
WH>Единственный вариант это на каждую ноду поставить по демону который будет работать с локальными дисками сам. WH>Если опять не веришь задумайся почему базы данных отключают кешь файловой системы и организуют свое кеширование.
Ещё раз, есть кластеризация БД не только для балансировки нагрузки но и для отказоустойчивости. Ты можешь её отрицать, но она есть.
A>>Ручная репликация рулит! Йоу! WH>Именно так. WH>Ибо уневерсальные решения дохнут от нагрузки.
A>>Зависит от того, сколько винтов было в рейде изначально, а что? WH>Раскажи как это зависит от колличества винтов в пятом рейде. WH>Мне просто интересно.
Извиняюсь, не увидел в изначальном вопросе цифры 5
RAID0 дохнет при выходе их строя любого носителя.
RAID1 дохнет при выходе их строя всех носителей.
RAID5 дохнет при выходе их строя двух носителей.
Для важной информации делают зеркало из 3 винтов. У нас так. RAID5 это бюджетный вариант который рекомендуется применять вместе с HotSwap/HotSpare. Ну и вообще говоря не рекомендуется подключать в рейд винчесеры из одной партии. Чисто из своей практики делают RAID0+1 где 0 наращивается для производительности, а 1 для надёжности. Чёго ты на 5ом рейде зациклился я не очень понимаю. Хотя я слушал делают рейд 5+1, но сам не видел. В принципе это должно выходить дешевле.
Здравствуйте, adontz, Вы писали:
A>Забавно, что все между бесплатным Apache и бесплатным light HTTPd выбирают Apache хотя он, по твоему мнению хочу. Я конечно могу предположить, что мир сошёл с ума, но мне кажется более правильным отмести эту версию и предположить, что ты не прав.
Народ еще и PHP использует...
A>Можно и нужно интерпретировать как "fork — опасный инструмент с помощью которого легко напортачить, но если быть очень осторожным этого не случиться". Не надо больше интепретировать мои слова, если не понял сразу. Лучше переспроси, а я уточню.
Форк это не инструмент. Это маразм. Форк создает массу вопросов на которые нет однозначного ответа.
Например: Нужно клонировать потоки или нет? Как клонировать сокет? И много чего другого.
A>Например послал русский текст в win1251, получил в UTF-8/koi8-r.
У нас протокол который работает с пачкой октетов.
Откуда в нем возьмется изменение кодировки?
A>У тебя какая-то неправильная практика. Например сейчас (буквально в этом месяце) у нас скупили всей такой техники (и много другой) на где-то 10% больше необходимого. по одной запасной штучке минимум. Даже не для того чтобы восстановить данные, а чтобы время ремонта сводилось ко времени замены детали. Плюс к этому все важные файлы храняться в DFS, так что отказ любого узла DFS кластера не отражается на пользователях. Вобщем все эти проблемы от сгорающих контроллёров от жадности.
Ты вобще читаешь что я пишу?
Я сказал что используется написанный руками распределенный рейд 0+1.
A>Даже не представляю задачу на которую не хватит функциональности DFS и SQL кластеров.
А они есть.
WH>>2)DFS это вобще смех на палочке. A>Да, серьёзный аргумент. Глубина мысли поражает.
Ты сам то описание этого чуда читал?
A>У SQL сервера есть свои failover кластеры, зачем их поверх DFS ставить? Чем больше я читаю то что ты пишешь, тем больше понимаю что в вопросе ты не сечёшь.
A>Ещё раз, есть кластеризация БД не только для балансировки нагрузки но и для отказоустойчивости. Ты можешь её отрицать, но она есть.
Нет. Ты меня не читаешь.
A>RAID5 дохнет при выходе их строя двух носителей.
Правильный ответ: Один винт.
Сам догадаешься почему?
Устройство рейдов я знаю не хуже чем ты.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Забавно, что все между бесплатным Apache и бесплатным light HTTPd выбирают Apache хотя он, по твоему мнению хочу. Я конечно могу предположить, что мир сошёл с ума, но мне кажется более правильным отмести эту версию и предположить, что ты не прав. WH>Народ еще и PHP использует...
Да-да, в списке этого народа, например Yahoo!. Те ещё неудачники. Честно, они просто придурки что взяли PHP! Долой PHP! PHP, уходи! PHP, уходи! PHP, уходи! Овации публики. СМИ сообщают об одуванчиковой революции в рунете. Все правительственные сайты Грузии и Украины отказываются от использования PHP! Путин приказывает изобрести нано-PHP работающий на нано-скоростях с нано-производительность.
Право, не могу об этом говорить в другом тоне, слишком уж смешные вещи ты пишешь.
WH>Форк это не инструмент. Это маразм. Форк создает массу вопросов на которые нет однозначного ответа.
Форк создает массу вопросов на которые нет стандартизированного ответа.
WH>Например: Нужно клонировать потоки или нет? Как клонировать сокет? И много чего другого.
Сокет клонируется как и все другие I/O дескрипторы. Кажется и в винде и никсах принципиальных различий между использованием сокета, пайпа и файла нет.
A>>Например послал русский текст в win1251, получил в UTF-8/koi8-r. WH>У нас протокол который работает с пачкой октетов. WH>Откуда в нем возьмется изменение кодировки?
Как я уже писал выше: кривой софт железки.
WH>Ты вобще читаешь что я пишу? WH>Я сказал что используется написанный руками распределенный рейд 0+1.
Зря писали
WH>Ты сам то описание этого чуда читал?
А зачем мне описание, я его каждый день вживую вижу
A>>RAID5 дохнет при выходе их строя двух носителей. WH>Правильный ответ: Один винт. WH>Сам догадаешься почему? WH>Устройство рейдов я знаю не хуже чем ты.
После отказа одного винта RAID5 переходит в аварийный режим. Это ещё не отказ тома вообще, это просто большая жопа. Вот если в аварийном режиме ещё что-то случиться, тогда да, хана. Кстати я сегодня встреечался с один хорошим человеком и вдохновлнный тобой побеседовал на тему рейдов. Оказывается есть аппартные контроллёры, которые не позволяют тебе пихать в рейд винты одного производителя. Надо именно винты разных производителей с одинаковой геометрией. Такая херня явно только для RAID5 и нужна.
Здравствуйте, adontz, Вы писали:
A>>>В итоге ты опять получишь синглтон, только в крайне извращённой форме. Правой рукой левое ухо... C>>Не обязательно. Фабрику можно настроить, чтобы она штамповала новые объекты по требованию и т.п.
A>Да вобщем-то синглтон и так создаётся по требованию
Проблема синглетона не в том, как он создаётся, а в нарушении SRP.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, adontz, Вы писали:
A>>>Да вобщем-то синглтон и так создаётся по требованию _FR>>Проблема синглетона не в том, как он создаётся, а в нарушении SRP.
A>Это лечится на раз внешним шаблонным создавателем.
Верно, но что тогда отличает "внешний шаблонный создавателель" от фабрики?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, adontz, Вы писали:
A>Право, не могу об этом говорить в другом тоне, слишком уж смешные вещи ты пишешь.
Смешные они только для тех кто делал сайты на которые никто не ходит.
A>Форк создает массу вопросов на которые нет стандартизированного ответа.
А нет его по тому что любой ответ на любой вопрос порождает проблемы.
A>Как я уже писал выше: кривой софт железки.
Какрй еще софт?
Протокол работвет с октетами.
Он ничего про кодировки не знает.
А если софт корежет пачки октетов то железка вобще неработоспособна.
WH>>Ты вобще читаешь что я пишу? WH>>Я сказал что используется написанный руками распределенный рейд 0+1. A>Зря писали
И как ты предлагаешь решать проблему выхода из строя одной машины?
Или отключения электричества?
A>А зачем мне описание, я его каждый день вживую вижу
А вот я почитал что о нем написано у мелкософтов...
Эта хрень не решает вопросы конкурентной записи в файл.
Да и вобще настораживает что нет описания архитектуры системы. Те скорей всего там присутствует масса сценариев кода вся система пойдет в разнос.
А главное данная система расчитана на неспешную репликацию данных между удаленными офисами.
Мне нужны мягко говоря иные характиристики.
A>После отказа одного винта RAID5 переходит в аварийный режим.
Я про рейды знаю больше тебя.
Сам поймешь почему выход одного винта может привести к потери данных?
Или нужно расказать?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, _FRED_, Вы писали:
_FR>Верно, но что тогда отличает "внешний шаблонный создавателель" от фабрики?
Фарбрика создаёт подтипы некотрого типа, а то что создаёт "внешний шаблонный создавателель" никак не регламентируется.
Хотя с некоторой натяжкой, "внешний шаблонный создавателель" вполне можно считать очень узкоспециализированной разновидностью фабрики, я бы воздержался.
Здравствуйте, WolfHound, Вы писали:
WH>И как ты предлагаешь решать проблему выхода из строя одной машины?
На уровне файлов DFS'ом, на уровне БД средствами БД.
WH>Или отключения электричества?
UPS'ом
WH>А вот я почитал что о нем написано у мелкософтов... WH>Эта хрень не решает вопросы конкурентной записи в файл.
Если бы у меня было такое, я бы на БД переехал не задумываясь. Файлы должен писать кто-то один.
WH>Да и вобще настораживает что нет описания архитектуры системы. Те скорей всего там присутствует масса сценариев кода вся система пойдет в разнос.
Это бред, потому что через File Replication Service передаётся уйма настроек Active Directory. Если бы там были малейшие глюки AD была бы неработоспособна.
WH>А главное данная система расчитана на неспешную репликацию данных между удаленными офисами.
Не знаю откуда ты это взял, это не правда. У нас два сервера стоят рядышком, репликация небольших файлов занимает пару секунд. Для документов это более чем нормально.
A>>После отказа одного винта RAID5 переходит в аварийный режим. WH>Я про рейды знаю больше тебя. WH>Сам поймешь почему выход одного винта может привести к потери данных? WH>Или нужно расказать?
Если вышел из строя только один винт и его заменили до того как вышел из строя другой то никакой потери данных не будет. А твоё "может привести" называется "вышло из строя два винчестера".
Здравствуйте, adontz, Вы писали:
A>Фарбрика создаёт подтипы некотрого типа, а то что создаёт "внешний шаблонный создавателель" никак не регламентируется. A>Хотя с некоторой натяжкой, "внешний шаблонный создавателель" вполне можно считать очень узкоспециализированной разновидностью фабрики, я бы воздержался.
Здравствуйте, _FRED_, Вы писали:
A>>Фарбрика создаёт подтипы некотрого типа, а то что создаёт "внешний шаблонный создавателель" никак не регламентируется. A>>Хотя с некоторой натяжкой, "внешний шаблонный создавателель" вполне можно считать очень узкоспециализированной разновидностью фабрики, я бы воздержался.
_FR>Это уже каузистика
Не, это я погнал Я почему то решил что речь об абстрактной фабрике, вот и затянул "создаёт подтипы некоторого типа..."
синглетона, не решаемая "создавателем" — глобальность. То есть, по-хорошему, "создаватель" надо подпихивать тому, кто им будет пользоваться. Не так ли?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Help will always be given at Hogwarts to those who ask for it.
синглетона, не решаемая "создавателем" — глобальность. То есть, по-хорошему, "создаватель" надо подпихивать тому, кто им будет пользоваться. Не так ли?
Тут как бы надо разделить. Неглобальный создатель вполне может создать (точнее вернуть, откуда-то взяв) нечто глобальное.
Здравствуйте, adontz, Вы писали:
WH>>Или отключения электричества? A>UPS'ом
Ты не понял. Электричество в половине города выключили.
A>Если бы у меня было такое, я бы на БД переехал не задумываясь.
Для того чтобы БД не дохли от нагрузки их приходится очень акуратно готовить.
Фактически создается своя БД которая использует готовые БД как отказоустойчивое хранилище индексированных табличек.
Еще очень распространен паттерн: write only master and read only slave(s).
A>Файлы должен писать кто-то один.
Наивный.
Кстати хранить файлы в БД это очень плохая идея...
A>Это бред, потому что через File Replication Service передаётся уйма настроек Active Directory. Если бы там были малейшие глюки AD была бы неработоспособна.
Вобще говоря DFS использует Remote Differential Compression
A>Не знаю откуда ты это взял, это не правда. У нас два сервера стоят рядышком, репликация небольших файлов занимает пару секунд. Для документов это более чем нормально.
А мне нужна кислотная (ACID) репликация.
Читай распределенные транзакции.
A>Если вышел из строя только один винт и его заменили до того как вышел из строя другой то никакой потери данных не будет. А твоё "может привести" называется "вышло из строя два винчестера".
Один вышел из строя. А второй заменил админ... по ошибке.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
синглетона, не решаемая "создавателем" — глобальность. То есть, по-хорошему, "создаватель" надо подпихивать тому, кто им будет пользоваться. Не так ли?
A>Тут как бы надо разделить. Неглобальный создатель вполне может создать (точнее вернуть, откуда-то взяв) нечто глобальное.
Ты имеешь в виду что-то такое:
public class Singleton<T> where T : new()
{
// Глобальные данныеprivate static readonly T instance = new T();
public T Instance {
get { return instance; }
}
}
//… где-то в коде
{
// Неглобальный создатель
Singleton<MyClass> s = new Singleton<MyClass>();
s.Instance.SomeMember…
}
... << RSDN@Home 1.2.0 alpha rev. 717>>
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, WolfHound, Вы писали:
WH>>>Или отключения электричества? A>>UPS'ом WH>Ты не понял. Электричество в половине города выключили.
А в чём проблема? UPS держит 30 минут свободно, спец-движок запускается секунд за 30 после отключения питания. Ну если ты ещё и бензин забыл залить, тогда едействительно ой. А бывают ещё UPSы на целое здание (в знакойо фирме есть) когда электричество вырубают люди туда бегают футбол смотреть. пол подвала — UPS.
WH>Для того чтобы БД не дохли от нагрузки их приходится очень акуратно готовить. WH>Фактически создается своя БД которая использует готовые БД как отказоустойчивое хранилище индексированных табличек. WH>Еще очень распространен паттерн: write only master and read only slave(s).
Что-то у меня стойкое впечатление, что SQL failover кластер порвёт этот велосипед и по производительности и по функциональности.
A>>Файлы должен писать кто-то один. WH>Наивный. WH>Кстати хранить файлы в БД это очень плохая идея...
Смотря как хранить. Хранить только пути более традиционно, но не всегда это лучшее решение.
A>>Это бред, потому что через File Replication Service передаётся уйма настроек Active Directory. Если бы там были малейшие глюки AD была бы неработоспособна. WH>Вобще говоря DFS использует Remote Differential Compression
Я про codebase.
WH>А мне нужна кислотная (ACID) репликация. WH>Читай распределенные транзакции.
Это к DTS серверу обращайся. Хотя сделать всё на БД явно на порядки проще.
A>>Если вышел из строя только один винт и его заменили до того как вышел из строя другой то никакой потери данных не будет. А твоё "может привести" называется "вышло из строя два винчестера". WH>Один вышел из строя. А второй заменил админ... по ошибке.
Забавные у тебя админы Вот у меня, например, сейчас дома комп на матернке ASUS M2N-E SLI. Она держит SATA RAID 0, 1, 5, JBOD и некоторые комбинации. Я это к тому описываю чтоб просто было понятно что это явно не супер-пупер оборудование. Эта штукенция поддерживает Hot-Swap винтов в рейде (зачем мне это дома не спрашивать!), у часов появляется значок Safely Remove Hardware и прочие прибамбасы. Так вот, я просто не могу вытащить неповреждённый винт. Мне его не дают отключить. Совсем. Учитывая что у продвинутых моделей светодиодная индикация около штекера, надо быть попросту бухим чтобы вытащить не тот винт. Ну и возвращаясь к уже написанному — RAID5 это бюджетный вариант, реально используется 0+1.
Здравствуйте, _FRED_, Вы писали:
A>>Тут как бы надо разделить. Неглобальный создатель вполне может создать (точнее вернуть, откуда-то взяв) нечто глобальное. _FR>Ты имеешь в виду что-то такое:
В принципе да, только не так примитивно. Вместо
public T Instance {
get { return instance; }
}
может быть что-то посложнее, например, какое-нибудь межпроцессное взаимодействие, или создание Remoting-объекта, или ещё что-то.
Здравствуйте, adontz, Вы писали:
A>А в чём проблема? UPS держит 30 минут свободно, спец-движок запускается секунд за 30 после отключения питания. Ну если ты ещё и бензин забыл залить, тогда едействительно ой. А бывают ещё UPSы на целое здание (в знакойо фирме есть) когда электричество вырубают люди туда бегают футбол смотреть. пол подвала — UPS.
Смешной ты.
Я говорю про вебсервер. Те нужно не только обеспечить электричеством датацентр (что само по себе не просто... ну очень много упсов понадобится) так еще и обеспецить работоспособность каналов которые тоже без электричества не работают.
В этом случае гораздо дешевле и надежнее обеспечить реполикацию в реальном времени между датацентрами.
И при выходе из строя одного датацентра данные будет отдавать другой.
A>Что-то у меня стойкое впечатление, что SQL failover кластер порвёт этот велосипед и по производительности и по функциональности.
Порвался SQL failover кластер... Проверяли.
A>Это к DTS серверу обращайся. Хотя сделать всё на БД явно на порядки проще.
Сдохнет от нагрузки.
A>Ну и возвращаясь к уже написанному — RAID5 это бюджетный вариант, реально используется 0+1.
Те кому дороги данные аппаратные рейды вобще не используют.
Короче ты тут расказываешь про всякие там чудодейственные технологие использование которых типа ведет к вселенскому счастью.
Но реально чудес не бывает.
И алгоритмические заморочки и главное человеческий фактор никто не отменял.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, akasoft, Вы писали:
A>WolfHound тебе походу намекает, что в его самописном решении типа исключён "человеческий фактор".
Полностью его конечно не исключить но сделать его сильно меньше чем в случае с тупыми рейдами можно.
В моем случае нужно поломать 2 машины стоящие в разных датацентрах. (при жилании колличество зеркал можно увеличить)
Думаю ты сам понимаешь что это сильно труднее чем случайно передернуть не тот винт.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>так еще и обеспецить работоспособность каналов которые тоже без электричества не работают.
То есть свитчам тоже поставить UPS'ы? Да, трудно конечно....
WH>Порвался SQL failover кластер... Проверяли.
A>>Это к DTS серверу обращайся. Хотя сделать всё на БД явно на порядки проще. WH>Сдохнет от нагрузки.
Ну да, велосипеды рулят. Интересно, times ten тоже сдохнет? Ты им напиши письмо, так мол и так, сдыхает...
A>>Ну и возвращаясь к уже написанному — RAID5 это бюджетный вариант, реально используется 0+1. WH>Те кому дороги данные аппаратные рейды вобще не используют.
Да нет, они просто не жмотяться запасной контроллёр купить
WH>Короче ты тут расказываешь про всякие там чудодейственные технологие использование которых типа ведет к вселенскому счастью. WH>Но реально чудес не бывает. WH>И алгоритмические заморочки и главное человеческий фактор никто не отменял.
Это ты предлагаешь во всех сложных задачах использовать лисапеды, потому что никто ещё не смог написать ни приличного DFS, ни приличной БД, ни рейд-контроллёр нормальный спаять и только WolfHound рулит
Здравствуйте, adontz, Вы писали:
A>То есть свитчам тоже поставить UPS'ы? Да, трудно конечно....
Электричество выключили в половине города.
Сдохли все каналы.
A>Ну да, велосипеды рулят. Интересно, times ten тоже сдохнет? Ты им напиши письмо, так мол и так, сдыхает...
NDA
A>Да нет, они просто не жмотяться запасной контроллёр купить
Бесполезно.
Например наднях у нас на одной машине в разнос пошли все винты разом. Сами винты живы но какимто образом на них разнесло файловую систему.
Если бы там был рейд то все. Хана данным. Ну или долгое и нудное соберание файлухи из кусочков.
А так мы просто переналили машину и перелили данные с зеркала.
Пользователи об этом даже не узнали. Ибо они получали ответы с живого зеркала.
A>Это ты предлагаешь во всех сложных задачах использовать лисапеды, потому что никто ещё не смог написать ни приличного DFS, ни приличной БД, ни рейд-контроллёр нормальный спаять и только WolfHound рулит
Я использую сторонние решения если они работают.
Например с удовольствием использую лайти. Работает очень хорошо и ниразу небыл узким местом.
Но если готовые решения не работают, а сделать нужно...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Kazna4ey, Вы писали:
K>Здравствуйте! K> Есть несколько вопросов по поводу subj'а.
K>1) В чем преимущество этого паттерна перед классом со статическими методами? K>2) Приведите хотя бы пару примеров где РЕАЛЬНО помогает реализация данного паттерна? K>3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton?
K>Спасибо.
Все топики не осилил.
Но возникли вопросы, правильно ли я поступаю.
Например я сделал синглтон для запись статитики в систему(приложение ASP.NET, ошибки, переход по ссылкам и прочие действия пользователя)
Я получил глобальный объект, который всегда в одном экземпляре и пишет мне в базу необходимые данные связанные со статисткой сайта.
Все работает, никаких минусов я не заметил.
Я для себя решил, что бы не создавать каждый раз объект статистики, я лучше сделаю синглтон, что бы сразу вызывать метод, а там уж сам синглтон пусть определяет, создавать объект статисктики или возвращать существующий.
Это является примером правильной реализации синглтона или нет? Может надо было сделать по другому?