Могу ли я разделить методы на разные классы, передав свойства конструктора из одного класса в другой?
Ваш подход может быть приемлемым, если массив players не имеет скрытых зависимостей внутри вашего класса Players, поэтому ваш PointsManager может свободно манипулировать своим содержимым без риска создания каких-либо несоответствий. Например, по какой-то причине может быть атрибут «sumOfAllPoints», и класс Players может отвечать за синхронизацию этого атрибута с очками отдельных очков игроков, и в этом случае было бы плохой идеей позволить a PointsManager напрямую управлять точками в массиве игроков. Также нормально, когда ваш PointsManager просто читает данные из массива.
В противном случае было бы менее подвержено ошибкам добавление некоторых общедоступных методов доступа к классу Players, которые заботятся о согласованности, передают сам объект Players в PointsManager и позволяют PointsManager получать доступ к Players только через его открытый интерфейс. Недостатком является то, что это создаст циклическую зависимость между Players и PointsManager (что может быть здесь прекрасно или нет, это зависит от). Если циклическая зависимость начинает создавать проблемы, вы также можете ввести некоторый функциональный интерфейс, позволяющий PointManager получать доступ к точкам игрока через что-то вроде функции обратного вызова. Недостатком является то, что это сделает код более сложным и менее читаемым.
Когда вы сталкиваетесь с этой ситуацией в более крупном классе (например, в классе Board с квадратным массивом, о котором вы изначально говорили), вы можете либо передать квадратный массив в класс House (с указанными выше ограничениями), либо вместо этого объект Board себя (предполагается, что это обеспечивает некоторый интерфейс для последовательного управления квадратным массивом). В качестве альтернативы вы можете сначала инкапсулировать квадратный массив в новый класс Square, использовать его как член Board, а затем передать объект Square в House, если это помогает предотвратить несоответствия состояния.
И, пожалуйста, сделайте себе одолжение и перестаньте думать о безмозглых «лучших практиках». Все разные решения действительны, с разными компромиссами, здесь нет «общей передовой практики».
Рекомендую посмотреть эти видео для лучшего погружения в вопрос: