Мне кажется, есть небольшая разница между встроенной в Android framework поддержкой баз данных и использование сторонних библиотек для Windows phone 7. В статье речь шла про базовую функциональность. Поправьте, если я ошибаюсь.
Какая-то однобокая статья. Например, не сказано, что у Android есть встроенная поддержка базы данных SQLite для локального хранения информации. Т.е. статья выглядит так, как будто все то, что есть в Android, есть и в Windows Phone 7, хотя это не так.
Для меня, как нефунциональщика, приведенный в статье пример гораздо понятнее, чем приведенный вами в комментариях. Наверно, стоит сделать в статье сноску, почему так не следует писать, и что это приведено лишь для иллюстрации и наглядности для, так сказать, введения в язык. А после обретения навыков надо писать уже по-другому.
Да, статья очень интересная и познавательная. Но хотелось бы увидеть спектры для каждого типа ламп, для сравнения, так сказать, а также «эталонный» солнечный спектр в полдень.
В своем продукте выработали свой собственный стиль и стараемся его придерживаться. Для себя пишу в стиле Ultimate++. Он больше похож на то, что принято в C#. Только вместо class пишется struct, чтобы не писать потом сразу public:. При этом при наследовании не надо добавлять public, например: struct Button : Ctrl
{
Button();
...
};
Приведенные формулы в статье неправильные. Рассмотрим пример: сервер может обрабатывать только один поток, время CPU и ожидания одинаковы, т.е.:
t=1
c=w
Тогда очевидно, что сервер при использовании потоков сможет обработать только:
1000/(c+w) = 1000/2c
т.е. в 2 раза меньше, чем значение, указанное в статье. Более того, в реальности производительный софт использует следующий подход:
1. Проакторная модель: события асинхронные, по окончании события зовется callback.
2. События распрараллеливаются в t потоках.
3. Запросы могут включать в себя «легкую» логику (можно быстро вернуть ответ) и «тяжелую» (например, нужно обратиться к базе данных). «Легкая» логика обрабатывается тут же, «тяжелая» использует другой пул потоков. Для этого пула количество потоков уже, как правило, превышает t.
Таким образом в реальности продвинутые высоконагруженные сервера используют гибридную модель.
SRP не упомянул, хотя можно было бы. На мой взгляд, данный факт является более теоретическим и является довольно спорным. Но, как несложно догадаться, приведенный подход решает также и эту проблему.
An — это не класс-синглтон, его можно создавать как угодно. Синглтон заливается через функцию anFill. An можно копировать и иметь несколько экземпляров без каких-либо проблем.
В русскоязычной литературе чаще используется слово синглтон, чем одиночка. Поэтому я посчитал, что будет более понятнее и естественнее использовать это слово.
struct Button : Ctrl
{
Button();
...
};
Очень удобно и практично.
t=1
c=w
Тогда очевидно, что сервер при использовании потоков сможет обработать только:
1000/(c+w) = 1000/2c
т.е. в 2 раза меньше, чем значение, указанное в статье. Более того, в реальности производительный софт использует следующий подход:
1. Проакторная модель: события асинхронные, по окончании события зовется callback.
2. События распрараллеливаются в t потоках.
3. Запросы могут включать в себя «легкую» логику (можно быстро вернуть ответ) и «тяжелую» (например, нужно обратиться к базе данных). «Легкая» логика обрабатывается тут же, «тяжелая» использует другой пул потоков. Для этого пула количество потоков уже, как правило, превышает t.
Таким образом в реальности продвинутые высоконагруженные сервера используют гибридную модель.