Шпаргалка по шаблонам проектирования

У меня обычно с ними ассоциируется цитата Толстого «гладко было на бумаге, да забыли про овраги». :):):)

Шпаргалка по шаблонам проектирования

Жаль, что шаблоны не обозначены в языке. То есть пока коментарий не напишешь
/* это шаблон мост */, остается догадываться что там за шаблон.
Было бы что-то типа «implements template Bridge» — было бы понятнее

Многопоточность в Java: ExecutorService

Странно, что почти во всех примерах по многопоточности Java нет даже простых вычислений рациональности применения потоков.
типа int cores = Runtime.getRuntime().availableProcessors();

Может в одном потоке будет быстрее работать, так как не надо будет ждать блокировок

Многопоточность в Java: ExecutorService

В С++ сейчас столько наворотили, что специалистов, которые все это знают, становится все меньше. Один мой друг много лет программировал на С++ и WinAPI и даже выигрывал конкурсы Intel — решил как-то раз сдать собеседование в захудалой провинциальной конторе по С++. И не сдал!!! Просто закидали какими-то терминами и закопали буквами. Зато в Интел его взяли без проблем, так как приложения, которые они пишет выигрывают конкурсы.

Самое сложное в программировании это…

про «8. Невозможно всё знать»
У меня на собеседовании по java как то спросили теорему Чёрча-Росса в трех видах.
До сих пор чешу репу, — действительно ли я чего-то не знаю? :)

Почему объектно-ориентированное программирование — это отстой

По моим наблюдениям ООП моделирует предметную область от самого общего понятия объекта, постепенно конкретизируя. Как бы сверху вниз.

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

Несколько аргументов против Dependency Injection и Inversion of Control

тогда не обращайте внимания, условия еще не созрели

Несколько аргументов против Dependency Injection и Inversion of Control

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

идеи растут отсюда:
— биологическая теория эволюции Северцова
— и кибернетическая эволюция Турчина

Несколько аргументов против Dependency Injection и Inversion of Control

Я когда-то интересовался вопросом, — когда можно обобщать, а когда еще рано? Четких критериев не нашел.

В целом должно сойтись несколько условий для того, что бы обощение было удачным:
1) доведенные до предельной простоты базовые понятия.
2) четкая область применения, возможность специализации базовых понятий.
3) возможность усиления функций, интенсификации базовых понятий.

Когда эти качества доведены до предела, тогда для дальнейшего развития поможет только переход на следующий уровень организации, то есть в данном случае — обобщение. В противном случае уроень еще не исчерпан и равитие вполне может происходить на одном уровне. То есть можно дальше упрощать, специализировать и усиливать.

Несколько аргументов против Dependency Injection и Inversion of Control

Да, это извечная тема — чем модель отличается от явления, чем карта отличается от реальной местности, чем восприятие предмета отличается от самого предмета…

Несколько аргументов против Dependency Injection и Inversion of Control

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

Несколько аргументов против Dependency Injection и Inversion of Control

преждевременные обобщения вредят.

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

Несколько аргументов против Dependency Injection и Inversion of Control

В моем текущем проекте порядка 1 Гб исходников на ООП. Постоянно чувствую over-engineering изза того, что предметная область проще ООП. Незнания в предметной области выражаются в виде обобщений, которые зачастую уводят не туда, куда надо.

Несколько аргументов против Dependency Injection и Inversion of Control

То есть человек добавил новое значение в словарь и система упала?

Если это значение попало в процедуру, то должно или упасть, или выдать предупреждение с указанием места, куда надо добавить этот ID.

И что делать с требованиями «для любого договора верно следующее»?

Вот это надо подкрепить конкретным списком типов договоров. Обобщения вредят. Потом не разберешься что имелось в виду. В будущем все может измениться и слово «все типы договоров» будут означать совсем другое, чем имелось в виду на данный момент

Несколько аргументов против Dependency Injection и Inversion of Control

например, новый тип договора или документа, если это автоматизация предприятия

Несколько аргументов против Dependency Injection и Inversion of Control

Моя идея — новые данные, попавшие в программу должны вызывать исключение и из этого должно быть понятно куда добавлять обработку. То есть надо перечислять все случаи, когда программа должна работать. Все остальное должно её ронять. По крайней мере можно это сделать на этапе тестирования или на стенде у разработчиков. Подобный подход есть контрактном программировании. Я к такому выводу пришел, после нескольких лет работы на большом проекте, где действительно не разберешь куда вставлять новые обработчики.

Несколько аргументов против Dependency Injection и Inversion of Control

чтобы догадаться, куда нужно «воткнуть» обработку нового поля объекта из БД, то

Давно думаю над этой проблемой.

IMHO надо запретить использовать простой if на уровне языка. Вместо этого должна быть конструкция конструкция с семантикой.
if(...){...}else{ошибка}

Тогда если добавляешь что-то новое, что ты явно в программе не прописал, тогда сразу будет видно куда добавлять обработчик по такому принципу:

if(...){...}
if(...new...){...new...}
else{ошибка}

[UPDATED + Комментарии] Сначала они воруют, а когда ты побеждаешь, то тебя убивают

Когда условия сходятся, то многие идеи как бы напрашиваются сами собой. Если палкой можно копать, то рано или поздно кто-то начнет ей копать.

Как иприт начал лечить рак (более-менее)

ЯО — ядерное оружие
ВВ — взрывчатое вещество

Некоторые старые сокращения еще можно в играх, типа танков найти.

Метод конечных элементов на примере уравнения Пуассона

Я когда-то занимался моделированием плазмы, где это уравнение используется. Пришел к выводу, что никто не учитывает флуктуации. В идеальном газе, если в некотором небольшом объеме N частиц в среднем, то реальное количество частиц распределено по гауссу с сигмой 1/sqrt(N). Для некоторых компонент смеси это просто убивает гладкую модель, так как эти флуктуации не диссипируют, а наоборот усиливаются.