Сколько частных переменных слишком много? Капсулирующие занятия? Практика класса?

Question

Хорошо, сейчас я работаю над внутренним пакетом статистики для python, который в основном ориентирован на комбинацию работы с геопроцессором arcgis для моделирования сравнения и инструментов.

В любом случае, у меня есть один класс, который вычисляет статистику. Давайте просто назовем это Stats. Теперь мой класс по статистике становится очень большим. Он использует статистику, рассчитанную по другой статистике, для вычисления других наборов статистики и т. Д. И т. Д. Это приводит к множеству частных переменных, которые хранятся просто для предотвращения пересчета. однако есть определенные, хотя используются довольно часто, они часто используются только одним или двумя ключевыми подразделами функциональности. (например, суммирование матричных диагоналей и вероятностей). Тем не менее, он начинает становиться основным зрачком, и я чувствую, что делаю это ужасно неправильно.

Так это плохо?

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

Что-то вроде этого действительно хорошая идея? Есть ли способ лучше? Прямо сейчас у меня есть более десятка различных подстатистических данных, которые помещаются в текстовый файл для создания небольшого отчета. Кодовая база растет, и мне бы очень понравилось, если бы я мог начать разделять все больше и больше своих классов Python. Я просто не уверен, что лучше всего делать такие вещи.

Answer 1

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

В любом случае, если бы мне нужно было подсчитать определенную статистику, я бы немедленно обратился к созданию отдельного класса для каждого из них. Я делал это однажды, когда писал программу статистики кода для python. Каждая статистика, например, сколько раз класс наследуется или как часто вызывается функция, была отдельным классом. Таким образом, каждый из них был прост, однако мне не нужно было использовать ни один из них в другом.

Answer 2

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

StatisticType = enum('AveragePerDay','MedianPerDay'...)

Другой вариант - использовать наследование следующим образом:

class StatisticBase
....
class AveragePerDay ( StatisticBase )
...
class MedianPerDay ( StatisticBase )
...    

Не существует жесткого и быстрого правила для «слишком многих», однако правило состоит в том, что если список полей, свойств и методов в свернутом состоянии длиннее одного экрана, он, вероятно, слишком большой.

Answer 3

Поскольку вы спрашиваете о передовых методах, вы, возможно, захотите проверить pylint (http://www.logilab.org/857).. В нем есть много хороших предложений о стиле кода, включая те, которые касаются количества закрытых переменных в классе.

Answer 4

Это обычный анти-паттерн, когда класс становится "слишком толстым" (имеет слишком много функциональности и связанного состояния), и хотя это обычно наблюдается в отношении "базовых классов" (откуда прозвище "толстый базовый класс" для анти-шаблон), это действительно может произойти без какого-либо наследования.

Множество шаблонов проектирования (DP для short_ могут помочь вам переориентировать ваш код, чтобы свести большой, непроверяемый, не поддерживаемый «толстый класс» к хорошему пакету взаимодействующих классов (которые можно использовать через DP «Facade» для простоты). ): рассмотрим, например, State, Strategy, Memento, Proxy.

Вы могли бы атаковать эту проблему напрямую, но я думаю, тем более что вы упомянули в комментарии, что рассматриваете ее как общую тему дизайна класса, она может предложить вам хорошую возможность углубиться в очень полезную область шаблоны проектирования и особенно «рефакторинг к шаблонам» (книга Фаулера под таким названием превосходна, хотя она не затрагивает вопросы, связанные с Python).

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