Здравствуйте, и добро пожаловать в мою серию статей по Go Pointers! Это то, чем я собирался заняться уже некоторое время. Наступил новый год, я только что закончил две недели отбора мощности и чувствую, что сейчас нет времени, как настоящее.
Почему я это делаю
Я думаю, что важно изучить мою мотивацию. Во-первых, я не буду здесь ничего кричать. По общему признанию, я испытываю любовь / ненависть к Го. Каждый день, работая с Go, я обязательно испытываю множество взлетов и падений. В некоторые моменты я восхищаюсь элегантной простотой языка или просто рад быстро решить проблему параллелизма. Я всегда удивляюсь легкости, с которой я могу кросс-компилировать код для альтернативных операционных систем и архитектур ЦП, на самом деле это часто моя самая большая мотивация для использования Go - это и тот факт, что это, несомненно, lingua franca распределенных вычислений. Но есть вещи, которые сводят меня с ума ...
Это та часть, где большинство комментаторов критикуют Go за что-то вроде отсутствия поддержки дженериков. И хотя, да, я считаю это существенным недостатком языка, я считаю, что, говоря тематически, есть что-то более широкое, что мы можем обсуждать эпизодически, что поможет всем нам стать лучше сусликами. На самом деле, я верю, что я стану лучшим сусликом, поделившись своими знаниями.
Сущность против Церемонии
Много лет назад я был так же глубоко укоренен в экосистеме Java / Spring, как и сейчас в экосистеме Go. Неоднократно мне доводилось слышать, как Венкат Субраманиам говорит о том, что он назвал «сущностью против церемонии». В то время это было представлено в контексте Java vs Groovy, но это понятие применимо в более широком смысле, чем это. Я перефразирую, но Венкат определил «сущность» как определенное je ne sais quoi, которое делает язык полезным. Он определил «церемонию» как всю нелепую работу, которую вы выполняете вручную (или с помощью инструментов) в качестве рутинной процедуры для устранения недостатков языка или просто потому, что кто-то сказал вам, что это лучшая практика. Венкат утверждал, что Java - это «церемония», в то время как Groovy содержит больше «сущности».
Я не хочу, чтобы этот пост превратился в пост, посвященный Java, но я думаю, что было бы полезно изучить простой пример на основе Java.
В Java видимость атрибутов класса и функций-членов может быть указана с помощью таких ключевых слов, как public
, private
и protected
. Если кто-то хочет, чтобы какой-то атрибут одного класса был видимым для других классов, может возникнуть соблазн сделать атрибут public
, но во многих случаях это нарушит инкапсуляцию. Возможно, например, допустимо, чтобы значение атрибута читалось другими классами, но не изменялось. Обозначая такой атрибут как public
, желаемый характер атрибута только для чтения не применяется, и внутренняя работа класса потенциально начинает просачиваться в остальную часть вашего кода. Это не буэно. На протяжении всего времени существования Java разработчики работали над этим, создавая public
функции-члены, называемые аксессорами и мутаторами ( или, проще говоря, «геттеры» и «сеттеры»), которые управляют доступом к private
атрибутам. Это улучшает соблюдение основных принципов объектно-ориентированного проектирования. Хотите, чтобы атрибут был доступен только для чтения? Без проблем. Предоставьте только "получатель".
Плохой:
Лучше:
Конечно, существует множество исключений из этого правила - случаи, когда «геттеры» или «сеттеры» могут выполнять более сложную логику, - но в целом проблема даже с лучшим из двух подходов выше - это частота сдвига, с которой разработчики должны писать такие банальный код. Это «церемония». Со временем IDE стали умнее и полезнее, и большинство из них может генерировать такой код от вашего имени. Но в какой степени это действительно решает проблему? Я бы не стал спорить. Несмотря на то, что вам не пришлось писать код вручную, он все еще существует. Он где-то находится в системе управления версиями, и кто-то в конечном итоге увидит этот код - и когда они это сделают, они вполне могут найти такой приземленный код, как этот, как шум, отвлекающий от гораздо более важных элементов.
Groovy (который компилируется в байт-код Java и выполняется в JVM точно так же, как Java) решает эту конкретную проблему, при отсутствии каких-либо модификаторов доступа для атрибута генерируя соответствующие «геттеры» и «сеттеры». для вас во время компиляции.
Тот же пример в Groovy:
Этот пример логически идентичен лучшему из наших двух примеров на Java, но идет без «церемониального» налога. В этом суть.
Ах да ... мы говорили о Go ...
Что ж, друзья мои. С сожалением сообщаю вам, что, хотя Go обладает большой сущностью в отношении определенных проблем - например, я считаю, что его подход к параллелизму соответствует требованиям, - тем не менее, в отношении многих других проблем он чрезвычайно высок. на церемонии - возможно, больше, чем на любом другом языке, с которым я работал. Это значит, что объем лучших практик, с которыми вы должны быть ознакомлены, чтобы писать (что я считаю) хорошим кодом Go, ошеломляет.
Возможно, это звучит не очень комплиментарно, поэтому, пожалуйста, отнеситесь к этому комментарию с недоверием. Программирование - это во многом упражнение по выбору правильного инструмента для работы, и я бы не стал беспокоиться об этой серии статей, если бы не думал, что есть много применений, для которых Go хорошо подходит. Также имейте в виду, что Go - все еще относительно молодой язык, и со временем он почти наверняка значительно улучшится.
Между тем, независимо от того, новички мы или эксперты, наши навыки игры в го могут быть улучшены только путем изучения особенностей Go и некоторых хорошо зарекомендовавших себя методов управления ими. Хотя я иногда отклоняюсь от этой темы, это является сутью этой серии - добывать гору хороших практик Go по одной лопате за раз.
Что ожидать
На данный момент я не собираюсь придерживаться какого-либо конкретного графика, но постараюсь публиковать короткие и удобоваримые сообщения как можно чаще. Я также приложу усилия, чтобы своевременно освещать темы, которые возникают в моей собственной работе, чтобы сообщения были хорошо информированы о недавнем реальном опыте.
Следите за новостями о первом (реальном) взносе, который выпадет на следующей неделе!