Python OOP – One Boilerplate Class vs Many Similar Classes

class-designinheritanceobject-orientedobject-oriented-designpython

Lets say I'm trying to model a variety of objects that are virtually identical, the only difference being their class variables. Am I better off creating one boilerplate class and just calling the constructor with the specific variables, or creating a lot (in this case 100+) of essentially identical classes and hard coding their class variables (which will never change)?

To be clear:

Identical methods
Identical class variable names but different values
Identical intended functionality

To be clear, my language (Python) doesn't support interfaces that I'm aware of – some of the other similar questions seemed to get answers recommending that. The other option that seems to make sense to me would be to create a base class with each field and method and then create a bunch of unique child classes that contain their unique values.

The amount of work to create all the child classes isn't significant to me – I've written a program that quickly parses a text file (that has all the unique values) and can write all the classes to a .py file quickly and easily. Making changes down the road is rather easy for the same reason.

(somewhat) Related questions

Best Answer

100+ almost identical classes is crazy. Classes are organizational structures. Having dozens of them with almost no variation does't seem useful. It's over-specialization.

It sounds very much like you need a single class with a shared lookup-table that defines the shared info. Something like:

from collections import namedtuple

Lang = namedtuple('Lang', 'style points creator')

LANG_FORM = {
    'Python': Lang('dynamic', 84, 'Guido van Rossum'),
    'Java':   Lang('static', 65, 'James Gosling'),
    # ...
    'Pascal': Lang('static', 33, 'Niklaus Wirth')
}

class Protean(object):

    def __init__(self, name, form):
        self.name = name
        self.form = form
        self.lang = LANG_FORM[form] # optional

    # methods here

Here LANG_FORM can be a global variable (quasi-constant), or it could be a class variable. Either way, each instance gets basically just a pointer back to its shared info (what you refer to as class variables). It doesn't even strictly need that, if you're willing to index LANG_FORM whenever you need it, rather than memorizing it in each instance.

If you want to have each of the instances depict itself based on its form/kind/quasi-class, add a __repr__ method:

def __repr__(self):
    classname = self.__class__.__name__
    return "{0}-{1}({2!r}, {3})".format(classname, self.form, self.name, self.lang.points)

Then:

p = Protean('CPython', 'Python')

print p

Yields:

Protean-Python('CPython', 84)

Related Solutions

Python OOP – Splitting a Single Class into Multiple Classes

Generic functions should not go into classes. Python is not Java, it does not require pure functions to live inside classes. Only use classes if you want to store state of some kind. Put the functions into a standalone utility module, and import that into the module that contains your test classes.

Python – When to Create a Single Class Instance vs Working with the Class

Given a Python class which will be instantiated only once, i.e. there will be only one object of the class. I was wondering in which cases it makes sense to create a single class instance instead of working directly with the class instead.

So it's this:

class Singleton:
    '''don't bother instantiating me'''
    clsvar1 = 'foo'

    @classmethod
    def foobar(cls, *args, **kwargs):
        if condition():
            cls.clsvar1 = 'bar'

versus this?

class Singleton:
    '''instantiate and use me'''
    def __init__(self):
        self.var1 = 'foo'

    def foobar(self, *args, **kwargs):
        if condition():
            self.var1 = 'bar'

Recommendation

I definitely would prefer the one that's intended to be instantiated. When you create a "type of thing" that implies that you create things of that type.

The motivation is to group related code and data and having an interface to it.

That said, why not just use a module since all you want is a namespace? Modules are singletons, group related code and data, and this is a bit simpler and probably would be considered more Pythonic:

var1 ='foo'

def foobar(*args, **kwargs):
    global var1
    if condition():
        var1 = 'bar'

So the usage would be instead of:

from modules.singleton import Singleton
Singleton.foobar()

from modules.singleton import Singleton
the_singleton = Singleton()
the_singleton.foobar()

do this:

from modules import singleton
singleton.foobar()

Best Answer

Related Solutions

Python OOP – Splitting a Single Class into Multiple Classes

Python – When to Create a Single Class Instance vs Working with the Class

Related Topic