Представьте, если бы было возможно общаться со своим прошлым «я», разве вы не воспользовались бы даже самой запутанной возможностью?
В будущем тебе тоже нужна любовь. К счастью для нас, это не так запутанно… Но все равно…
Представьте, что ваш волшебный стикер путешествует во времени. Это не гладко; потому что есть озорные эльфы, которые пытаются изменить вашу заметку, чтобы направить вас по ложному пути и разозлить ваши рефактореры.
СОВЕТ. Используйте все доступные языковые и IDE-конструкции, чтобы в будущем вы (и другие разработчики) могли получить все возможные нюансы замысла вашего кода.
Javadoc
Давайте разберем это в мелодии Java. Что обычно можно сделать? Оставить будущему себе заметку в виде старого доброго javadoc или комментариев? Здесь прячутся озорные эльфы. Код имеет тенденцию меняться, а javadoc — нет. Есть обереги и талисманы, способные отогнать эльфов.
Пример (ниже) — обратите внимание, как это обычный текст. Это хорошая попытка оставить след из хлебных крошек, но она просто умоляет ошибиться. Кто-то скоро переименует SomeClass или someMethod, и будущее-я будет потеряно.
/* См. SomeClass.someMethod() для получения дополнительной информации */
Вместо этого (ниже) — использование {@link} делает ссылку на класс с учетом IDE. Переименование класса или метода также обновит javadoc. Пакости предотвратил и можно переходить по клику — так удобно!
/* Подробнее см. {@link SomeClass#someMethod()} */
Аннотации
Аннотации могут быть компактными javadoc или автоматизированными инструментами. Оба вида использования ценны, но реальная ценность исходит от их фактического использования И использования их должным образом. Были ли у вас мама или тетя, которые скупали все тренажеры «Как видели по телевизору», потому что собирались привести себя в форму, но так и не использовали их? Как будто. Это отличная идея, но вы должны приложить усилия.
«О да, я всегда использую аннотацию @Overrides». МОАР. Попробуйте создать свои собственные аннотации для общих комментариев внутри разработчиков, таких как некоторые, которые вы, возможно, видели:
@MainThread, // примененный к методу, ясно говорит разработчику, что этот метод следует вызывать только из основного потока.
@ThreadSafe // Также не требует пояснений.
@WorkAround(url="http://some_url_that_describes_a_known_bug")
Более того, можно создать средства проверки ворсинок для обработки этих аннотаций, чтобы проанализировать код и дать вам пощечину, если вы решите их игнорировать.
Продуманность инкапсуляции и API
Ваш код будет использоваться для колдовства всеми возможными способами, которые он неофициально поддерживает. Так что официально не поддерживайте ничего, чего не собираетесь делать. Что?… Большинство разработчиков используют автодополнение, чтобы узнать о возможностях класса, эта‹точка›…Поэтому скройте все по умолчанию и выставляйте только то, что необходимо. Вы всегда можете открыть больше позже, когда решите поддержать его.
«Подождите, но наследство» — туфта! Отдайте предпочтение композиции. На самом деле, я захожу так далеко, что создаю внутренние классы и компоную их, чтобы скрыть все, что могу.
Вот нелепый код, демонстрирующий ценность инкапсуляции через композицию.
В приведенных ниже примерах оба являются RayGuns, но ShrinkRay «является» ComplexGizmo, где ShrinkRayAdvanced «имеет» ComplexGizmo (через композицию).
Я призываю вас прочитать код здесь.
Активировать или сжечь? Я никогда не могу вспомнить. Нужно ли сначала шунтировать компенсаторы реальности или это какая-то другая сложная штуковина? Я никогда не могу вспомнить, и javadoc мало. Если бы я только лучше обдумал использование инкапсуляции.
Этот RayGun очень прост в использовании. Разоблаченные участники точно говорят мне, что я должен делать, потому что использование краткое. Я ясно вижу, что мне следует проверить, перезаряжено ли мое оружие, прежде чем стрелять. У меня даже есть возможность изменить цвет — хотя это то, что я могу игнорировать, это, по крайней мере, говорит само за себя.
Примечание. Можно дополнительно инкапсулировать, сделав setRayColor() защищенным, а затем предоставив статический фабричный метод для создания RayGun с предустановленным цветом, если это щекочет ваше воображение.
Сильная связь может быть полезной
Термин «тесно связанные» часто имеет негативный оттенок, связанный с ним. «Слабосвязанные» часто имеют положительную коннотацию, связанную с этим. Тем не менее, плотное или слабое соединение на самом деле просто еще один инструмент, как и любой другой, и может быть одинаково превосходным или ужасным в зависимости от использования или неправильного использования соответственно.
У меня есть еще один пост, посвященный исключительно связи, но сейчас давайте сосредоточимся на том, как ее можно использовать для общения с будущим я.
Тесно связанный код, которого не должно быть, сильно снижает способность к рефакторингу — это распространенная инженерная ошибка, из-за которой возникает негативная коннотация. С другой стороны; тесно связанный код, который должен быть, значительно улучшает рефакторинг. Связанный код, который концептуально связан, создает поддержку IDE и проверку во время компиляции для поддержки двух сущностей вместе. Это важно.
Выше показано то, что вы бы назвали неявной связью. Эти двое «предполагаются» для совместной работы. Неявная связь между рукой и перчаткой проистекает из того факта, что обе они имеют схожий интерфейс, а также из-за ментальной связи в нашем сознании — это не то, что нам нужно помнить, скорее, это выжжено в нашем мозгу.
В приведенном выше примере рефакторинг руки или перчатки путем добавления нового пальца сломал бы вселенную. Что еще хуже, мы не обнаружим этот сбой во время компиляции.
Это пример неумения общаться с будущим тобой.
В качестве альтернативы, жесткая связь была бы лучшим выбором. Мы думаем, что неявной связи достаточно, потому что нет необходимости помнить, как это правильно? Неправильно, код не имеет тех же нейронов, что и мы, если только мы не научим его тому, что рука и перчатка должны выстраиваться в одну линию. Тесная связь за счет того, что они оба реализуют интерфейс с пальцами, поможет. Теперь при добавлении нового пальца к любому объекту система не будет компилироваться, пока мы не разрешим все затронутые варианты использования.
