Массив против частного класса для внутреннего представления: этика Java

Question

Недавно у меня был вопрос по домашнему заданию, где мы должны были работать с шахматной доской и разместить на ней несколько королев.

Вопрос был тривиальным с точки зрения сложности, но я хотел спросить:

Должен ли я просто создать логический двумерный массив и изменить каждую позицию, содержащую ферзь, на 1?или я должен сделать закрытый класс для представления ферзя, у которого координаты x и y являются переменными экземпляра?

Это может показаться не очень важным или неотложным делом, но я использую Java, и это своего рода доходит до сути концепции ОО-программирования.Если мы никогда не используем модульные возможности Java, тогда зачем вообще использовать Java?С таким же успехом мы могли бы написать то же самое на C или Python.

Как вы думаете, что было бы более уместным в целом?Я был бы признателен, если бы вы могли ограничить свои ответы теми, которые подкреплены разумом, а не мнениями или личными предпочтениями.

Answer 1

Должен ли я просто создать логический двумерный массив и изменить каждую позицию, содержащую ферзь, на 1, или я должен создать закрытый класс, представляющий ферзь, который имеет координаты x и y в качестве переменных экземпляра?

Нет единого общего ответа на такие вопросы.Любой из них может подойти в конкретных ситуациях, решая конкретные проблемы.

Если мы никогда не используем модульные возможности Java, тогда зачем вообще использовать Java?С таким же успехом мы могли бы написать то же самое на C или Python.

Тот факт, что Java является ОО-языком, не означает, что мы должны определять и использовать классы и объекты для каждогочасть данных, которую мы должны представить.

Если я правильно понимаю ваш вопрос, вы спрашиваете о деталях реализации.Объектно-ориентированное программирование не столько заботится о конкретных деталях реализации, сколько о инкапсуляции тех подробностей реализации в подходящем интерфейсе, который хорошо представляет некоторую важную концепцию предметной области.Следовательно, клиенты класса не должны знать и думать о деталях его реализации, только об абстракции более высокого уровня, представленной интерфейсом.

Answer 2

Должен ли я просто создать логический 2-D массив и изменить каждую позицию, содержащую ферзь, на 1, или я должен создать закрытый класс, представляющий ферзь, у которого координаты x и y являются переменными экземпляра?

Это зависит от ваших потребностей.Если, например, вам нужно перебрать доску и проверить каждый квадрат, чтобы определить, есть ли королева, я бы выбрал первый подход, но если у вас есть только две или три королевы и вы принимаете решения в зависимости от их взаимного расположения, сохраняя координатыкак поле класса Queen было бы лучшей идеей, как для меня.

Это может показаться не очень важным или неотложным делом, но я использую Java, и это вроде как доходит до сути концепции ОО-программирования.Если мы никогда не используем модульные возможности Java, тогда зачем вообще использовать Java?С таким же успехом мы могли бы написать то же самое на C или Python.

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

Answer 3

Я знаю, что вам не нужно мнение, но я все равно дам вам его: общего случая нет. Искусство проектирования программного обеспечения заключается в том, чтобы сделать правильный выбор в структуре данных и кода в зависимости от специфики приложения. ОО-языки дают вам более выразительную палитру для дизайна, но нет жестких и быстрых правил, которые применяются в любой ситуации.

Итак, это мнение. Теперь к вашему конкретному примеру. Я мог бы задать себе вопрос: что полезнее? Отдельная фигура, знающая, где она находится на доске, или доска, знающая, где находится каждая фигура? Если у вас нет отдельного понятия доски, то есть в виде двумерного массива, содержащего фигуры, вам придется спрашивать каждую фигуру, где каждый раз вам нужно что-то делать с фигурой. Это, возможно, хорошо, если у вас есть только несколько фигур, но это становится неэффективным, если у вас больше фигур.

И наоборот, если, скажем, у вас очень большая шахматная доска - 500x500 - и на ней всего пара фигур, то двумерный массив будет очень неэффективным, поэтому разреженная структура данных, вероятно, будет лучше.

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

Answer 4

В этом случае правильный выбор - наличие двумерного массива Queens (отдельный класс, но без указания координат x, y) или логических значений (указывающих на наличие или отсутствие ферзя).Аргументация такова:

• Королевы как таковые не имеют позиции.Вы должны создавать свои объекты (POJO) независимо от того, где они будут использоваться, и включать в качестве членов класса только те свойства, которые имеют к ним отношение.
• Данные позиционирования не имеют никакого отношения к королевам и должны быть отделены от них.Проще говоря, заботиться о ее положении - дело не королевы, а внешней стороны (игрок, программа, что угодно).Это называется разделение обязанностей .
• Большинство алгоритмов, которые вы хотели бы использовать, будут более сложными для реализации и очень сложными для чтения и логического следования.Простые итерации доски были бы невозможны (или, по крайней мере, бесполезны).

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

Answer 5

Должен ли я просто создать логический 2-D массив и изменить каждую позицию, которая содержит королеву в 1 или я должен сделать частный класс для представления королевы, который имеет координаты х и у как переменные экземпляра?

Это действительно два вопроса:

1. Должен ли я хранить позиции ферзей в одном двумерном массиве или хранить координаты х / у для каждой королевы?
2. Должен ли я использовать простую структуру данных или класс для хранения этих данных?

Ответ на вопрос 1. Как указывают другие ответы: зависит. Используйте наиболее простую структуру данных для нужных вам алгоритмов.

Ответ на вопрос 2. Да, я бы всегда оборачивал структуру данных (независимо от того, что вы используете, список координат или массив) в классе. Даже если класс может показаться тривиальным, если вы используете класс, сразу станет очевидно, что вы сохраняете позиции. Если вы просто используете 2D-массив, люди должны будут задаться вопросом, что он делает. Кроме того, вы можете иметь подходящие методы в классе, применять инварианты (например, <10 ферзей) и т. Д. ... все, что нужно, -:). </p>

Answer 6

Вы можете адекватно представить состояние платы, используя любой из методов, которые вы описали. Наиболее подходящий подходящий метод будет зависеть от желаемого поведения системы, о котором нам не сказали.