CODEWITHSUNDEEP
pythondjangopython-3.x
nigel222
nigel222

Reputation: 8222

defining object method outside its class block, any reason not to?

The following surprised me, although perhaps it shouldn't have. However, I've never seen this done elsewhere

def bar_method(self):
    print( f"in Foo method bar, baz={self.baz}")
    # and pages more code in the real world


class Foo(object):
   def __init__(self):
       self.baz = "Quux"
   bar = bar_method

>>> foo = Foo()
>>> foo.bar()
in Foo method bar, baz=Quux
>>>

This follows from the definition of def which is an assignment of a function object to its name in the current context.

The great advantage, as far as I am concerned, is that I can move large method definitions outside the class body and even into a different file, and merely link them into the class with a single assignment. Instantiating the class binds them as usual.

My question is simply, why have I never seen this done before? Is there anything lurking here that might bite me? Or if it's regarded as bad style, why?

(If you are wondering about my context, it's about Django View and Form subclasses. I would dearly love to keep them short, so that the business logic behind them is easy to follow. I'd far rather that methods of only cosmetic significance were moved elsewhere).

Upvotes: 1

Views: 46

Answers (1)

bruno desthuilliers
bruno desthuilliers

Reputation: 77912

The great advantage, as far as I am concerned, is that I can move large method definitions outside the class body and even into a different file

I personnally wouldn't consider this as "a great advantage".

My question is simply, why have I never seen this done before?

Because there are very few good reasons to do so, and a lot of good reasons to NOT do so.

Or if it's regarded as bad style, why?

Because it makes it much harder to understand what's going on, quite simply. Debugging is difficult enough, and each file you have to navigate too adds to the "mental charge".

I would dearly love to keep them short, so that the business logic behind them is easy to follow. I'd far rather that methods of only cosmetic significance were moved elsewhere

Then put the important parts at the beginning of the class statement and the cosmetic ones at the end.

Also, ask yourself whether you're doing things at the right place - as far as I'm concerned, "business logic" mainly belongs to the domain layer (models), and "cosmetic" rather suggests presentation layer (views / templates). Of course some objects (forms and views specially) are actually dealing with both business rules and presentation, but even then you can often move some of this domain part to models (which the view or form will call on) and some of this presentation part to the template layer (using filters / custom tags).

My 2 cents...

NB: sorry if the above sounds a bit patronizing - I don't know what your code looks like, so I can't tell whether you're obviously already aware of this and doing the right thing already and just trying to improve further, or you're a beginner still fighting with how to achieve proper code separation...

Upvotes: 1

Related Questions