Написання підтримуваного Go: освоєння структур, методів і мистецтва композиції

Чому підхід Go до об’єктно-орієнтованого дизайну є революційним

Багато розробників, що приходять із Java або C#-середовища, спочатку мають труднощі з Go. Шок приходить у дві хвилі: спершу «У Go немає класів!», а потім швидко — «Як я можу будувати без спадку?!»

Ось правда, яку я відкрив після років роботи з Go: те, що спочатку здається обмеженням, насправді є силою. Go змушує вас рухатися до більш чистої архітектури через композицію, неявне задоволення інтерфейсів і просту семантику методів. Розробники, які досягають успіху, не борються з цим дизайном — вони його приймають.

З мого досвіду перегляду кодових баз, я бачу найчастіше шаблони, що відображають поширені помилки:

• Ігнорування безпеки м’ютексів із значеннями-отримувачами (~25% викликає гонки)
• Несумісність типів отримувачів у межах одного типу (~35% структур змішують їх)
• Неналежне використання геттерів/сеттерів (~60% кодових баз)
• Спроби створити ієрархії спадкування (~40% новачків намагаються це зробити)

Різниця між розробниками, що мають труднощі з Go, і тими, хто вільно ним володіє, зводиться до розуміння одного концепту: як правильно проектувати структури та методи.

Рішення щодо отримувача: ваш фундамент

Розуміння двох типів отримувачів

Найбільш фундаментальний вибір у дизайні методів Go — чи має ваш отримувач бути значенням або вказівником. Ось практичне розрізнення: