Это Микро. Увидев, что моя группа Makers закончила учебу и меня больше не запирают ежедневно в большой комнате с двадцатью другими небритыми инженерами-стажерами, я довольно неожиданно оказался без людей, с которыми можно было бы поговорить большую часть дня.

Иногда, когда вы зафиксировали проблему, и независимо от того, как сильно вы смотрите в экран, ноутбук не смягчается и просто отказывается от ответа, один из способов сдвинуть дело с мертвой точки – сформулировать его. . Для себя работает так же, как и для коллеги (или прохожего на улице, если вы можете не отставать от их спринтерского темпа); этот процесс называется Rubber Ducking, так как вы можете разговаривать со своей резиновой уткой (Micro) и получать точно такой же эффект. На самом деле речь идет только о том, чтобы услышать проблему и прислушаться к реакции, которую вы испытываете на свои собственные слова.

На днях я разговаривал с Micro об упражнении, которое я выполнял. В данный момент я нападаю на JavaScript, учитывая, что я намерен заняться фронтендом, чтобы начать свою карьеру, и я не мог понять решение, которое искал. Автор ввел в процесс разработки некоторые этапы, которые мне показались совершенно ненужными; однако, учитывая, что это, по сути, считалось решением, проблема была гораздо более вероятной со мной, чем с безликим разработчиком, чью работу я читал.

Я обратился к Микро.

"Микро", я сказал, что это за безумие?"

Микро посмотрел на меня.

«Правильно, вы не умеете читать. Вместо того, чтобы написать метод, толкающий самолет в ангар, у него есть методы посадки и на самолет, и на аэропорт. У самолета есть функция land() в паре с функцией permissionToLand(), которая есть у аэропорта. Используя его код, когда вы даете команду самолету приземлиться, самолет вызывает метод разрешенияToLand аэропорта, который, в свою очередь, помещает самолет в массив ангара.

"Почему".

Микро на какое-то время задумался и, казалось, собирался что-то сказать, но меня на мгновение охватил мнемонический хлыст. Призрак воспоминания проскользнул сквозь стену и стал бродить по слегка влажному, кишащему пауками чердаку моего разума: экземпляры классов не должны иметь возможности изменять состояние экземпляров других классов.

«Микро, подожди. Где я этому научился? Потому что это звучит как вещь, и я почти уверен, что не придумал это просто так».

Я оставил Micro читать об асинхронности (он большой поклонник ES8), а Slacked — коллеге (который, прочитав это, возражал против того, чтобы его называли коллегой). Конечно же, слабые следы ожогов от наполовину поглощенного воспоминания были правильными, и я дрейфовал в общем направлении Инкапсуляции.

Инкапсуляция — это один из четырех принципов объектно-ориентированного проектирования, и он просто гласит, что реализация класса должна быть такой, чтобы его состояние оставалось максимально скрытым. Состояние отображается, когда свойства и переменные могут быть изменены непосредственно другими объектами. Инкапсуляция:

…уменьшает сложность системы и повышает надежность за счет разъединения ее компонентов

("источник")

Когда вы идете за покупками и подходите к кассе с пакетом мини-чеддеров и салатным кремом, Tesco вынуждена попросить вас оплатить счет. Они не говорят вам, какова сумма вашей корзины, а затем ковыляют в местное отделение вашего банка, чтобы помочь себе. Ваш банковский баланс может считаться частью вашего состояния, и было бы совершенно неправильно, если бы этот баланс был доступен для изменения любым проходящим мимо.

Вы лично должны произвести оплату. Вы лично должны изменить свое собственное состояние. Инкапсуляция диктует то же самое для любого кода, который вы пишете. Экземпляр класса должен иметь интерфейс, который другие экземпляры могут использовать для запроса изменения состояния, но сама модификация — это то, что делает объект.

Причина, по которой это было особенно неловко осознавать, заключается в том, что этому учили в течение первых двух недель Создателей. Видимо, я был слишком занят полиморфизмом, чтобы взять это на вооружение.

Черт возьми.