Di me’tr. Подчеркнутый вокал - ми, как и ми на «равном».

Ровно в 11 часов, тот же напиток и еще неделя. Продолжая на прошлой неделе серию о постоянно произносимых словах в разработке программного обеспечения, сегодня мы поговорим об истории, лежащей в основе Закона Деметры (также известного как Принцип наименьшего знания).

Давайте снова начнем с классной карты бинго: в конце концов, вся эта серия - это крутые и забавные вещи.

отказ от ответственности: этот пост предназначен для использования в развлекательных целях: вместо того, чтобы говорить о , что это такое, мы расскажем об источниках, авторах, последствиях 30-летней шумихи и некоторых интересных материалах о Деметре. . Бьюсь об заклад, вы понятия не имеете, кто она.

Мы 80-е, и двое парней из Северо-Восточного университета написали статью под названием «Обеспечение хорошего стиля для объектно-ориентированных программ», недавно опубликованную в IEE Software. Замечательное имя, не правда ли?

Этими ребятами были профессора Карл Либерхер и Ян Холланд, они работали в Demeter, исследовательской / проектной группе, которая провела несколько исследований и инструментов по ​​адаптивному и аспектно-ориентированному программированию. Давайте вспомним, что в конце 80-х объектно-ориентированное программирование взлетело вверх по сравнению с процедурным программированием, которое оказалось гораздо менее читабельным и обслуживаемым, а затем и менее прибыльным. Может быть, сегодня мы чувствуем то же самое с функциональным программированием, но по разным причинам (горизонтальный скейлинг, застой по закону Мура и проблемы параллелизма и т. Д.).

В этой статье они описывают Закон Деметры: метод, не зависящий от кода, который был придуман, усовершенствован и использовался командой при создании инструментов, и как он помогает сохранить модульный, инкапсулированный код (извините за шум ), а затем о том, как можно изменить каждую часть программного обеспечения, чтобы закон соблюдался.

Команда университета работала над языком описания оборудования под названием Zeus, и теперь вы знаете, к чему мы идем: в греческой мифологии Деметра и Зевс являются детьми Кроноса и Реи, а также родителями Персефоны. Работая над инструментом для упрощения языка, они искали имя, связанное с Zeus and Voila !, Деметра была выбрана в качестве названия команды и инструмента. Помните, что Деметра - богиня сельского хозяйства и распространения, и позже это имя было продвинуто как идея выращивать (помните, сельское хозяйство) программное обеспечение, а не создавать программное обеспечение. Замечательно то, как идея (давайте уменьшим дублирование кода), поведение (давайте попробуем следовать этой идее) и стиль кода (программирование, чтобы упростить соблюдение Закона) стал самой вещью в рамках проекта. В этом суть использования модных словечек: знания - это здорово, но как они улучшают продукт, команду или карьеру? Просто сказать, что X должен быть масштабируемым, ничего не значит: без знания реальной проблемы само слово бесполезно.

И действительно, первое упомянутое слово показало, что оно работает, потому что на протяжении этих 30 лет мы говорим об этом, и нет, это не ~ только ~ предотвращение двух точек в одном вызове.
Позднее авторы объяснили Закон в виде гениальный способ, расширяющий идею и возможности использования; на всякий случай, комбинируя это с идеей Мартина Фаулера «Говори, а не спрашивай», я считаю, что это шедевр при кодировании под ООП.

Спасибо, что прочитали второй пост из серии, а если вы пропустили первый, как насчет его взгляда? На следующей неделе мы собираемся исследовать теорию разбитых окон. Отзывы приветствуются, спасибо :-)

edit 1: Я отправил профессору Карлу электронное письмо с просьбой разрешить использование его имени в этом сообщении: он ответил мне и поддержал предложение идеи для тогдашнего аспиранта Яна.

Ссылки:
статья, статья IEE, страница профессора Карла, сайт проекта университета