Что забавно, так это то, что, если ООП код писать, следуя принципам SOLID, то в конечном итоге мы приходим именно к функциональному программированию :-)
Когда я работал над кастомным решением для построения Rich интерфейсов, аналогичном ExtJS, но в духе WPF, то у меня возникало ощущение, что я пишу браузер поверх другого браузера. С кучей оптимизаций, чтобы избавиться от лишних reflow и repaint. С кучей хаков, чтобы всё это выглядело идентично во всех браузерах. И никак не мог избавиться от ощущения, что если бы я напрямую работал с графической подсистемой, минуя HTML, то вышло бы на порядок проще.
HTML ограничивает разработку сложных интерфейсов. Для магазинов, блогов и разного рода социальных приложений, он отлично подходит, но как только требуется создать сложный интерфейс, то приходится делать множество лишних телодвижений, городить кучу JS кода, склеивающего хрупкую конструкцию из HTML/CSS.
Даже простейшую задачу центрирования одного блока произвольного размера внутри другого довольно сложно решить, не прибегая к хакам. Или ту же задачу растягивания внутреннего блока на всю высоту родительского, скажем, когда нам нужен 100 пиксельный хидер, а за ним 100%-100px блок контента, внутри которого ещё два блока с высотой по 50% от их родителя, и пятипиксельным отступом между ними.
Да, я знаю про flex box, про grid layout, и я буду счастлив, когда их доведут до ума и имплементируют во всех браузерах, хотя и они наверняка не покрывают всех случаев.
В контексте DDD и DSL, лучше смотреть не на пример с synchronized, а на эту картинку:
Хоть и этот пример тоже не совсем показателен, но MPS, помимо расширения Java, предполагает в том числе и создание нового языка, собственного DSL, на котором описывать бизнес-правила модели. При этом сохраняется полная поддержка со стороны IDE.
Вместо того, чтобы оперировать концепциями ООП, вы могли бы оперировать терминами из Ubiquitous Language и это, теоритически, было бы правильнее.
Можно, но насколько тесно можно интегрировать Roslyn в IDE? Насколько я знаю, сейчас это ограничивается лишь кодогенерацией перед билдом, и о поддержке конструкций вашего расширения в intellisence/debug-режиме речи не идёт.
Вопрос скорее в том, планируется ли официальная реализация C#. Я знаю, что есть вариант от Robert Hencke, и продолжение от mezastel, хотя и не знаю, если честно, насколько они хороши.
На практике, если класс имеет слишком много зависимостей — это bad design. Чаще всего это свойственно каким-то божественным объектам, нарушающим SRP. В этому случае имеет смысл подумать над пересмотром архитектуры системы.
Да, я знаю, ошибся уровнем комментариев :-) Впрочем, оттого, что socket.io не сможет найти поддержку WebSocket из-за того, что браузер работает с более новой версией протокола, и перейдёт на long-pooling или флэш мне не легче)
У WebSocket один минус: спецификация ещё не устаканилась, и время от времени выходят новые версии протокола, и при выходе новой версии браузеров, что-то может ломаться.
В случае если система доступа предполагает неограниченное количество паролей, дающих доступ к части информации, то терморектальный криптоанализ не эффективен.
Предположим, вы ищете финансовую информацию. С помощью паяльника вы узнали пароль жертвы, но он открыл доступ к поддельной информации. Что вы будете делать дальше? Вы не можете быть уверены в достоверности полученной информации, не можете быть уверены в её полноте, не знаете сколько всего различных паролей есть, не можете быть уверены даже в том, что данные ещё присутствуют на носителе, а не были уничтожены при введении указанного жертвой пароля.
> При работе над произведением художник/музыкант обычно начинает с этого самого «вектора зюйд-зюйд-вест» — с определенного настроения, концепции (рожденной внутри или выданной заказчиком, это в данном случае не столь важно). Конечный результат, в большинстве случаев, представляется весьма смутно. Справедливости ради отметим, что это — львиная доля удовольствия от творчества — делать как делается. Это, в сущности, и есть попытка «выразить себя».
Искусство и творчество — понятия очень широкие. Создать стройную систему — искусство. Написать шмат говнокода — тоже в каком-то смысле искусство… только уже ближе к области экспрессионизма в программировании.
Само по себе создание чего-то — творчество. Что же до конечного результата… проектируя систему, вы правда всегда себе представляете результат проектирования? Если действительно представляете, значит уже спроектировали, тем самым совершив акт творения.
Есть два крайних значения, когда в голове представления результата нет, и когда он уже есть. Переход — это и есть творчество. В первом случае нет ни ТЗ, ни документации. Во втором мы имеем идеальное ТЗ, которое целиком описывает систему, или же имеем саму систему, так как лишь готовая система может выступать в роли идеального ТЗ.
И до тех пор, пока мы не достигли этой второй точки, мы будем заниматься творчеством. Другое дело, что у джуниоров его не должно быть много, творчеством в основном должны заниматься бизнес-аналитики и архитектор.
Против каруселей и давления это не поможет. Против подтасовки результатов после подсчета голосов, когда протоколы, выдаваемые наблюдателям, тем или иным образом делаются недействительными, и в результате пишутся нужные цифры. Да и что толку, если к этим данным никто доступа не даст? Как и никто не станет пересчитывать бюллетени.
HTML ограничивает разработку сложных интерфейсов. Для магазинов, блогов и разного рода социальных приложений, он отлично подходит, но как только требуется создать сложный интерфейс, то приходится делать множество лишних телодвижений, городить кучу JS кода, склеивающего хрупкую конструкцию из HTML/CSS.
Даже простейшую задачу центрирования одного блока произвольного размера внутри другого довольно сложно решить, не прибегая к хакам. Или ту же задачу растягивания внутреннего блока на всю высоту родительского, скажем, когда нам нужен 100 пиксельный хидер, а за ним 100%-100px блок контента, внутри которого ещё два блока с высотой по 50% от их родителя, и пятипиксельным отступом между ними.
Да, я знаю про flex box, про grid layout, и я буду счастлив, когда их доведут до ума и имплементируют во всех браузерах, хотя и они наверняка не покрывают всех случаев.
Хоть и этот пример тоже не совсем показателен, но MPS, помимо расширения Java, предполагает в том числе и создание нового языка, собственного DSL, на котором описывать бизнес-правила модели. При этом сохраняется полная поддержка со стороны IDE.
Вместо того, чтобы оперировать концепциями ООП, вы могли бы оперировать терминами из Ubiquitous Language и это, теоритически, было бы правильнее.
Предположим, вы ищете финансовую информацию. С помощью паяльника вы узнали пароль жертвы, но он открыл доступ к поддельной информации. Что вы будете делать дальше? Вы не можете быть уверены в достоверности полученной информации, не можете быть уверены в её полноте, не знаете сколько всего различных паролей есть, не можете быть уверены даже в том, что данные ещё присутствуют на носителе, а не были уничтожены при введении указанного жертвой пароля.
Искусство и творчество — понятия очень широкие. Создать стройную систему — искусство. Написать шмат говнокода — тоже в каком-то смысле искусство… только уже ближе к области экспрессионизма в программировании.
Само по себе создание чего-то — творчество. Что же до конечного результата… проектируя систему, вы правда всегда себе представляете результат проектирования? Если действительно представляете, значит уже спроектировали, тем самым совершив акт творения.
Есть два крайних значения, когда в голове представления результата нет, и когда он уже есть. Переход — это и есть творчество. В первом случае нет ни ТЗ, ни документации. Во втором мы имеем идеальное ТЗ, которое целиком описывает систему, или же имеем саму систему, так как лишь готовая система может выступать в роли идеального ТЗ.
И до тех пор, пока мы не достигли этой второй точки, мы будем заниматься творчеством. Другое дело, что у джуниоров его не должно быть много, творчеством в основном должны заниматься бизнес-аналитики и архитектор.