├── .gitignore ├── README.md ├── Архив └── skype-discussion.txt ├── Источники.md └── Принципы ├── Говори, а не спрашивай (Tell Dont ask).md ├── Закон Деметры (law of demeter).md ├── Закон дырявых Абстракций (The Law of Leaky Abstractions).md ├── Принцип Разделения Интерфейса (Interface segregation principle).md └── Сокрытие (Information hiding).md /.gitignore: -------------------------------------------------------------------------------- 1 | .idea/ 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Принципы дизайна в JavaScript 2 | 3 | ## Идея 4 | Написать о принципах дизайна относительно JS с реальными примерами 5 | 6 | ## Цели 7 | 1. Описать распространённые принципы дизайна ПО с различных точек зрения 8 | 2. Вывести общие базовые понятия, лежащие в основе дизайна ПО 9 | 3. Описать мыслительный фреймворк, упрощающие следование принципам 10 | 4. Привести примеры кода на JS для каждого принципа, показывающие применение принципов и способов мышления 11 | 12 | -------------------------------------------------------------------------------- /Архив/skype-discussion.txt: -------------------------------------------------------------------------------- 1 | [09/07/14 17:56:32] Антон Шувалов: @question Все больше сталкиваюсь с middlewares, в express, в loa, в page.js, и мне очень нравится такой подход. Подскажите, что полезного можно почитать по этой теме? Я так понимаю, это не просто паттерн, это какая-то архитектура. Подскажите, пожалуйста, ссылок или кейвордов для гугла, где можно о полезных архитектурных решениях почитать в принципе. Ну или ссылок на модули с крутой архитектурой. 2 | [09/07/14 17:57:39] Alexey Migutsky: это паттерн Chain Of Responsibilities 3 | [09/07/14 17:58:04] Alexey Migutsky: ну и его вариации :) 4 | [09/07/14 18:02:04] Антон Шувалов: Спасибо! Заинтересовала тема паттернов, глядя как TJ ловко использует цепочку ответственности. А что можно почитать чтобы получить более-менее фундаментальное понимание этой темы? Стефанова? Такие паттерны называются «архитектурный паттерн», да? 5 | [09/07/14 18:03:34] Alexey Migutsky: Почитать - хз что. Понимание этого всего приходит тупо после надрыва мозга 6 | [09/07/14 18:03:43] Alexey Migutsky: "с опытом" :) 7 | [09/07/14 18:03:58] Alexey Migutsky: Надо как минимум пощупать несколько разных систем и, желательно, языков 8 | [09/07/14 18:04:03] Alexey Migutsky: я пока не встретил книгу, которая бы ок рассказывала про паттерны и нах они нужны, и как их грамотно применять, и тыды и тыпы 9 | [09/07/14 18:04:38] Alexey Migutsky: имхо, это просто тренировка мозга на тему "как можно сделать лучше этот кусок кода" 10 | [09/07/14 18:04:46] Андрей Листочкин: Да, он появился лет 20 назад на Перле, оттуда перекочевал в Джаву, потом руби, питон и наконец Нод 11 | [09/07/14 18:04:47] Alexey Migutsky: Но если совсем не знакомы - то НЕ читайте GoF, а начните с каких-нить Head First Design Patterns 12 | [09/07/14 18:05:00] Антон Шувалов: Я понимаю middlewares, но мне настолько это понравилось, когда я понял, что захотелось узнать, что еще есть похожего, классификацию и тд. 13 | [09/07/14 18:05:18] Alexey Migutsky: Можно ещё Фаулера почитать, но там Содом и Гоморра 14 | [09/07/14 18:05:26] Alexey Migutsky: зато архитектуры интересные и разные 15 | [09/07/14 18:05:40] Андрей Листочкин: На Java ищи servlet filters - по идее должно быть инфы на эту тему 16 | [09/07/14 18:05:55] Антон Шувалов: Понятно, спасибо :) 17 | [09/07/14 18:06:04] Alexey Migutsky: > классификацию и тд. 18 | Ну тут такое - классификация той же GoF зависит от парадигмы и большей частью основана на ООП и ООД 19 | [09/07/14 18:06:39] Alexey Migutsky: в ЖСе функции - первородные "жители" языка 20 | [09/07/14 18:06:50] Alexey Migutsky: что убивает часть паттернов ГоФ, потому что нах не нужны :) 21 | [09/07/14 18:06:58] Alexey Migutsky: Архитектура во многом зависит от контекста 22 | [09/07/14 18:07:53] Alexey Migutsky: В целом да, это архитектурные паттерны, и я по ним почитываю Фаулера - многобукаф, местами оч неоднозначно, но я пока не нашёл более менее вменяемого источника 23 | [09/07/14 18:09:12] Alexey Migutsky: Плюс ко всему, некоторые паттерны отличаются незначительными деталями. 24 | К примеру, чепочка ответственности не терминейтится, на скока я помню. 25 | А миддлваре терминейтится - и это уже другой паттерн, но из того же семейства :) 26 | [09/07/14 18:09:58] Nikita Butenko: Head First про паттерны же вроде хорошо http://shop.oreilly.com/product/9780596007126.do 27 | [09/07/14 18:11:04] Alexey Migutsky: я бы даже сказал "прекрасно", но мало :) 28 | [09/07/14 18:11:07] Alexey Migutsky: и контекста маловато 29 | [09/07/14 18:12:00] Alexey Migutsky: ну т.е. изучение паттернов имхо однозначно надо с хед ферст начинать 30 | [09/07/14 18:13:59] Антон Шувалов: А как вы читали? Перед сном? Или читали и пробовали сразу? 31 | [09/07/14 18:14:05] Андрей Листочкин: Вообще один из хороших вариантов прокачаться в плане архитектуре - поискать что-то на эту тему в более старых платформах. 32 | 33 | Хочешь знать, как делать масштабируемые системы? 34 | - transaction servers 35 | - Java EE 36 | - Erlang 37 | 38 | Хочешь прокачаться в плане архитектуры UI? 39 | - Cocoa 40 | - RAD 41 | - .NET/Xaml 42 | 43 | Интересна мобильная разработка? 44 | - Symbian 45 | - Java ME (андроид отсюда столько идей слизал - ууу) 46 | 47 | Все конечно, нужно делить надвое - многие паттерны и идеи либо неприменимы сегодня в том виде, в котором их придумали изначально, либо вообще стали частью языков и платформ. Но в целом, история ходит по кругу - десять лет назад все кричали, что SOA в Java - это очень сложно и надо валить на Рельсы, а сегодня - что SOA в Рельсах - это сложно и надо валить на Ноду :) 48 | [09/07/14 18:14:32] Антон Шувалов: Если просто перед сном почитчывать, то стоит ждать эффект? Я хочу с чего-то обзорного начать сперва 49 | [09/07/14 18:15:37] Антон Шувалов: Антон Шувалов не знает что такое SOA 0_0 50 | [09/07/14 18:17:03] Evgeniy Kurtov: SOA с рельсами действительно под большим вопросом 51 | [09/07/14 18:17:20] Джон, просто Джон: Service Oriented Architecture 52 | [09/07/14 18:18:39] Антон Шувалов: А, кажется немного понял: есть микро-паттерны, которые помогают писать рутинный код проще, типа, стратегии (?) и тд, есть более высокоуровневые паттерны, типа Chain of Responsibilities, которые определяют архитектуру фреймворков, и есть макро-паттерны на уровне языка/среды, которые определяют их возможности и класс задач, для которых они разрабатываются, правильно? 53 | [09/07/14 18:19:47] Evgeniy Kurtov: пока понятно одно - MVC это лишь один из архитекутрных шаблонов и далеко не всегда выгодный 54 | [09/07/14 18:19:55] Антон Шувалов: Head First даст мне хотя бы поверхностный обзор всех этих штук? Или лучше для этого начать с других книг, чтобы понять вообще, что мне нужно, и куда дальше копать? 55 | [09/07/14 18:20:46] Alexey Migutsky: > Если просто перед сном почитчывать, то стоит ждать эффект? Я хочу с чего-то обзорного начать сперва 56 | it depends от человека. 57 | Я теоретик, мне норм заходит без практики, потому что я так привык. 58 | 59 | Но лучше сразу пробовать 60 | [09/07/14 18:21:11] Alexey Migutsky: > и класс задач, для которых они разрабатываются, правильно? 61 | С языком не всё так просто, но в целом да :) 62 | [09/07/14 18:21:26] Ivan Motiienko: On 09/07/14, at 18:20, Антон Шувалов wrote: 63 | > Head First 64 | как раз хорош для въезжания 65 | [09/07/14 18:21:38] Alexey Migutsky: Плюс у микро-паттернов и макро-паттернов своя классификация - типа "структурные паттерны", "паттерны создания всякой шняги", "паттерны дающие нужное поведение" 66 | [09/07/14 18:22:07] Ivan Motiienko: но там все паттерны под жаву 67 | [09/07/14 18:22:21] Alexey Migutsky: Макро-паттерны - это скорее к системным паттернам - всякие шины данных, организация флоу кода/данных, интеграция 68 | [09/07/14 18:22:48] Антон Шувалов: Ага, классификация — одна из основных вещей, которые меня тут сейча интересуют 69 | [09/07/14 18:22:51] Alexey Migutsky: > пока понятно одно - MVC это лишь один из архитекутрных шаблонов и далеко не всегда выгодный 70 | MVC сам по себе далеееееекооооо не один шаблон, а "Самая Большая Ошибка Большинства Девелоперов" 71 | [09/07/14 18:23:03] Sergey Koval (DymokSR): кто-нибудь работал с socket.io из objective c? 72 | [09/07/14 18:23:07] Alexey Migutsky: потому что подвидов этого "МВЦ" существует ёбом, и дьявол в мелочах 73 | [09/07/14 18:23:25] rosko.com.ru: rosko.com.ru added re0ne.skype to this conversation 74 | [09/07/14 18:23:26] Alexey Migutsky: чего стоит тока MVC Model 2, который в джава мире в JSP 75 | [09/07/14 18:23:42] Alexey Migutsky: Сломал жизнь половине джавистов - они всё воспринимают сквозь призму модел2 76 | [09/07/14 18:23:46] Sergey Koval (DymokSR): в том плане, что насколько я понимаю, у socket.io свой протокол 77 | [09/07/14 18:23:57] Антон Шувалов: А что скажите насчет «Идеального кода» и «Рефакторинга»? Посоветовали их еще почитать по паттернам. Да и давно в списке на чтение стоят 78 | [09/07/14 18:23:57] Alexey Migutsky: > но там все паттерны под жаву 79 | Под ООД скорее 80 | [09/07/14 18:23:59] Sergey Koval (DymokSR): т.е. либо нужно реализовать работу с ним самому, либо уже есть готовая либа/класс/фреймворк 81 | [09/07/14 18:24:18] Sergey Koval (DymokSR): есть https://github.com/pkyeck/socket.IO-objc 82 | [09/07/14 18:24:22] Alexey Migutsky: > Ага, классификация — одна из основных вещей, которые меня тут сейча интересуют 83 | Начни с Хэд Фёст, и потом по гуглу 84 | [09/07/14 18:24:41] Sergey Koval (DymokSR): но у них совместимость до 0.9.х 85 | [09/07/14 18:24:44] Alexey Migutsky: Я реально не знаю норм классификации на разных уровнях, и даже хз как это найти 86 | [09/07/14 18:25:02] Alexey Migutsky: > т.е. либо нужно реализовать работу с ним самому, либо уже есть готовая либа/класс/фреймворк 87 | Ищи готовые решения на гитхабе. 88 | [09/07/14 18:25:12] Alexey Migutsky: СокетИО есть реализация под разные языки и окружения 89 | [09/07/14 18:25:18] Alexey Migutsky: но тока с 1.0+ работать вряд ли будет 90 | [09/07/14 18:25:35] Sergey Koval (DymokSR): у меня сейчас socket.io 1.0.6 91 | [09/07/14 18:25:39] Alexey Migutsky: > но у них совместимость до 0.9.х 92 | А с новыми сокетами никто щас работать и не будет - им пару месяцев от роду :) 93 | [09/07/14 18:26:28] Sergey Koval (DymokSR): есть еще мысль uiwebview воспользоваться :) 94 | [09/07/14 18:27:53] Alexey Migutsky: ну можно поковырять 95 | [09/07/14 18:27:57] Alexey Migutsky: там приоритет транспортов сменился 96 | [09/07/14 18:28:01] Alexey Migutsky: апи вроде как компэтибл 97 | [09/07/14 18:28:10] Alexey Migutsky: ну по крайней мере слой совместимости я там видел краем глаза 98 | [09/07/14 18:43:54] Kirill Cherkashin: Вот хочу насчет паттернов от себя вставить: я читал читал все эти книги и не мог воткнуть, че они все от меня хотят и зачем это нужно, а потом сел за Java и сразу стало многое ясно, а паттерны - частью общения, когда ты это используешь и понимаешь что и зачем, намного проще объяснить деву рядом с тобой, что ты сделал фабрику для того-то и того-то 99 | [09/07/14 18:44:59] Kirill Cherkashin: Но многие паттерны в джаве тупо призваны решить проблемы языка, например в джаве до недавнего функции не были объектами первого класса, у них для этого стратегии, в JS стратегии тоже можно использовать, но совсем другой юз кейс 100 | [09/07/14 18:45:24] Kirill Cherkashin: Поэтому если читать про паттерны в Джаве, надо писать на джаве, иначе намного сложнее будет разабраться 101 | [09/07/14 18:46:08] Антон Шувалов: Ну, эта часть меня интересует несколько меньше, чем построение гибкой и масштабируемой архитектуры (не знаю, вообще, возможно ли такое). 102 | [09/07/14 18:47:32] Антон Шувалов: И, да, про язык согласен. Читал «Программист-прагматик» с примерами на java/smalltalk и не во все понимал. Примеры хочется по js. 103 | [09/07/14 18:48:19] Антон Шувалов: Вспоминается только Стоян Стефанов. Вот стоит, интересно, его читать? Я бегло смотрел первую треть, очень многое мне давно знакомо. 104 | [09/07/14 18:48:59] Антон Шувалов: чейнинги через `return this;` в методах не особенно интересуют, я в такие «паттерны» уже умею, вроде 105 | [09/07/14 18:49:03] Kirill Cherkashin: Ну здесь та же история, например параллализм (concurency) в джаве и в JS совсем вообще разные вещи и работает все совсем подругому 106 | [09/07/14 18:49:25] Антон Шувалов: То есть, мой интерес — развить скиллы проектирования приложений 107 | [09/07/14 18:49:42] Kirill Cherkashin: Просто когда пишут книгу про джаву многие мелочи, которые знакому любому джава разработчику остаются за кадром, тут дело не только в понимании синтаксиса 108 | [09/07/14 18:49:51] Probably Kira: Стефанов "паттерны"? 109 | [09/07/14 18:50:07] Probably Kira: я читала, неплохо. 110 | [09/07/14 18:51:56] Alexey Migutsky: > То есть, мой интерес — развить скиллы проектирования приложений 111 | Тока опыт и дядьки типа Фаулера 112 | [09/07/14 18:52:54] Alexey Migutsky: У меня тоже такой интерес - многие ваще не понимают штойта и говорить про это не хотят/не могут :) 113 | [09/07/14 18:52:57] Alexey Migutsky: статьи про такое обычно пишут люди, которые видели кучу таких систем и могут сравнивать 114 | [09/07/14 18:53:03] Alexey Migutsky: а книг я вообще не знаю 115 | [09/07/14 18:53:53] Alexey Migutsky: http://www.eaipatterns.com/ 116 | [09/07/14 18:53:59] Alexey Migutsky: тока вот это мб в тему 117 | [09/07/14 18:54:08] Alexey Migutsky: но там надо делать скидку на интерпрайзность :) 118 | [09/07/14 18:54:24] Kirill Cherkashin: http://www.insight-it.ru/highload/ 119 | [09/07/14 18:55:29] Alexey Migutsky: это не то чучуть, это обзор решений 120 | [09/07/14 18:55:45] Alexey Migutsky: он мало что говорит о том, ПОЧЕМУ нужно делать и какие БЫЛИ альтернативы 121 | [09/07/14 18:55:52] Alexey Migutsky: нету принятия решений, что крайне важно 122 | [09/07/14 18:55:54] Alexey Migutsky: Хотя тоже тема :) 123 | [09/07/14 18:56:11] Alexey Migutsky: Отдельные статьи ваще нищтяк 124 | [09/07/14 18:57:49] Alexey Migutsky: Есть в загашнике ещё http://www.aosabook.org/en/index.html 125 | [09/07/14 18:57:57] Alexey Migutsky: но пока не читал 126 | [09/07/14 18:58:55] Kirill Cherkashin: прикольно, добавил на почитать 127 | [09/07/14 18:58:56] Alexey Migutsky: Но тут опять же - хайлоад это дизайн систем, энтерпрайз интеграция - о том же 128 | [09/07/14 18:59:32] Alexey Migutsky: А всякие там MVC vs MVVM и прочие Presentation Model и Monadic Parsers хрен в какой книге найдёшь 129 | [09/07/14 18:59:40] Alexey Migutsky: и терминология - мама не горюй, у всех своя 130 | [09/07/14 19:00:08] Alexey Migutsky: мне больше по душе Фаулер всё же в этом вопросе, у него хотя бы постоянство присутствует и он сам это всё анализировал 131 | [09/07/14 19:00:29] Alexey Migutsky: в статьях периодически встречаются отсылки на других чуваков, но у них ничо толкового я не нашёл 132 | [09/07/14 19:02:09] Alexey Migutsky: Есть ещё 133 | Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice, 2nd ed. Addison-Wesley Professional, 2003. 134 | туда я вообще никогда не смотрел, но на них ссылаются мелкомягкие 135 | [09/07/14 19:02:35] Alexey Migutsky: http://msdn.microsoft.com/en-us/library/ee658093.aspx 136 | [09/07/14 19:02:58] Kirill Cherkashin: 10 лет книге 137 | [09/07/14 19:03:03] Kirill Cherkashin: Как-то стремно 138 | [09/07/14 19:03:16] Kirill Cherkashin: А, не вот 2009 139 | [09/07/14 19:03:18] Kirill Cherkashin: второе издание 140 | [09/07/14 19:03:51] Alexey Migutsky: ну тут такое 141 | [09/07/14 19:04:06] Alexey Migutsky: архитектура UI вообще лет 30 назад зародилась 142 | [09/07/14 19:04:11] Alexey Migutsky: и особо ничего не менялось :) 143 | [09/07/14 19:04:15] Alexey Migutsky: те же биндинги, но в другой форме 144 | [09/07/14 19:04:51] Alexey Migutsky: Опять же, инфу по ним нарыть тяжело, особенно если не шаришь :) 145 | [09/07/14 19:06:38] Alexey Migutsky: http://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Architecture 146 | [09/07/14 19:07:12] Alexey Migutsky: раз уж пошла такая пьянка 147 | [09/07/14 19:08:58] Alexey Migutsky: Но опять же, большинство таких книг и статей - про дизайн систем 148 | [09/07/14 19:09:06] Alexey Migutsky: но не про то, как можно клёво компоновать свой код для простоты и красоты :) 149 | [09/07/14 19:10:22] Alexey Migutsky: т.е. я вот промежуточного уровня между "как нам заставить два аппа работать вместе" и "как нам заставить две функции работать вместе" особо не наблюдаю 150 | [09/07/14 19:12:31] Alexey Migutsky: Все эти чуваки просто вводят понятия "архитектуры" и "лоу левел дизайна" 151 | [09/07/14 19:12:45] Alexey Migutsky: архитектура - это слои и сервисы и их интеграция 152 | [09/07/14 19:12:55] Alexey Migutsky: а лоу левел - алгоритмы и "софтваре компоненты" 153 | [09/07/14 19:13:12] Kirill Cherkashin: Просто слишком много разных мелочей по дороге и слишком малому количеству людей это реально нужно 154 | [09/07/14 19:13:13] Alexey Migutsky: и всё 155 | [09/07/14 19:13:20] Alexey Migutsky: имхо хуета какая-то 156 | [09/07/14 19:13:46] Alexey Migutsky: нагуглить первое реально, нагуглить второе сложнее 157 | [09/07/14 19:14:01] Alexey Migutsky: а нагуглить промежуточные варианты - ваще ололо 158 | [09/07/14 19:14:23] Alexey Migutsky: такая вот бида :( 159 | Если кто-то знает как решить - с радостью выслушаю 160 | [09/07/14 19:14:44] Alexey Migutsky: > и слишком малому количеству людей это реально нужно 161 | Я бы сказал слишком мало людей осознаёт значимость этих знаний 162 | [09/07/14 19:14:52] Alexey Migutsky: ведь можно хуяк-хуяк 163 | [09/07/14 19:14:59] Alexey Migutsky: а через 2 года на новый проект :) 164 | [09/07/14 19:15:49] Kirill Cherkashin: Как решить, учиться самим и учить других 165 | [09/07/14 19:17:11] Alexey Migutsky: Так я за всё время общения с программистами видел всего 3-4 человек, которые бы вообще проблематику понимали 166 | [09/07/14 19:17:33] Alexey Migutsky: у всех остальных реакция типа "ууу, не, это оверинжениринг, о таком думать ну нафиг" 167 | [09/07/14 19:17:48] Kirill Cherkashin: А сколько проектов ты видел, где это реально нужно было бы? 168 | [09/07/14 19:19:22] Alexey Migutsky: все мои проекты, за редким исключением 169 | [09/07/14 19:19:27] Alexey Migutsky: ровно с тех пор, как я научился различать понятия "разных абстрактных уровней" 170 | [09/07/14 19:20:07] Alexey Migutsky: и плюс ко всему - проблема взаимодействия компонентов в коде (классы, иерархии классов, контрол флоу) встаёт вообще всегда 171 | [09/07/14 19:20:48] Alexey Migutsky: основная проблема - как инкапсулировать так, чтобы оставались НУЖНЫЕ экстеншн поинты, и всё это без постоянного бойлерплейта 172 | [09/07/14 19:20:57] Alexey Migutsky: это вообще всегда и всюду 173 | [09/07/14 19:22:13] Kirill Cherkashin: Ну так напиши статью про это дело, я тебя поддержу с удовольствием 174 | [09/07/14 19:26:54] Alexey Migutsky: так для того, чтобы написать статью - нужно утромбовать знания :) 175 | [09/07/14 19:27:07] Alexey Migutsky: а у меня на этапе классификации уже проблемы 176 | [09/07/14 19:27:34] Alexey Migutsky: плюс по собственному опыту - мыслить абстрактными категориями очень тяжело 177 | [09/07/14 19:27:43] Alexey Migutsky: а уж обсуждать их - ваще хана 178 | [09/07/14 19:31:11] Kirill Cherkashin: Поэтому придуманы примеры 179 | [09/07/14 19:33:34] Kirill Cherkashin: Когда мне говорят "как инкапсулировать так, чтобы оставались НУЖНЫЕ экстеншн поинты, и всё это без постоянного бойлерплейта", я в целом понимаю, но как мне это в жизни поможет - не вижу, а вот если мне показать, как в каком-то фремворке благодаря конкретному решению остается в два раза меньше кода, и что это частный случай вышенаписанного, мне интересно 180 | [09/07/14 19:37:06] Alexey Migutsky: Оно всем так 181 | [09/07/14 19:37:39] Alexey Migutsky: Но я не могу просто придумать синтетический пример 182 | [09/07/14 19:38:17] Kirill Cherkashin: Да, но у тебя же есть реальные проекты, где ты это применяешь 183 | [09/07/14 19:38:20] Ksenia Redunova: Стоян Стефанов хорошо про паттерны написал 184 | [09/07/14 19:38:21] Kirill Cherkashin: С реальными примерами 185 | [09/07/14 19:38:22] Kirill Cherkashin: И у меня 186 | [09/07/14 19:38:30] Alexey Migutsky: Обычно такие решения зависят и от домена, и от окружения 187 | [09/07/14 19:38:53] Alexey Migutsky: А экстеншен поинты вообще уникальны, если тачка не общеупотребимая 188 | [09/07/14 19:39:18] Alexey Migutsky: А на проекте я могу это коллеге объяснить 189 | [09/07/14 19:39:26] Ksenia Redunova: насчет архитектуры JS приложений - есть хорошие доклады на эту тему, я сейчас навскидку дать ссылки не смогу, могу завтра скинуть. 190 | [09/07/14 19:39:38] Alexey Migutsky: Но не могу его в паблик вытянуть 191 | [09/07/14 19:40:15] Alexey Migutsky: Ксюша, буду благодарен 192 | [09/07/14 19:40:26] Kirill Cherkashin: Ну надо обобщать 193 | [09/07/14 19:40:40] Ksenia Redunova: если забуду, пишите в личку, обязательно найду. Я давно этой темой интересуюсь. 194 | [09/07/14 19:40:58] Kirill Cherkashin: http://vk.com/doc10903696_195353516?hash=b3f9f3790ee3d24f6b&dl=1387f01871e3631562 195 | [09/07/14 19:41:18] Alexey Migutsky: Надо под это чатик, а то потеряемся 196 | [09/07/14 19:41:25] Ksenia Redunova: просто год назад на эту тему читала доклад на Hotcode 197 | [09/07/14 19:41:48] Ksenia Redunova: ну там простые паттерны, но в любом случае 198 | [09/07/14 19:42:09] Alexey Migutsky: Обобщение и дает в результате вздутые паттерны и кучу оверинжиниринга 199 | [09/07/14 19:43:25] Kirill Cherkashin: Ксения, видео есть? 200 | [09/07/14 19:43:35] Alexey Migutsky: Доклады обычно дают представление о конкретной системе, но не показывают альтернатив 201 | [09/07/14 19:46:51] Kirill Cherkashin: Обобщение обобщению рознь 202 | [09/07/14 19:48:43] Kirill Cherkashin: Мы на прошлом проекте всей командой спорили о том, как должны взаимодействовать виды, и модели в бэкбоне, через месяц пришли к решению, оно подходит для нашего проекта, но я думаю что я смог бы обобщить это дело и выделить условия, при которых оно было бы полезно другим людям 203 | [09/07/14 19:50:03] Alexey Migutsky: Да я много таких примеров видел, но в итоге все равно либо очень укзкую задачу решает, либо оверинжиниринг 204 | [09/07/14 19:50:26] Ksenia Redunova: к сожалению, видео нет, есть только слайды доклада http://www.slideshare.net/redunova/javascript-design-patterns-overview 205 | [09/07/14 19:50:50] Alexey Migutsky: В любой абстрактной системе важны принципы мышления 206 | [09/07/14 19:51:19] Ksenia Redunova: но там про мега-архитектуру сложных приложений нет - тут надо отдельный доклад готовить, что в принципе входит в мои планы на будущее ) 207 | [09/07/14 19:51:22] Alexey Migutsky: А паттерны - лишь промежуточные шаги 208 | [09/07/14 19:52:39] Alexey Migutsky: Вы про knowledge flow слышали, кстати? 209 | [09/07/14 19:53:02] Alexey Migutsky: Оно же принцип наименьшего знания 210 | [09/07/14 19:53:38] Alexey Migutsky: То, на чем якобы базируется devide and conquere 211 | [09/07/14 19:54:12] Alexey Migutsky: Если да, то удалось ли это объяснить коллеге хоть раз внятно? :) 212 | [09/07/14 19:54:32] Kirill Cherkashin: Ксения норм разложила, только что в книге, что в слайдах непонятно причем там JSLint между синглтонами и фабриками 213 | [09/07/14 19:55:58] Kirill Cherkashin: Что-то меня knowledge flow отправляет в статью про сноудена 214 | [09/07/14 20:37:07] Alexey Migutsky: А это не самый распространенный паттерн, я хз где я его откопал 215 | [09/07/14 20:37:26] Alexey Migutsky: Least knowledge principle погугли 216 | [09/07/14 21:19:53] Ksenia Redunova: ага, ну про JsLint это было лирическое отступление о том, что в народе называют "антипаттернами". 217 | [09/07/14 21:20:13] Ksenia Redunova: там я перечислила несколько примеров плохих практик и способы борьбы с ними 218 | [09/07/14 21:24:22] Антон Шувалов: А можно подробнее про knowledge flow? 219 | [09/07/14 21:40:48] Kirill Cherkashin: А, это так же исвестно как Law of Demeter 220 | [09/07/14 21:41:12] Kirill Cherkashin: Грубо говоря чем меньше других юнитов знает каждый отдельный юнит, тем лучше 221 | [09/07/14 21:42:39] Антон Шувалов: Понял, с этим я знаком, только под термином «сцепление/связывание кода» 222 | [09/07/14 21:42:49] Kirill Cherkashin: http://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%94%D0%B5%D0%BC%D0%B5%D1%82%D1%80%D1%8B 223 | [09/07/14 21:43:31] Kirill Cherkashin: Это не совсем оно, но это один из способов контролировать связывание, насколько я понимаю 224 | [09/07/14 22:16:10] Alexey Migutsky: > А можно подробнее про knowledge flow? 225 | Сорри, я от вас рано сбежал. 226 | 227 | Я про это читал как про "поток знаний" в компоненте. 228 | > А, это так же исвестно как Law of Demeter 229 | Это примерно он, но не совсем. 230 | Это действительно способ контроля связанности, который помогает о связях размышлять. 231 | 232 | Связи представляют собой "поток знаний" о каждом компоненте с точки зрения программиста 233 | [09/07/14 22:16:38] Alexey Migutsky: т.е. компоненты должны быть такими, чтобы программист не думал о том, где брать знания о компонентах 234 | [09/07/14 22:17:17] Alexey Migutsky: грубо говоря, когда программист работает с одним компонентом - он в идеале должен находиться в очень сжатом контексте 235 | [09/07/14 22:17:48] Alexey Migutsky: это касается как структуры на файловой системе, так и связей между компонентами, и ограничений самого фреймворка 236 | [09/07/14 22:18:10] Alexey Migutsky: Сюда привязываются SRP, LoD и ещё пара принципов 237 | [09/07/14 22:18:30] Ksenia Redunova: @patterns @паттерны 238 | вот нашла книги и ссылки на эту тему, именно по JS-паттернам: 239 | Writing Maintainable JS (Nickolas Zakas) - есть еще видео его доклада с таким же названием на youtube 240 | Patterns for Large-Scale JS Application Architecture (Addy Osmani) 241 | Learning JS Design Patterns (Addy Osmani) 242 | http://jsdesignpatterns.com 243 | http://shichuan.github.io/javascript-patterns/ 244 | есть еще серия статей "Angry birds of JS" - там тоже было неплохо рассказано про паттерны 245 | [09/07/14 22:19:00] Alexey Migutsky: т.е. при помощи вот этого knowledge flow удаётся одновременно контролировать поток данных, связи компонент, гранулярность и ряд других косвенных признаков хорошего кода 246 | [09/07/14 22:19:19] Alexey Migutsky: Мы исходим из того, что компонент должен знать только о своих зависимостях через их интерфейсы, он знает, что ему нужно для реализации минимальной задачи 247 | [09/07/14 22:19:33] Антон Шувалов: Patterns for Large-Scale JS Application Architecture (Addy Osmani) я перевел на русский 248 | [09/07/14 22:19:46] Антон Шувалов: http://largescalejs.ru/ 249 | [09/07/14 22:20:12] Антон Шувалов: Это, как я понял, развитие идей Закаса. 250 | [09/07/14 22:20:15] Alexey Migutsky: так вот, идея самого flow в том, что поток не должен "расширяться", или "растекаться" 251 | [09/07/14 22:20:38] Alexey Migutsky: т.е. логика не должна размазываться, минимум копирования кода, максимум инкапсуляции 252 | [09/07/14 22:20:44] Alexey Migutsky: и при расширении - затрагиваем минимум других компонент 253 | [09/07/14 22:21:37] Alexey Migutsky: при этом паттерн мышления тут такой - вы думаете, как будет работать с вашим кодом другой человек, и откуда ему черпать знания о работе вашего компонента - это помогает держать компоненты максимально близко друг к другу. 254 | [09/07/14 22:22:12] Alexey Migutsky: В идеале человек должен открыть одну папку и увидеть все составные части компонента 255 | [09/07/14 22:22:35] Alexey Migutsky: а при работе с компонентом он не выходит за рамки одного файла 256 | [09/07/14 22:23:11] Alexey Migutsky: Ну и получается такой постулат - клиент кода должен держать в памяти минимум знаний о компоненте, в иделе только то, что достаточно для работы самого компонента 257 | [09/07/14 22:23:39] Alexey Migutsky: Я встречал такое описание всего пару раз, и точно не знаю где 258 | [09/07/14 22:23:40] Alexey Migutsky: Частично оно упоминается вроде как в Чистом Коде 259 | [09/07/14 22:24:41] Ksenia Redunova: Антон Шувалов, это просто супер! Хочу тебя поблагодарить за перевод такой важной книги! 260 | [09/07/14 22:25:23] Alexey Migutsky: и получается мыслить примерно так: что должен знать этот компонент для реализации одной конкретной функции. Каждый такой "факт" можно выделить в другие компоненты, типа "поведения" или "состояния", которые соотв. знают только о состоянии, или только о поведении 261 | [09/07/14 22:25:52] Антон Шувалов: :-) 262 | [09/07/14 22:26:10] Alexey Migutsky: Антон, так ты после перевода должен нас всех консультировать :) 263 | [09/07/14 22:26:59] Alexey Migutsky: > для реализации одной конкретной функции. 264 | либо для выполнения конкретной роли - тут действует SRP 265 | [09/07/14 22:28:05] Антон Шувалов: Ну, такую архитекруту я более-менее понимаю, а вот сила цепочки зависимостей для меня только недавно открылась, и мне очень интересно разобраться получше с возможностями и альтернативами тут. 266 | [09/07/14 22:28:32] Alexey Migutsky: И "факты знаний" или "роли" компонента на разных уровнях абстракций могут слега отличаться. Т.е. в том же ангуляре - поведение в фреймворке той же директивы вполне конкретное, и не стоит раздувать эти знания, добавляя иное поведение - не стоит примешивать туда роль сервиса 267 | [09/07/14 22:29:28] Alexey Migutsky: и когда вы работаете с директивой, на уровне взаимодействия компонент ангуляра вы 100% знаете как она работает - соответственно об этом факте можно "забыть", когда вы переходите к коду, который реализует логику директивы 268 | [09/07/14 22:29:50] Alexey Migutsky: а на уровне логики - вы думаете только о логике, но не думаете как она влияет на поведение директивы в фреймворке 269 | [09/07/14 22:30:21] Alexey Migutsky: Т.е. это чисто шаблон мышления, позволяющий контролировать практики в коде относительно простым способом 270 | [09/07/14 22:30:35] Alexey Migutsky: избавляет код от магии и сайд эффектов 271 | [09/07/14 22:30:48] Антон Шувалов: Алексей, кажется, очень просится крутая статья от тебя) 272 | [09/07/14 22:31:01] Alexey Migutsky: тут же комментарии - если вы осознаёте, что вы делаете в коде "магию", то это знание нужно как-то закрепить 273 | [09/07/14 22:31:11] Alexey Migutsky: самый простой способ - оставить коммент об этом знании 274 | [09/07/14 22:31:15] Антон Шувалов: А то потом не найти в чате 275 | [09/07/14 22:31:29] Alexey Migutsky: > очень просится крутая статья от тебя 276 | Просится, но я не могу это просто так взять и сформулировать в читаемом виде :) 277 | [09/07/14 22:31:34] Alexey Migutsky: не умею я ещё круто писать 278 | [09/07/14 22:33:26] Alexey Migutsky: Так вот, в итоге мы имеем: 279 | 1. Наши компоненты состоят из "кусков знаний" 280 | 2. Таких кусков должно быть как можно меньше и они должны быть задокументированы в коде 281 | 3. Поток таких знаний через "границы" компонент должен быть минимальный 282 | 4. Знания со смежных уровней абстракции не должны пересекаться и зависеть друг от друга 283 | [09/07/14 22:33:54] Alexey Migutsky: Тут вам и декларативность 284 | [09/07/14 22:33:59] Alexey Migutsky: и ФП со своим отсутствием сайд-эффектов и наличием однозначных функций 285 | [09/07/14 22:34:03] Alexey Migutsky: и SRP, и тыды и тыпы 286 | [09/07/14 22:34:51] Alexey Migutsky: И большая проблема - как это объяснить? :) 287 | Я могу этому обучить лично на примере, но не могу это нормально доходчиво объяснить 288 | [09/07/14 22:35:19] Alexey Migutsky: практика показывает, что для такого подхода нужно пол года старательно менять паттерн мышления 289 | [09/07/14 22:35:37] Alexey Migutsky: и есть одна большая проблема - контроль КОЛИЧЕСТВА компонент 290 | [09/07/14 22:36:03] Alexey Migutsky: Есть бритва Оккама и всякие советы, предостерегающие о "плождении сущностей", типа YAGNI 291 | [09/07/14 22:36:13] Alexey Migutsky: Так вот они с этим подходом не очень дружат 292 | [09/07/14 22:36:21] Антон Шувалов: Вот, кстати, еще неплохая статья по архитектуре http://www.richardrodger.com/monolithic-nodejs 293 | [09/07/14 22:36:58] Alexey Migutsky: плюс часто такой подход ведёт к генерализации решений - а это прямой путь к оверинженерингу 294 | [09/07/14 22:38:24] Alexey Migutsky: Но зато есть большой ощутимый плюс - с таким подходом проще контролировать рефакторинг 295 | [09/07/14 22:38:36] Alexey Migutsky: потому что рефакторинг - это "перетосовка знаний" в системе мышления 296 | [09/07/14 22:38:59] Alexey Migutsky: т.е. если вы видите, что компоненту нужно знать много, или эти знания размазаны - собираете их вместе 297 | [09/07/14 22:40:36] Alexey Migutsky: Плюс имеем три главных вопроса: 298 | 1. что? 299 | 2. где? 300 | 3. как? 301 | 302 | что? - что делает конкретный кусок знаний 303 | где? - где это знание находится 304 | как? - как это знание получить в данном месте 305 | 306 | Каждый вопрос - это своеобразная независимая метрика, которую нужно уменьшать 307 | [09/07/14 22:40:59] Alexey Migutsky: Т.е. ответ должен быть максимально однозначным - этот компонент делает то-то, лежит там-то и подключается так-то 308 | [09/07/14 22:41:49] Alexey Migutsky: тут вам и DI, и структура на файловой системе и запрет дублирования функционала 309 | [09/07/14 22:42:13] Антон Шувалов: Мне кажется, формат мышления, о котором ты говоришь очень естественный для программиста. 310 | [09/07/14 22:42:13] Alexey Migutsky: DI вроде как имеет самый простой ответ на вопрос "как?" - мы просто объявляем зависимость и получаем компонент 311 | [09/07/14 22:42:35] Антон Шувалов: В некоторых случаях, правда, полезно его формализовать и дополнить примерами. 312 | [09/07/14 22:42:37] Alexey Migutsky: всё, никаких лишних знаний о путе или "местонахождении в скоупе" компонента 313 | [09/07/14 22:42:59] Alexey Migutsky: > Мне кажется, формат мышления, о котором ты говоришь очень естественный для программиста. 314 | И не только для программиста :) 315 | [09/07/14 22:43:13] Alexey Migutsky: Но я реально за всё время слышал упоминание о потоке знаний всего пару раз 316 | [09/07/14 22:43:33] Alexey Migutsky: и опять же - в форме такой же вот рефлексии, как сейчас происходит у меня :) 317 | [09/07/14 22:43:40] Антон Шувалов: И, я думаю, это поможет тебе донести суть. Даже скорее конкретизировать и формализовать, потому что, как мне кажется, это и правда очеть естественно 318 | [09/07/14 22:44:02] Alexey Migutsky: т.е. типа "вот есть набор правил, которые мы с вами знаем. И вот есть такой подход. И вот тут знания текут, а тут нет" 319 | [09/07/14 22:44:27] Alexey Migutsky: Короче, пол статьи я тут уже написал :) 320 | [09/07/14 22:45:02] Антон Шувалов: > потоке 321 | я, правда, не совсем понял. Это ж системы 322 | [09/07/14 22:45:32] Антон Шувалов: Типа, система состоит из набора систем более низкого уровня, которые при объединении дают системе новые свойства 323 | [09/07/14 22:45:53] Антон Шувалов: И так можно уменьшать и уменьшать, до формальной системы 324 | [09/07/14 22:46:21] Alexey Migutsky: а вот хз 325 | [09/07/14 22:46:34] Alexey Migutsky: можно ли о системах в таком ключе размышлять 326 | [09/07/14 22:47:05] Антон Шувалов: Не то? О системах достаточно много информации, как мне кажется. Может ты по неправильным терминам ориентируешься, и по этому не можешь найти информацию о потоке, когда это система? (если я правильно тебя понял) 327 | [09/07/14 22:47:06] Alexey Migutsky: Тут, кстати, "протекание знаний" примерно равно "текучим абстракциям" 328 | [09/07/14 22:47:11] Alexey Migutsky: но как я понял - не тоже самое 329 | [09/07/14 22:47:16] Alexey Migutsky: или это просто я так понял :) 330 | [09/07/14 22:47:39] Alexey Migutsky: > из набора систем более низкого уровня 331 | вот фишка как раз в том, что на самом низком уровне у вас "неделимые факты" 332 | [09/07/14 22:47:51] Антон Шувалов: Текучие абстракции — это, как мне кажется, эскалирование ошибки в системе 333 | [09/07/14 22:48:15] Alexey Migutsky: т.е. в итоге да, для того, чтобы получить "скейляшееся решение" вам нужно сделать так, чтобы каждый компонент был "нелелимым хранилищем знаний" для клиента этого компонента 334 | [09/07/14 22:48:59] Антон Шувалов: Когда ошибка в происходит в ее подсистеме (а может и ее подсистеме), и ты не опустившись вниз, до истинной причины проблемы, и не разобравшись в устройстве той подсистемы, в которой произошла проблема, не починишь надсистему? 335 | [09/07/14 22:49:03] Alexey Migutsky: > это, как мне кажется, эскалирование ошибки в системе 336 | не сомвсем, это о смешении слоёв абстракций 337 | [09/07/14 22:49:36] Alexey Migutsky: грубо говоря, это нарушение того же LoD 338 | [09/07/14 22:49:49] Антон Шувалов: > смешении слоёв абстракций 339 | Я совершенно другой понимаю под законом текучих абстракций) 340 | [09/07/14 22:49:54] Alexey Migutsky: когда мы инкапсулировали алгоритм в классе, но на уровне библиотеки всё равно стучимся к низкоуровневым методам 341 | [09/07/14 22:50:13] Антон Шувалов: Хотя, сейчас задумался, правильно ли я вообще понимаю 342 | [09/07/14 22:50:16] Kirill Cherkashin: Как-то слишком абстрактно 343 | [09/07/14 22:50:49] Alexey Migutsky: http://en.wikipedia.org/wiki/Leaky_abstraction 344 | [09/07/14 22:50:55] Alexey Migutsky: a leaky abstraction is an implemented abstraction where details and limitations of the implementation leak through 345 | [09/07/14 22:51:20] Антон Шувалов: Черт, я даже представить боюсь, что бы было, если б такой разговор начался в пабе под пиво (rofl) 346 | [09/07/14 22:52:19] Антон Шувалов: А, все понял про текучие абстракции 347 | [09/07/14 22:52:38] Антон Шувалов: Но, тогда, проксирование параметров в компонент абстракции — текучесть? 348 | [09/07/14 22:52:49] Alexey Migutsky: Ну, сложно найти людей которые под пиво не скажут "да ну нахуй, давай без этого" :))) 349 | [09/07/14 22:53:16] Alexey Migutsky: > Как-то слишком абстрактно 350 | О том и речь, что без примеров реальных это ОООООООЧЕНЬ тяжело понять и воспринять 351 | [09/07/14 22:53:18] Alexey Migutsky: нету формализма 352 | [09/07/14 22:53:24] Антон Шувалов: Да, я тоже замечал. Поэтому и забавно) 353 | [09/07/14 22:54:34] Антон Шувалов: Ну вот смотри пример: есть плагин для гранта, который просто проксирует опции в модуль, который выполняет задачу. https://github.com/shuvalov-anton/grunt-clinch/blob/master/tasks/clinch.js#L83 354 | [09/07/14 22:54:40] Антон Шувалов: Это протекающая абстракция? 355 | [09/07/14 22:54:50] Alexey Migutsky: Собсно, вот термин, который ближе всего к понятию "знаний" 356 | http://en.wikipedia.org/wiki/Modular_programming 357 | [09/07/14 22:55:38] Alexey Migutsky: Только в таких вот определениях не понятно, что есть "single aspect of functionality" 358 | [09/07/14 22:56:02] Антон Шувалов: Но, с другой стороны, я не скрываю его api за своим, и позволяю напрямуювзаимодействовать с его конфигурацией, а значит, в случае обновления компонента, новые опции будут поддерживаться дефакто 359 | [09/07/14 22:56:25] Alexey Migutsky: но в modular programming понятие модуля больше, чем понятие "знания" 360 | [09/07/14 22:57:40] Alexey Migutsky: > Это протекающая абстракция? 361 | не совсем. Под протекающей абстракцией понимается то, что какое-то свойство системы, вроде как инкапсулированное, всё равно проявляется 362 | [09/07/14 22:58:16] Alexey Migutsky: тут нет привязки к коду 363 | [09/07/14 22:58:41] Alexey Migutsky: не знаю, как это лучше объяснить - отличное имхо объяснение в той же википедии - обход массива 364 | [09/07/14 22:59:01] Alexey Migutsky: вроде как абстракция - набор ячеек M x N 365 | [09/07/14 22:59:15] Alexey Migutsky: абстрагирует от программиста память 366 | [09/07/14 22:59:35] Alexey Migutsky: но для эффективного обхода нужно знать, что обходить по "горизонтали" быстрее, из-за устройства памяти 367 | [09/07/14 23:00:44] Alexey Migutsky: другими словами, знание о том, как устроена память попадает в определение массива 368 | [09/07/14 23:01:24] Alexey Migutsky: для того, чтобы эту утечку прикрыть, нужно бы это "знание" о порядке обхода убрать в отдельное "поведение" - в метод "iterate", к примеру 369 | [09/07/14 23:02:02] Kirill Cherkashin: Антон, я не думаю, что у тебя в плагине есть протекающая астракция, у тебя есть АПИ который имеет смысл, и юзеру не нужно знать что внутри 370 | [09/07/14 23:02:06] Kirill Cherkashin: И как это работает 371 | [09/07/14 23:03:31] Alexey Migutsky: > а значит, в случае обновления компонента, новые опции будут поддерживаться дефакто 372 | Это текучая штука, так как ты даёшь доступ к внутрянке системы, которая закрыта проксёй. 373 | 374 | Клиенту твоей прокси нужно знать, как устроен этот объект опций и за что он отвечает внутри скрытой за проксёй либы 375 | [09/07/14 23:03:38] Alexey Migutsky: если ты поменяешь либу - хана опциям 376 | [09/07/14 23:04:17] Alexey Migutsky: [7/9/14, 22:02:04] Kirill Cherkashin: и юзеру не нужно знать что внутри 377 | [7/9/14, 22:02:08] Kirill Cherkashin: И как это работает 378 | 379 | Так вот тут наоборот - если изменится проксируемая либа - юзеру хана 380 | [09/07/14 23:04:46] Alexey Migutsky: потому что ему нужно менять передаваемые опции 381 | [09/07/14 23:04:47] Alexey Migutsky: возникает вопрос - зачем ему новое знание о том, что делает прокси, если он должен знать, какой компонент ей закрыт? 382 | [09/07/14 23:05:05] Alexey Migutsky: тут имеет смысл сделать адаптер, который будет трансформировать опции 383 | [09/07/14 23:05:13] Alexey Migutsky: в простом варианте - сами в себя :) 384 | [09/07/14 23:05:33] Alexey Migutsky: но в случае изменения апи проксируемого компонента - можно просто поменять адаптер 385 | [09/07/14 23:05:55] Kirill Cherkashin: Я не очень внимательно смотрел, я так понял, что ты пишешь свой конфиг снаружи, и конфиг какой-то другой либы внтури, а плагин просто делает какой-то препроцессинг и дает либе результат 386 | [09/07/14 23:05:58] Alexey Migutsky: у пользователя остаётся тот же объект настрок, а мы передаём в новую либу новый "проадаптированный" объект 387 | [09/07/14 23:06:00] Антон Шувалов: Хорошая мысль, кстати 388 | [09/07/14 23:06:11] Alexey Migutsky: прокси знает о конфиге либы 389 | [09/07/14 23:06:17] Alexey Migutsky: клиент знает о конфиге прокси 390 | [09/07/14 23:06:37] Kirill Cherkashin: Если я неправильно понял, то прошу прощения 391 | [09/07/14 23:07:00] Alexey Migutsky: эти знания независимы - потому что ты разлелил понятия "конфиг либы" и "конфиг прокси" 392 | [09/07/14 23:07:02] Антон Шувалов: Конфиг внутри — это дефорлтные параметры 393 | [09/07/14 23:07:12] Alexey Migutsky: а до этого было понятие "конфиг либы И прокси" 394 | [09/07/14 23:07:17] Антон Шувалов: Да, все правильно, вроде 395 | [09/07/14 23:08:07] Alexey Migutsky: т.е. в один прекрасный момент времени интерфейсы объекта настроек могут совпадать - но они выполняют разные роли 396 | -------------------------------------------------------------------------------- /Источники.md: -------------------------------------------------------------------------------- 1 | ## В качестве вступления можно перевести 2 | http://c2.com/cgi/wiki?ToAyoungExtremist 3 | 4 | ## Список принципов 5 | http://en.wikipedia.org/wiki/Category:Programming_principles 6 | ### SOLID 7 | * [Обзор принципов и их неверного толкования](http://yow.eventer.com/yow-2013-1080/the-solid-design-principles-deconstructed-by-kevlin-henney-1386) 8 | * http://freshbrewedcode.com/derekgreer/2011/12/08/solid-javascript-single-responsibility-principle/ 9 | * http://stackoverflow.com/questions/4711851/writing-javascript-according-to-solid 10 | http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod 11 | 12 | #### Single responsibility principle / Принцип единственной обязанности 13 | #### Open/closed principle / Принцип открытости/закрытости 14 | #### Liskov substitution principle / Принцип подстановки Барбары Лисков 15 | #### Interface segregation principle / Принцип разделения интерфейса 16 | #### Dependency inversion principle / Принцип инверсии зависимостей 17 | #### Law of Demeter / Закон Деметры 18 | * [Ссылка на черновик статьи](principles/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD%20%D0%94%D0%B5%D0%BC%D0%B5%D1%82%D1%80%D1%8B%20\(law%20of%20demeter\).md) 19 | * [An Empirical Validation of the Benefits of Adhering to the Law of Demeter.](http://www.ccs.neu.edu/home/lieber/LoD/LoD-2011-Zurich.pdf) 20 | 21 | ## Дополнительные подходы 22 | ### Offensive Programming (fail fast) 23 | ### The Tell, Don't Ask 24 | ### DRY 25 | ### YAGNI 26 | ### KISS 27 | ### Hollywood Principle 28 | ### Composition vs Inheritance 29 | ### OOD 30 | * http://programmers.stackexchange.com/questions/132425/how-did-you-get-good-practices-for-your-oop-designs 31 | * http://javarevisited.blogspot.com/2012/03/10-object-oriented-design-principles.html 32 | * http://www.slideshare.net/TelerikAcademy/highquality-classes-and-class-hierarchies-best-practices-in-the-objectoriented-design 33 | 34 | ### Component Driven Development 35 | 36 | * [Amazon: Component Software: Beyond Object-Oriented Programming](http://www.amazon.com/dp/0201178885/) 37 | * http://en.wikipedia.org/wiki/Component-based_software_engineering 38 | * http://gameprogrammingpatterns.com/component.html 39 | 40 | 41 | TDA design principle urges you to tell objects what to do. What you don't want to do is ask an object about its internal state, make some decisions about that state, then tell that object what to do. 42 | 43 | 44 | ## Смежная теория 45 | ### Software Design Formalism / Формализм дизайна ПО 46 | * [Formulations and Formalisms in Software Architecture?](http://repository.cmu.edu/cgi/viewcontent.cgi?article=1716&context=compsci) 47 | * [Formalism and Intuition in Software Development](http://www.fmeurope.org/wp-content/uploads/2013/03/mjackson.pdf) 48 | * [A Framework for Evaluating Software Design Pattern Specification Languages](http://www.academia.edu/3725444/A_Framework_for_Evaluating_Software_Design_Pattern_Specification_Languages) 49 | * [The Criticality of Modeling Formalisms in Software Design Method Comparison](http://laser.cs.umass.edu/techreports/96-49.pdf) 50 | * [Bringing Formalism and Unification to Human-Computer Interaction Design Patterns](http://dbonline.igroupnet.com/ACM.FT/1830000/1824754/p20-kruschitz.pdf) 51 | 52 | ### Подходы к дизайну систем 53 | * [Introduction to Software Engineering](http://en.wikibooks.org/wiki/Introduction_to_Software_Engineering) 54 | * [Architecture of Open Source Apps](http://www.aosabook.org/en/index.html) 55 | 56 | ### Паттерны 57 | * [Essential Design Patterns](http://addyosmani.com/resources/essentialjsdesignpatterns/book/) 58 | * [Patterns for Large Scale Javascript Apps](http://addyosmani.com/largescalejavascript/) 59 | * **[ABSTRACTION CLASSES IN SOFTWARE DESIGN 60 | ](http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf)** 61 | -------------------------------------------------------------------------------- /Принципы/Говори, а не спрашивай (Tell Dont ask).md: -------------------------------------------------------------------------------- 1 | 2 | 3 | http://robots.thoughtbot.com/tell-dont-ask 4 | http://habrahabr.ru/post/192706/ 5 | http://martinfowler.com/bliki/TellDontAsk.html 6 | http://www.rsdn.ru/forum/design/4470262.all 7 | http://phpclub.ru/talk/threads/tell-dont-ask.66259/page-2 8 | http://pragprog.com/articles/tell-dont-ask 9 | http://c2.com/cgi/wiki?DontConfuseYourDog 10 | -------------------------------------------------------------------------------- /Принципы/Закон Деметры (law of demeter).md: -------------------------------------------------------------------------------- 1 | # Law of demeter 2 | a specific case of loose coupling. 3 | ## Примерная схема 4 | ### Краткое описание и как понять что закон нарушен 5 | 6 | Что это, зачем нужно и как помогает 7 | 8 | Слишком большое количество точек (может нет, а может да) 9 | 10 | `a.b().c().d()` так же плохо как и `b = a.b(); c = b.c(); c.d()` 11 | 12 | Закон деметры был сформулирован не для JavaScript и слепо применять его нельзя Однако польза от него может быть 13 | 14 | Мы постараемся разобраться объективно, где в JS стоит, а где не стоит применять закон деметры. 15 | 16 | 17 | ### История 18 | 19 | Был придуман в 1987 году во время разработки проекта деметра. 20 | 21 | Изначально был сформулирован для 4х языков: Smalltalk, CLOS, C++ и Eiffel 22 | 23 | Альтернативным названием предложенным в статье было скромное "Правило хорошего стиля" (now known in-house as the Law of Demeter or the Law of Good Style) 24 | 25 | Проект по ходу сдох(пруф? ), а закон остался http://www.ccs.neu.edu/home/lieber/what-is-demeter.html 26 | 27 | Проект был назван в честь богини деметры, потому что в чуваков которые разрабатывали его был набор железа Зевс, с которым система должна была работать. Деметра - сестра зевса 28 | 29 | 30 | #### Пара абстрактных примеров, чтобы было понятно о чем речь 31 | 32 | Тут пример с заказами в последнем посте http://c2.com/cgi/wiki?LawOfDemeterMakesUnitTestsEasier 33 | 34 | Пример, где отдаешь кошелек вместо того, чтобы отдать деньги [1] 35 | 36 | Пример где не говоришь собакиной ноге что делать 37 | 38 | Для неймспейса наверное не должно применяться. Например если есть сложный json, то client.info.address.line2 по идее ничего не нарушает 39 | 40 | http://en.wikipedia.org/wiki/Multilayered_architecture 41 | ## Зачем нам это нужно и к чему это может привести 42 | ### Плюсы 43 | 44 | * Видны и понятны все зависимости функции и класса 45 | * проще тестировать, потом что не надо создавать вложенные моки 46 | * Меньше всего менять (объснить) 47 | * Посволяет избавиться от ошибок, когда внешний класс не в курсе, что внутренний класс был изменен 48 | * Возможно меньше печатать 49 | http://alvinalexander.com/java/java-law-of-demeter-java-examples 50 | 51 | ### Минусы 52 | 53 | * Больше функций в интерфейсе 54 | * Нарушает Narrow interfaces 55 | * Найти может быть довольно просто, но вот починить - не всегда, иногда пытаясь починить можно сделать еще хуже 56 | todo: The LawOfDemeter minimizes logical coupling, but maximizes what could be called "physical coupling" -- the number of instantiated objects that need to be traversed for any particular operation. There are specific reasons why this might be bad. If performance is an issue, you might not want to incur the costs of implicitly navigating through a bunch of objects every time you call a top-level method. (This can be counteracted by caching intermediate objects, though that might be cumbersome in practice.) Similar issues can occur when you're using multithreading or distributed systems, where physical indirection can cause problems. 57 | * Something about deep null checking 58 | ## Примеры 59 | Дальше мы пройдемся по примерам и для каждого посмотрим, даст ли применение ЗД обещанные выше плюсы, и удастсяли избежать минусов 60 | 61 | #### Чистый JavaScript 62 | Как это работает в JS 63 | Если в других языках можно как-то отрефакторит, то в JS не очень 64 | 65 | #### Чейнинг в underscore | jquery 66 | Нарушает ли принцип деметры? 67 | utils.measurments.size( something ) 68 | 69 | #### Разрешение зависимостей и инжектор в ангулар 70 | Нарушает ли принцип деметры? 71 | 72 | 73 | ### Тестирование 74 | 75 | * Что нужно знать о ПД при тестировании 76 | * Не нужно создавать моки вложенный в моки и не нужно знать как фигня работает внутри. 77 | 78 | 79 | ### Заключение 80 | Везде нужен баланс 81 | Как сказал мартин фоулер, "I've always felt I'd be more comfortable with the Law of Demeter if it were called the Suggestion of Demeter." 82 | 83 | 84 | ------- 85 | # Example with Order.Client.name 86 | Возможное решение: 87 | order.clientName 88 | Минусы: нужно делегировать каждое свойство 89 | Плюсы : Если какой-то свойство перенесется, шаблоны менять не нужно 90 | # Example with a paper boy and a wallet 91 | ## Original 92 | ```Javacript 93 | function Wallet( money ){ 94 | this.money = money; 95 | } 96 | 97 | Wallet.prototype.getMoney = function( amount ){ 98 | // get the money 99 | } 100 | 101 | function Customer( wallet, name ){ 102 | this.wallet = wallet 103 | this.name = name; 104 | } 105 | Customer.prototype.getWallet = function(){ 106 | return this.wallet; 107 | } 108 | 109 | function PaperBoy(){ 110 | 111 | } 112 | 113 | PaperBoy.prototype.acceptPayment = function( customer ){ 114 | var wallet = customer.getWallet(); 115 | if( wallet.hasMoney( amount ) ){ 116 | wallet.getMoney( amount ); 117 | } 118 | // LOD broken 119 | } 120 | ``` 121 | Что здесь не так, и почему это нужно исправлять? 122 | 1. Если нужно будет добавить кредитную карточку, то будет геморрой 123 | 2. Если появится кто-то еще, кто хочет получить деньги с клиента, придется дублировать код с проверками 124 | 3. Клиент позволяет любому классу управлять свои коешльком, что не всегда желательно 125 | 4. TODO 126 | ## Solution 1 127 | 128 | ```Javacript 129 | Customer.prototype.getMoney = function( amount ){ 130 | return this.wallet.getMoney( amount ) 131 | } 132 | ``` 133 | Плюсы: 134 | * PaperBoy is decoupled from the wallet class 135 | * PaperBoy con not do bad things with the wallet 136 | Минусы: 137 | * Если делать так часто, слишком много методов будет у кастомера. 138 | 139 | ## Solution 2 140 | 141 | ```Javacript 142 | PaperBoy.prototype.acceptPayment = function( wallet ){ 143 | wallet.getMoney(); 144 | } 145 | ``` 146 | Плюсы: 147 | * PaperBoy ничего не знает про кастомера 148 | // TODO подрбнее и больше примеров 149 | ## Solution 3 150 | 151 | ```Javacript 152 | var paymentService = { 153 | processPayment: function( fromWallet, toWallet, amount){ 154 | // do the payment 155 | } 156 | } 157 | 158 | PaperBoy.prototype.acceptPayment = function( customer ){ 159 | paymentService.processService( customer.wallet ); 160 | } 161 | ``` 162 | Плюсы: 163 | 164 | // TODO подрбнее и больше примеров 165 | 166 | # Ссылки и прочие материалы для подготовки статьи 167 | 168 | 169 | ## Вопросы и вещи которые пока непонятны 170 | * Как это работает с функциональным программированием? 171 | * А как с фабриками? SomeFactory.createSomething().doSomething() 172 | * Как это связано с TellDontAsk ? 173 | * Как это все соотносится с замыканиями? 174 | * Как это все соотносится с промисами? Есть вопрос на СО, но там никто не понимает, что происходит http://stackoverflow.com/questions/20275957/does-deferred-promise-promote-breaking-the-law-of-demeter 175 | * jQuery 176 | * chaining in underscore? 177 | * Функции которые приходят в качестве аргументов? 178 | * Библиотеки. Вся эта фигня, чтобы если интерфейс объекта поменяется, не было боли. Библиотеки меняются редко, поэтому там можно простить нестинг и чейнинг? 179 | * Moжно ли отследить нарушения принципа с помощью статического анализа? 180 | * Определен ли закон на уровне функии или на уровне класса? 181 | * Массивы объектов - исключение из правила 182 | * How is this at all related to bridge and shield patterns? 183 | * Domain specific objects only? 184 | * Coffee script has a ? operator, talk about it and LoD # http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx/ 185 | * Нельзя починить нарушение закона какими-то внутренними изменениями 186 | * CSS Selectors? 187 | * Dependency injection? 188 | http://stackoverflow.com/questions/160032/does-dependency-injection-break-the-law-of-demeter 189 | http://stackoverflow.com/questions/791940/law-of-demeter-on-factory-pattern-and-dependency-injection 190 | http://blog.glassdiary.com/post/60056612233/law-of-demeter-in-software-design 191 | http://googletesting.blogspot.com/2008/10/dependency-injection-myth-reference.html 192 | 193 | The final thing I was going to say is that I like your observation about types being a big deal. I know that, recently, when I am programming in a functional language, I'm constantly looking at the types and trying to find a kernel of uses of a type that make it easy to chain functions. For example, if I have 3 functions which each take a different type and return the same type A, then I can use them as input to a chain. If I have functions which take an A to A, those can be part of the chain. If I have a function which takes an A to a B and a function which takes a B to an A, I can chain those easily also. It's sort of like `type attractors.' I'd argue that when we make DSLs, they are good to the degree that we have those. 194 | 195 | ## Цитаты 196 | , it's a guidline to help reduce coupling in code 197 | 198 | Taken from http://www.ccs.neu.edu/home/lieber/LoD.html: 2003 was the 15 Year Anniversary of the Law of Demeter: The Law of Demeter is a simple style rule for designing ObjectOriented systems. "Only talk to your immediate friends" is the motto. The style rule was first proposed at Northeastern University in the fall of 1987 and popularized in books by Booch, Budd, Coleman, Larman, Page-Jones, Rumbaugh and others. A 2000 book that describes it well is The Pragmatic Programmer by AndrewHunt and DavidThomas. The name "Law of Demeter" was chosen because the style rule was discovered while working on the The Demeter Project which ever since was strongly influenced by the Law of Demeter. The Demeter Project develops tools that make it easier to follow the Law of Demeter. (Demeter = Greek Goddess of Agriculture; grow software in small steps) For example, "only talk to your immediate friends that share the same concerns" leads to tools for Aspect-Oriented Software Development. 199 | 200 | Demeter has raised (ага)what we would know here as a CodeSmell to the level of a law. 201 | 202 | Demeter tries to establish a relation about objects created and used within a method or function, 203 | 204 | Something about telling the milk to uncow itself...? 205 | 206 | 207 | The Demeter system considers Repetition objects as special classes of objects for which the oft-quoted normal Demeter "law" does not apply in the same manner. In fact, the Demeter method/system contains several laws/forms of Demeter, each of which applies to its appropriate context (which is still admittedly broad and abstract) and is not completely universal in applicability. People just tend to hear only about the form that is most commonly cited and not always with the appropriate context. Even so, for regular OOD/OOP, it's still more of a guideline (a very strong recommendation) rather than a hard and fast, inviolable rule. 208 | 209 | 210 | The Demeter literature talks about the introduction of lots of additional small methods, which started getting unwieldy to add manually, and is part of why the Demeter tools exists, so they can be autogenerated as needed. 211 | This gets into issues of propagation of results of partial computations, which is a whole other area of Demeter called "propagation patterns" (not be confused with "design patterns"). Beyond the straightforward stuff, trying to go "full" Demeter without the niceties of the "full" Demeter system has lots of not niceties" associated with it because without Demeter's tool-support you can't so easily propagate what is needed where in an orthogonal fashion. -- [[Anonymous Donor]] 212 | 213 | had the opportunity to briefly chat with Michael Feathers about LoD and he pointed out the example of Excel’s object model for tables and cells. If LoD is about encapsulation (aka information hiding) then why would you hide the structure of an object where the structure is exactly what people are interested in and unlikely to change? 214 | 215 | Software design principles can be interesting to study in the abstract, but there is no substitute for trying them out in concrete applications. If you can find a project that is a natural fit for the technique you are trying to investigate, even the most simple toy application will teach you more than pure thought experiments ever could. 216 | 217 | I think applying the Law of Demeter to individual classes is taking it a bit too far. I think a better application is to apply it to layers in your code. For example, your business logic layer shouldn't need to access anything about the HTTP context, and your data access layer shouldn't need to access anything in the presentation layer. 218 | 219 | The style rule was first proposed at Northeastern University in the fall of 1987 by Ian Holland and popularized in books by Booch, Budd, Coleman, Larman, Page-Jones, Rumbaugh and others. A 220 | 221 | No more russian dolls 222 | 223 | Unfortunately, when you simplify Demeter from "don't rely on behavior on internals of other objects" to "don't use more than one dot", you lose this critical thinking on context. (Applies to anything) 224 | 225 | This is true. I don't suppose you are, because if Kevin Bacon acted in a film with Kevin Bacon, and you acted with that copy of Kevin Bacon, you still have a Bacon number of 1.# On chaining 226 | 227 | It’s important to understand that the Law of Demeter is a heuristic, not an end in and of itself. It is not a law in the sense that you “must” write your code in a certain way. Rather, it is a law in the sense that it has been consistently observed that if code complies with the Law of Demeter, it almost certainly has a number of the qualities—encapsulation, loose coupling, etc.—desirable in an OO system. 228 | 229 | I just notice that often when Demeter is violated it takes some re-conceptualization of the problem and a completely different factoring of classes to make things much nicer. 230 | 231 | По ходу закон деметры сложно понять, потому что он показывает косяки архитетуры в целом и нарушение сложно починить в рамках одного или двух классов 232 | 233 | As a law it's more like 'floss your teeth every day' than like gravity. You might prefer not to confess to your dentist but occasional violations will not collapse the universe. 234 | ## Мысли 235 | ### Статический анализ 236 | В языке со статической типизацией можно выяснить, какие классы знают о других классах 237 | Можно выяснить, какие классы напрямую зависят от других классов 238 | Если из первого вычесть второе, то будет понятно 239 | У руби есть какой-то инструмент для находжения нарушений ЗД, надо посмореть внимательнее 240 | http://www.ccs.neu.edu/research/demeter/DemeterF/ 241 | 242 | 243 | ### Вариации 244 | #### LoDC 245 | in 2003/2004 the Law of Demeter was revisited for Karl Lieberherr's ICSE 2004 keynote paper and presentation. The Law of Demeter was refined from "Only talk to your friends" to "Only talk to your friends who share your concerns" and this refined form is called the Law of Demeter for Concerns (LoDC). The LoDC is best followed by using Aspect-Oriented Software Development (AOSD) techniques such as AspectJ or DJ. On the other hand, the LoDC leads to better AOSD. Properly following the LoDC has two key benefits: It leads to better information hiding (using the technique of structure-shyness or the more general technique of concern-shyness) and to less information overload for the software developer. 246 | 247 | #### No returns 248 | https://practicingruby.com/articles/temporal-coupling-and-the-law-of-demeter # A very hardcore version of demeter law applied to some async thing in ruby. worth revisiting 249 | 250 | ## Links 251 | ### General links 252 | Wiki http://en.wikipedia.org/wiki/Law_of_Demeter 253 | 254 | 255 | http://c2.com/cgi/wiki?LawOfDemeter 256 | http://c2.com/cgi/wiki?LawOfDemeterIsInvalid 257 | http://c2.com/cgi/wiki?LawOfDemeterRevisited 258 | http://c2.com/cgi/wiki?IsLawOfDemeterOverspecifiedOnCeeTwo 259 | 260 | Хорошая статья, все отлично расписано, возможно - первоисточник примера с кошельком 261 | http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf 262 | http://c2.com/cgi/wiki?LawOfDemeterMakesUnitTestsEasier 263 | http://c2.com/cgi/wiki?LawOfDemeterIsHardToUnderstand 264 | http://c2.com/cgi/wiki?LawOfDemeterIsTooRestrictive // see "How to apply the LawOfDemeter successfully" 265 | http://c2.com/cgi/wiki?LawOfDemeterAndCoupling 266 | http://c2.com/cgi/wiki?CanLawOfDemeterBeRefactoredAutomatically // bullshit 267 | http://c2.com/cgi/wiki?TellDontAsk 268 | 269 | 270 | 271 | Really nice collection of links 272 | http://www.ccs.neu.edu/home/lieber/LoD.html // TODO: Read more carefully, good material in the presentation 273 | 274 | How does the Law of Demeter apply to object-oriented systems regarding coupling and cohesion? [closed] 275 | http://programmers.stackexchange.com/questions/181699/how-does-the-law-of-demeter-apply-to-object-oriented-systems-regarding-coupling 276 | 277 | http://programmers.stackexchange.com/questions/214721/rails-law-of-demeter-confusion 278 | http://stackoverflow.com/questions/6918666/law-of-demeter-and-oop-confusion # Good point, answers are not helpful 279 | 280 | A lot of arguing, worth revisiting 281 | http://don.fed.wiki.org/view/law-of-demeter/sfw.c2.com/law-of-demeter-revisited 282 | 283 | Several takes on explaining why chaining does not violate the law of Demeter 284 | http://stackoverflow.com/questions/67561/do-fluent-interfaces-violate-the-law-of-demeter 285 | 286 | Law of demeter applied to TCL programming language 287 | http://wiki.tcl.tk/8505 288 | 289 | http://codemate.wordpress.com/2008/08/09/looking-at-the-law-of-demeter/ 290 | 291 | http://web.archive.org/web/20110717132001/http://garmhold.blogspot.com/2010/02/no-more-russian-dolls-applying-law-of.html 292 | 293 | 294 | http://web.archive.org/web/20100617233935/http://www.driis.dk/en/2010/01.aspx 295 | 296 | 297 | 298 | ### JavaScript links 299 | 300 | Promises and law of demeter: 301 | http://stackoverflow.com/questions/20275957/does-deferred-promise-promote-breaking-the-law-of-demeter 302 | 303 | 304 | Really weird article on LoD, selectors nesting and backbone views 305 | http://zen-hacking.com/backbone-views-and-the-law-of-demeter/ 306 | 307 | Mostly flood about TDD 308 | https://plus.google.com/+TadDonaghe/posts/jRvNenACand 309 | 310 | Angular docs: Passing the injector breaks the Law of Demeter. # That's all about LoD on that page 311 | https://docs.angularjs.org/guide/di 312 | 313 | Part of a Book: Dependency Injection with AngularJS (Holy shit, did not know this kind of book even exists) 314 | http://books.google.com/books?id=9dtdAgAAQBAJ&pg=PT61&lpg=PT61&dq=law+of+demeter+angular&source=bl&ots=AjDR10eAtM&sig=Lo3UjKIxgLtujsEl8L2doLChJwU&hl=en&sa=X&ei=FN-9U4KZE4yryASt8oLgCw&ved=0CC4Q6AEwAg#v=onepage&q=law%20of%20demeter%20angular&f=false 315 | 316 | Transfer injector broke The law of Demeter(Law of Demeter, Least knowledge principle) 317 | http://www.programering.com/a/MTO1EzMwATg.html # Those people really screwed up trying to translate from english to english 318 | 319 | 320 | ### Other languages 321 | 322 | original article about law of demeter 323 | http://www.ccs.neu.edu/research/demeter/papers/law-of-demeter/oopsla88-law-of-demeter.pdf 324 | 325 | Weird stuff 326 | http://www.daedtech.com/visualization-mnemonics-for-software-principles # Some ridiculous example on handling pants instead of wallet 327 | 328 | 329 | 330 | 331 | ## Ruby examples + some discussion 332 | 333 | Deep, Good examples, worth revisiting #revisit 334 | http://devblog.avdi.org/2011/07/05/demeter-its-not-just-a-good-idea-its-the-law/ 335 | 336 | Some ruby refactoring from really ugly code to just ugly code 337 | http://guillecarlos.com/refactoring-law-of-demeter.html 338 | 339 | Link from the previous post, nothing on demeter, mostly about Active Record and data structures 340 | https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects 341 | 342 | Simple example of refactoring from @invoice.user.name to @invoice.user_name using Ruby delegation 343 | http://rails-bestpractices.com/posts/15-the-law-of-demeter 344 | 345 | Nice overview, I like the Consequences of Violations section #revisit 346 | http://www.informit.com/articles/article.aspx?p=1834700&seqNum=6 347 | 348 | 349 | 350 | This looks like an attempt to transform all dots into underscores. May probably be helpful for the future refactorings, similar to having getters and setters everywhere. 351 | https://github.com/emerleite/demeter 352 | 353 | 354 | One of the most quoted, good example on not just having properties out, but having the logic out, makes more sense, many comments #revisit 355 | http://www.dan-manges.com/blog/37 356 | 357 | 358 | Discussion regarding the previous link, interesting point of view in the first comment #revisit 359 | http://programmers.stackexchange.com/questions/214721/rails-law-of-demeter-confusion 360 | 361 | Paperboy example in Ruby 362 | http://nithinbekal.com/posts/demeter/ 363 | 364 | ---- Finished here 365 | 366 | Some erlang stuff 367 | http://erlang.org/pipermail/erlang-questions/2013-January/071991.html 368 | 369 | 370 | Some PHP examples 371 | http://www.sitepoint.com/introduction-to-the-law-of-demeter/ 372 | http://www.theodo.fr/blog/2013/02/dont-overuse-dependency-injection/ 373 | http://codeutopia.net/blog/2011/08/02/doctrine-2-and-the-law-of-demeter/ 374 | 375 | Python 376 | https://mail.python.org/pipermail/python-list/2002-December/152685.html 377 | 378 | Money And Wallet methaphor 379 | http://juristr.com/blog/2009/09/law-of-demeter-nice-metaphor/ 380 | 381 | Some .NET stuff 382 | http://lostechies.com/derekgreer/2008/06/10/distilling-law-of-demeter/ 383 | http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx/ 384 | http://taswar.zeytinsoft.com/2009/04/03/law-of-demeter-principle-of-least-knowledge/ 385 | http://fusion.dominicwatson.co.uk/2012/07/the-law-of-demeter.html 386 | http://www.prowareness.com/blog/hidedelagate/ 387 | Derick Bailey on LoD in C#, see comments 388 | http://lostechies.com/derickbailey/2010/03/25/law-of-demeter-extension-methods-don-t-count/ 389 | 390 | Law of Demeter is easy to spot when you need extra mocks 391 | http://richarddingwall.name/2009/08/26/law-of-demeter-is-easy-to-spot-when-you-need-extra-mocks/ 392 | 393 | Refactoring to Law of Demeter 394 | http://pilchardfriendly.wordpress.com/2009/04/06/refactoring-to-law-of-demeter/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+PlanetTw+%28Planet+TW%29 395 | 396 | OO: Reducing the cost of…lots of stuff! 397 | http://www.markhneedham.com/blog/2009/03/12/oo-reducing-the-cost-oflots-of-stuff/ 398 | 399 | >> done.for.the.day.about.to.go.to.the.hotel.where.i.specificatlly.wont.think.about.the.law.of.demeter() 400 | 401 | Some java stuff 402 | "I've always felt I'd be more comfortable with the Law of Demeter if it were called the Suggestion of Demeter." Martin Fowler 403 | http://martinfowler.com/articles/mocksArentStubs.html 404 | http://misko.hevery.com/2008/07/18/breaking-the-law-of-demeter-is-like-looking-for-a-needle-in-the-haystack/ 405 | http://java.dzone.com/articles/law-demeter 406 | http://vitalflux.com/law-demeter-violations-fix/ 407 | http://www.ericfeminella.com/blog/2008/02/02/principle-of-least-knowledge/ 408 | http://www.blackwasp.co.uk/LawOfDemeter.aspx 409 | http://eyalgo.com/2014/02/17/law-of-demeter-4/ 410 | http://theshyam.com/tag/law-of-demeter/ 411 | http://www.javacodegeeks.com/2012/06/demeter-law.html 412 | http://www.javacodegeeks.com/2014/02/law-of-demeter.html?utm_content=buffer4711e 413 | 414 | ### Not just demeter 415 | http://www.bennadel.com/blog/2375-object-calisthenics-in-javascript-my-first-attempt.htm 416 | 417 | http://habrahabr.ru/post/206802/ 418 | ### Russian 419 | 420 | Nice discussion 421 | http://toster.ru/q/44822 422 | 423 | Несвязность_и_закон_Деметра 424 | http://ru.wikibooks.org/wiki/%D0%9D%D0%B5%D1%81%D0%B2%D1%8F%D0%B7%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B8_%D0%B7%D0%B0%D0%BA%D0%BE%D0%BD_%D0%94%D0%B5%D0%BC%D0%B5%D1%82%D1%80%D0%B0 425 | 426 | http://plakhov.livejournal.com/54739.html 427 | 428 | Ruby looks like a translation 429 | http://vessi.github.io/blog/2012/07/18/zakon-diemietry-ili-poakkuratnieie-s-tochkami/ 430 | 431 | http://life-prog.ru/view_zam2.php?id=174&cat=5&page=8 432 | 433 | http://c2.com/cgi/wiki?InformationHiding 434 | http://vessi.github.com/blog/2012/07/18/zakon-diemietry-ili-poakkuratnieie-s-tochkami/ 435 | http://msdn.microsoft.com/ru-ru/magazine/cc947917.aspx 436 | 437 | ## Books 438 | pragmatic programmer 439 | Clean code 440 | 441 | ## testing 442 | http://googletesting.blogspot.com/2008/07/breaking-law-of-demeter-is-like-looking.html 443 | http://programmers.stackexchange.com/questions/232442/unit-testing-factories-and-the-law-of-demeter 444 | http://jayflowers.com/WordPress/?p=78 445 | http://codevanced.net/post/The-Law-of-Demeter-The-crux-of.aspx 446 | http://www.scottmcmaster365.com/2011/04/law-of-demeter-makes-you-create-mock.html 447 | 448 | http://stackoverflow.com/questions/19549535/intellij-ideas-law-of-demeter-inspection-false-positive-or-not 449 | https://code.google.com/p/testability-explorer/wiki/LawOfDemeterCostExplanation 450 | http://blog.bbv.ch/2011/03/28/law-of-demeter-and-testability/ 451 | http://blog.igorstoyanov.com/2005/10/stubs-or-mocks-state-or-behavior_30.html 452 | https://groups.yahoo.com/neo/groups/extremeprogramming/conversations/topics/122627 453 | 454 | Google's Testing on the Toilet, whatever it means 455 | http://www.ccs.neu.edu/home/lieber/LoD/law_of_demeter_healthy_code-external.pdf 456 | 457 | ## LoD for namespaces and data objects 458 | http://stackoverflow.com/questions/12284057/law-of-demeter-data-objects 459 | http://codereview.stackexchange.com/questions/131/law-of-demeter-and-data-models 460 | 461 | ## Articles 462 | An Empirical Validation of the Benefits of 463 | Adhering to the Law of Demeter 464 | http://www.ccs.neu.edu/home/lieber/LoD/LoD-2011-Zurich.pdf 465 | 466 | In 2003/2004 the Law of Demeter was revisited for Karl Lieberherr's ICSE 2004 keynote paper and presentation. The Law of Demeter was refined from "Only talk to your friends" to "Only talk to your friends who share your concerns" and this refined form is called the Law of Demeter for Concerns (LoDC). 467 | http://www.ccs.neu.edu/research/demeter/biblio/icse-2004-keynote.html 468 | http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf 469 | 470 | http://www.ccs.neu.edu/research/demeter/biblio/LoD.html 471 | 472 | http://www.ccs.neu.edu/research/demeter/biblio/LoD-formulations.html 473 | 474 | And tons of articles here: http://www.ccs.neu.edu/research/demeter/biblio/ 475 | 476 | Brad Appleton Explains Law of Demeter and Adaptive Programming 477 | http://www.bradapp.com/docs/demeter-intro.html 478 | ## Talks 479 | Misko Hever - The Clean Code Talks - Don't Look For Things! 480 | https://www.youtube.com/watch?v=RlfLCWKxHJ0 481 | 482 | Misko Hever - Design Tech Talk Series Presents: OO Design for Testability 483 | https://www.youtube.com/watch?v=acjvKJiOvXw 484 | 485 | The talk by Ben Orenstein at RailsConf 2013 provides a very good visualization of the Law of Demeter. 486 | Ben Orenstein - Rails Conf 2013 How to Talk to Developers 487 | https://www.youtube.com/watch?v=l9JXH7JPjR4 488 | 489 | Really nice presenation, great research, Java examples, have to read 490 | http://www.slideshare.net/vladimirtsukur/law-of-demeter-objective-sense-of-style 491 | 492 | Coupling_Cohesion_and_the_Law_of_Demeter 493 | http://www.powershow.com/view1/5e4cb-ZDc1Z/Coupling_Cohesion_and_the_Law_of_Demeter_powerpoint_ppt_presentation 494 | 495 | Derek Ling, some JS examples 496 | http://prezi.com/lid1d64oqznb/law-of-demeter-presentation/ 497 | 498 | http://slides.nithinbekal.com/demeter/ 499 | # Coupling and cohesion 500 | http://msdn.microsoft.com/en-us/magazine/cc947917.aspx 501 | http://stackoverflow.com/questions/163071/coupling-cohesion-and-the-law-of-demeter 502 | 503 | # TO SORT 504 | http://theknowledge.me.uk/mywiki/concepts/law-of-demeter.html 505 | http://blog.shutupandcode.net/?p=718 506 | 507 | Static versus dynamic analysis applied to LoD 508 | http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/static-dynamic.html 509 | 510 | http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/Smyth/ 511 | 512 | Law of Demeter confirmed by experiment at University of Maryland 513 | http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/LawOfDemeter-confirmed-by-experiments.txt 514 | 515 | Limitations of Data Encapsulation 516 | http://www.ccs.neu.edu/research/demeter/related-work/paul-bergstein/lawOfDemeter 517 | 518 | 519 | Discussions of Law of Demeter and Adaptive Programming 520 | http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/ 521 | 522 | Discussions of Law of Demeter for Socrates and AspectJ 523 | http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/socrates 524 | 525 | Law of Demeter confirmed by experiment 526 | http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/socrates 527 | 528 | Publications by Demeter Group, including LoD papers from the late 80's 529 | http://www.ccs.neu.edu/research/demeter/papers/publications.html 530 | 531 | Potential violation of Law of Demeter 532 | http://coding.tocea.com/tools/pmd/lawofdemeter/ 533 | 534 | Dependency Injection and Reference Passing 535 | http://blog.pdark.de/tag/law-of-demeter/ 536 | 537 | 538 | http://tech.jonathangardner.net/wiki/Law_of_Demeter 539 | 540 | http://tech.socialchorus.com/2013/01/01/refactoring-and-the-null-object-pattern.html 541 | 542 | http://blogs.lessthandot.com/index.php/architect/designingsoftware/the-law-of-demeter/ 543 | 544 | http://t-a-w.blogspot.com/2008/07/new-law-of-demeter.html 545 | 546 | http://code.scottshipp.com/2013/03/29/a-practical-example-of-the-benefits-of-the-law-of-demeter/ 547 | 548 | http://www.captaindebug.com/2011/03/law-of-demeter.html 549 | 550 | http://www.codersgrid.com/2013/07/17/soma-js-framework/ 551 | 552 | http://pivotallabs.com/the-law-of-demeter-is-a-piffle/ 553 | 554 | http://compositecode.com/2007/06/21/law-of-demeter-tip-o-the-day/ 555 | 556 | http://www.markhneedham.com/blog/2009/08/17/law-of-demeter-some-thoughts/ 557 | 558 | http://ablogaboutcode.com/2012/02/27/understanding-the-law-of-demeter/ 559 | 560 | http://stackoverflow.com/questions/468615/how-to-solve-the-violations-of-the-law-of-demeter 561 | 562 | http://stackoverflow.com/questions/484469/when-is-it-ok-to-break-the-law-of-demeter 563 | 564 | http://board.phpbuilder.com/showthread.php?10390605-Method-Chaining-Poor-OOP-practice 565 | -------------------------------------------------------------------------------- /Принципы/Закон дырявых Абстракций (The Law of Leaky Abstractions).md: -------------------------------------------------------------------------------- 1 | http://www.joelonsoftware.com/articles/LeakyAbstractions.html 2 | -------------------------------------------------------------------------------- /Принципы/Принцип Разделения Интерфейса (Interface segregation principle).md: -------------------------------------------------------------------------------- 1 | http://en.wikipedia.org/wiki/Interface_segregation_principle 2 | -------------------------------------------------------------------------------- /Принципы/Сокрытие (Information hiding).md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JSDesignPrinciples/ruJSDesignPrinciples/2f548eec68caf84482e8dbb3d9d899ab054215fc/Принципы/Сокрытие (Information hiding).md --------------------------------------------------------------------------------