Вопрос о том, включать ли что-то в метод __init __ ()

Question

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

Я определяю класс Seller(a, b, c, d).Существует много атрибутов этого класса, два из которых mostRecentProfit и profitHistory.Однако значения этих двух неизвестны, когда класс инициализируется.Некоторые другие шаги в программе должны быть выполнены, прежде чем они будут реализованы.Мои вопросы:

В __init__(a, b, c, d) класса продавца я должен написать

self.mostRecentProfit = None
self.profitHistory = []

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

Спасибо.

Answer 1

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

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

Answer 2

Я бы определил их. По моему опыту, не делать этого, когда код, работающий с экземплярами, часто ссылается на эти свойства, означает, что вы в конечном итоге наберете if object.profitHistory: перед циклом и т. Д. При пустом списке вы можете пропустить эти условия. И, как вы говорите, это делает его более разборчивым.

Answer 3

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

Итак, в вашем примере это означало бы инициализацию self.mostRecentProfit до 0 или, возможно, 0.0 вместо None. Это позволило бы использовать его как число без проверки его существования со значением, не равным None перед каждой ссылкой на него, или оборачивать каждый из них в блок try/except для обработки случаев, когда они никогда не были явным образом установить другое значение.