Класс со слишком большим количеством параметров: лучшая стратегия проектирования?

ОБНОВЛЕНИЕ: этот подход может подойти в вашем конкретном случае, но у него определенно есть свои недостатки, см. kwargs - это антипаттерн?

Попробуйте такой подход:

class Neuron(object):

    def __init__(self, **kwargs):
        prop_defaults = {
            "num_axon_segments": 0, 
            "apical_bifibrications": "fancy default",
            ...
        }
        
        for (prop, default) in prop_defaults.iteritems():
            setattr(self, prop, kwargs.get(prop, default))

Затем вы можете создать Neuron следующим образом:

n = Neuron(apical_bifibrications="special value")

Я бы сказал, что в этом подходе нет ничего плохого - если вам нужно 15 параметров для моделирования чего-либо, вам нужно 15 параметров. И если подходящего значения по умолчанию нет, вы должны передать все 15 параметров при создании объекта. В противном случае вы можете просто установить значение по умолчанию и изменить его позже через сеттер или напрямую.

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

Или вы можете инкапсулировать части нейрона в отдельные классы и повторно использовать эти части для реальных нейронов, которые вы моделируете. То есть вы можете написать отдельные классы для моделирования синапса, аксона, сомы и т. Д.

Возможно, вы могли бы использовать объект Python "dict"? http://docs.python.org/tutorial/datastructures.html#dictionaries.

Наличие такого количества параметров говорит о том, что класс, вероятно, делает слишком много вещей.

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

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

Похоже, вы могли бы сократить количество аргументов, создав такие объекты, как Axon, Soma и DendriticTree вне конструктора LayerV, и вместо этого передавая эти объекты.

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

не могли бы вы предоставить пример кода того, над чем вы работаете? Это помогло бы получить представление о том, что вы делаете, и быстрее получить помощь.

Если только аргументы, которые вы передаете классу, делают его длинным, вам не нужно помещать все это в __init__. Вы можете установить параметры после создания класса или передать словарь / класс, полный параметров, в качестве аргумента.

class MyClass(object):

    def __init__(self, **kwargs):
        arg1 = None
        arg2 = None
        arg3 = None

        for (key, value) in kwargs.iteritems():
            if hasattr(self, key):
                setattr(self, key, value)

if __name__ == "__main__":

    a_class = MyClass()
    a_class.arg1 = "A string"
    a_class.arg2 = 105
    a_class.arg3 = ["List", 100, 50.4]

    b_class = MyClass(arg1 = "Astring", arg2 = 105, arg3 = ["List", 100, 50.4])

После просмотра вашего кода и осознания того, что я понятия не имею, как эти параметры соотносятся друг с другом (только из-за моего незнания в области нейробиологии), я бы порекомендовал вам очень хорошую книгу по объектно-ориентированному дизайну. «Развитие навыков в объектно-ориентированном дизайне» Стивена Ф. Лотта - отличное чтение, и я думаю, что он поможет вам и всем остальным в разработке объектно-ориентированных программ.

Он выпущен под лицензией Creative Commons License, поэтому его можно использовать бесплатно, вот ссылка на него в формате PDF http://homepage.mac.com/s_lott/books/oodesign/build-python/latex/BuildingSkillsinOODesign.pdf

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

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

class MyClass(object):

    def __init__(self, **kwargs):
        self.__dict__.update(dict(
            arg1=123,
            arg2=345,
            arg3=678,
        ), **kwargs)

Можете ли вы дать более подробный пример использования? Может быть, шаблон прототипа сработает:

Если есть какие-то сходства в группах объектов, может помочь шаблон-прототип. Много ли у вас случаев, когда одна популяция нейронов похожа на другую, только в чем-то отличается? (т.е. вместо небольшого количества дискретных классов у вас есть большое количество классов, которые немного отличаются друг от друга.)

Python - это язык, основанный на классах, но так же, как вы можете моделировать программирование на основе классов на языке, основанном на прототипах, таком как Javascript, вы можете моделировать прототипы, предоставляя вашему классу метод CLONE, который создает новый объект и заполняет свои ivars из родительского. Напишите метод clone так, чтобы переданные ему параметры ключевого слова переопределяли "унаследованные" параметры, чтобы вы могли вызывать его примерно так:

new_neuron = old_neuron.clone( branching_length=n1, branching_randomness=r2 )

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

Вы можете создать класс для своих параметров.

Вместо передачи нескольких параметров вы передаете один класс.

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

Например, в вашем __init__ у вас есть DendriticTree, который использует несколько аргументов из вашего основного класса LayerV:

main_apical_dendrite = DendriticTree(
    bifibs=apical_bifibs,
    first_sec_L=apical_sec1_L,
    L_sigma=L_sigma,
    L_decrease_factor=ldecf,
    first_sec_d=9, 
    branch_prob=apical_branch_prob
)

Вместо того, чтобы передавать эти 6 аргументов вашему LayerV, вы должны напрямую передать объект DendriticTree (таким образом, сохраняя 5 аргументов).

Вероятно, вы хотите, чтобы эти значения были доступны везде, поэтому вам придется сохранить это DendriticTree:

class LayerV(__Cell):
    def __init__(self, main_apical_dendrite, ...):
        self.main_apical_dendrite = main_apical_dendrite        

Если вы хотите также иметь значение по умолчанию, вы можете иметь:

class LayerV(__Cell):
    def __init__(self, main_apical_dendrite=None, ...):
        self.main_apical_dendrite = main_apical_dendrite or DendriticTree()

Таким образом, вы делегируете то, что по умолчанию DendriticTree должно быть классу, посвященному этому вопросу, вместо того, чтобы иметь эту логику в классе более высокого порядка, который LayerV.

Наконец, когда вам нужно получить доступ к apical_bifibs, который вы использовали для перехода к LayerV, вы просто обращаетесь к нему через self.main_apical_dendrite.bifibs.

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

Если вам кажется, что создание класса для группировки параметров является излишним, вы можете просто использовать collections.namedtuple , которые могут иметь значения по умолчанию, как показано здесь .

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

Возьмем, к примеру, реализацию кластеризации KMeans ++ в sklearn., который имеет 11 параметров, с которыми вы можете инициализировать. Таких примеров много, и ничего плохого в них нет.

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

class LayerV(__Cell):
    # author: {name, url} who made this info
    def __init__(self, no_default_params, some_necessary_params):
        self.necessary_param = some_necessary_params
        self.no_default_param = no_default_params
        self.something_else = "default"
        self.some_option = "default"
    
    def b_option(self, value):
        self.some_option = value
        return self

    def b_else(self, value):
        self.something_else = value
        return self

Думаю, преимущества этого стиля заключаются в следующем:

1. Вы можете легко узнать параметры, необходимые в __init__ методе
2. В отличие от setter, вам не нужны две строки для создания объекта, если вам нужно установить значение параметра.

Недостаток в том, что вы создали больше методов в своем классе, чем раньше.

sample: la = LayerV("no_default", "necessary").b_else("sample_else")
В конце концов, если у вас много необходимых параметров и параметров no_default, всегда думайте о том, выполняет ли этот класс (метод) слишком много вещей.
Если ваш ответ отрицательный, продолжайте.