История из моего класса чистого кода. Класс упражнений вращается вокруг разных аспектов игры в крестики-нолики.
Мне нравится эта игра в качестве платформы для упражнений: кажется, она не требует каких-либо технических требований.
Люди знают игру и предполагают, что они точно знают, как им нужно ее кодировать. Большинство из них пропускают этап проектирования. Каждый раз это иллюстрирует, как разработчики просто бросаются «делать работу», а не думать, проектировать и затем кодировать.
Одним из первых упражнений является начало написания кода для игры, в основном сосредоточенного на именах и операциях, а не на том, чтобы заставить его работать.
В конце упражнения мы просматриваем код одного из студентов. Это выглядело примерно так:
|
1
2
3
4
5
6
7
8
|
public class Game{public Game() {Board board = new board();Player playerX = new Player();Player playerO = new Player();}...} |
Выглядит достаточно невинно, верно? Я выполнил упражнение больше, чем помню, и много раз урок Game начинался именно так.
Вот в чем дело: обратите внимание, что игра создает доску ? Это означает, что есть новая доска для каждой игры.
Знаете, в реальной жизни на одной доске будет несколько игр. Если бы мы на самом деле думали о моделировании отношений между экземплярами Game и экземплярами Board, было бы много-мало-мало (или даже много-к-одному, если мы повторно используем плату).
Затем Игра создает экземпляры Player . Поскольку в требованиях, которые управляют игроками, нет указаний, игра является жизнеспособным выбором дизайна. Я не собираюсь обсуждать, где это хорошо или плохо, но это жизнеспособно.
Тем не менее, как мы можем прочитать код, мы видим, что класс Game не только содержит сущности Player и Board , но и фактически создает их.
Теперь, не могли бы вы описать такую игру другу, который не знает, во что все играют?
Нет. Вы бы описали это так:
В игру играют два игрока на доске.
Хотя код выглядит так:
Игра создает доску. Затем он создает игроков.
Словесные слова
Одна из вещей, о которых я говорю (неоднократно) в классе «Чистый код», — это важность вездесущего языка. Это означает, что мы используем как можно больше имен и терминов операций из реального домена (язык продукта) в рамках требований, дизайна, кода, тестов, документации и операций.
Поскольку мы имеем дело с кодом, вы уже видите диссонанс. Мы видим, что отношения между объектами в модели не такие, как мы описываем это в реальном мире.
Конечно, это может быть намного более простым. Многие участники, выполняющие упражнение, описывают доску в игре следующим образом:
|
1
2
3
4
|
public class Game { boolean [][] multi = new int[3][3]; ...} |
Я не знаю о вас, но никогда не слышал, чтобы игра описывалась с использованием слова «массив». Даже разработчиками. Давай, спроси их.
Выбирайте выражения
Конечно, английский и Java (или любое другое убеждение) разные. Языки имеют различия по своей сути.
Однако что происходит, когда у нас возникают ошибки при переводе? Иногда мы понимаем, что никакого вреда не было. Иногда мы получаем странный словарь с венгерского на английский .
В программном обеспечении мы в конечном итоге с ошибками. Некоторые из них несущественны. Некоторые из них основаны на неправильных предположениях и подкреплены неправильным переводом.
Как бороться с ошибками перевода? Ну, во-первых, признайте, что программирование — это переводческая деятельность, и поэтому она подвержена ошибкам перевода.
Во-вторых, не пропустите дизайн. Используйте термины из домена в коде.
Но также, расскажите историю использования. Если мы опишем игру так:
В игру играют два игрока на доске.
Тогда, возможно, код должен выглядеть так:
|
1
2
3
4
5
6
7
|
public class Player { public void play(Game game) {...}}public class Game public void setBoard(Board board) {...}} |
Есть только несколько, которые читают, как описано в игре. Если вы хотите легко обслуживаемый дизайн (а кто нет), начните с как можно меньшего количества переводов.
Вы поблагодарите себя позже.
| Опубликовано на Java Code Geeks с разрешения Гила Зильберфельда, партнера нашей программы JCG. Смотрите оригинальную статью здесь: Мой корабль на воздушной подушке полон угрей
Мнения, высказанные участниками Java Code Geeks, являются их собственными. |