То-то для некоторых задач используют уравнения Максвелла, для некоторых квантовую теорию, а для некоторых закон Кулона. Причем во всех трех случаях задачи по электрическому взаимодействию. Какой из трех подходов назначим общественно значимым?
С точки зрения эволюции гораздо эффективнее один раз вложиться государству или мировому сообществу (вспомним, например, Большой адронный коллайдер)
Большой адронный коллайдер — это конечно круто, Но в него вкладывалось не мировое сообщество целиком, а конкретные научные организации (да, их было много). И у этого коллайдера есть десяток конкурентов поменьше.
Ну вообще издатели — это такие инвесторы. Приходит автор, говорит я хочу написать и издать книгу, для этого мне нужно столько то денег. Дальше издательство вносит свою долю деньгами (а так же работами по продвижению и изданию написанной книги), автор — написанием текста книги. Дальше после издания книги они оба получают прибыль окупая затраты (да, там есть ньюансы с тем когда автор начинает получать эту прибыль (роялти), но это зависит от конкретного договора). Если автора схема не устраивает — он может пойти взять кредит в банке под залог, например, квартиры и издаваться сам. Вся прибыль будет его (за исключением процентов банка), однако если не окупится — отвечать по кредиту тоже будет только он.
Но самое главное, что по факту, если не использовать нормальные исключения (т.е., использовать FaultException), то выясняется, что в WCF паттерн, описанный в статье, прекрасно реализуется без какого-либо велосипеда.
Вот да. Проще всего собрать все валидационные сообщения, положить их в коллекцию и только после этого бросить FaultException типизованный этой коллекцией. А на клиенте спокойно разобрать эту коллекцию валидационных сообщений как нужно.
То что lair описал — это не наследование, а декоратор:
public class BaseClass
{
public void DoSmthng(obj param)
{
.....
}
}
public class Wrapper
{
private BaseClass _innerObj = new BaseClass();
public void DoSmthng(obj param)
{
...
_innerObj.DoSmthng(param);
}
}
Угу. поэтому, видимо, вынесение решарпера в отдельный процесс решит проблему с кончающейся памятью? Я, если что, тоже работаю с решарпером на большом проекте (около 100 проектов в солюшне). И основная проблема там в недостатке памяти.
Вы бы почитали что авторы пишут. Отдельный процесс решарпера там потому что IDE на Java. Они не захотели портировать решарпер на Java. Поэтому отдельный процесс и обмен с помощью бинарного протокола.
Так вот, то что вы сделаете с высшим образованием, приведет к тому, что выпускники вузов тоже не будут обладать квалификацией. И да, чтобы вы знали, специальность «Программист» — это специальность среднего специального заведения (ПТУ и иже с ним).
Слушайте, ну не нужны вам сотрудники с высшим образованием, а ПТУ-щники, ну и набирайте их. В чем проблема-то? Там уже выполняется все что вы хотите:
1. вступительные экзамены? чистая формальность.
2. выпускные экзамены — тоже самое.
3. Независимые сертификации — да полно их. А если не устраивают — сделайте свою.
Зачем вы хотите сломать текущее высшее образование мне не понятно.
Не должен. По определению паттерна Dependency Injection классу-клиенту безразличны любые аспекты реализации зависимости. Значение имеет только контракт (интерфейс).
Ну так либо интерфейс зависимости является IDisposable и тогда клиент знает что любая пришедшая сюда зависимость Disposable (и это не деталь реализации а контракт), либо не нужно ее диспозить.
Предположим, у вас есть такой ресурс, как соединение (IConnection)
Его контракт не допускает параллельное использование в нескольких разных задачах.
Поддержка соединения в рабочем состоянии кое-чего стоит, но создание нового.гораздо дороже.
Вы хотите полностью развязать себе руки в части выбора способа управления соединениями, при этом сохранив все возможности достичь максимальной эффективности.
Нет никакого смысла позволять клиентам делать вызов Dispose для соединения, так как вам вовсе не нужно закрывать его каждый раз.
Но нельзя давать соединение новому клиенту, если его еще использует старый.
Большой адронный коллайдер — это конечно круто, Но в него вкладывалось не мировое сообщество целиком, а конкретные научные организации (да, их было много). И у этого коллайдера есть десяток конкурентов поменьше.
Вот да. Проще всего собрать все валидационные сообщения, положить их в коллекцию и только после этого бросить FaultException типизованный этой коллекцией. А на клиенте спокойно разобрать эту коллекцию валидационных сообщений как нужно.
1. вступительные экзамены? чистая формальность.
2. выпускные экзамены — тоже самое.
3. Независимые сертификации — да полно их. А если не устраивают — сделайте свою.
Зачем вы хотите сломать текущее высшее образование мне не понятно.
Ну так либо интерфейс зависимости является IDisposable и тогда клиент знает что любая пришедшая сюда зависимость Disposable (и это не деталь реализации а контракт), либо не нужно ее диспозить.
Про коннекшн пул не слышали? Типовой паттерн.