CODEWITHSUNDEEP
pythonoopmethods
LarsVegas
LarsVegas

Reputation: 6832

Class design: methods that share a lot of the same code

I want to create a class with two methods at this point (I also want to be able to alter the class obviously). 

class ogrGeo(object):

    def __init__(self):
        pass

    def CreateLine(self, o_file, xy):
        #lots of code


    def CreatePoint(self, o_file, xy):
        # lot's of the same code as CreateLine(), 
        # only minor differences

To keep things as clean and to to repeat as less code as possible I'm asking for some advise. The two methods CreateLine() and CreatePoint() share a lot of code. To reduce redundance: Should a define third method that both methods can call? In this case you could still call o = ogrGeo() o.CreateLine(...) o.CreatePoint(...)seperatly. Or should I merge them into one method? Is there another solution I haven't thought about or know nothing about?

Thanks already for any suggestions.

Upvotes: 1

Views: 562

Answers (5)

glglgl
glglgl

Reputation: 91159

You as well could go the other direction. Especially if the following is the case:

def methA/B(...):
    lots of common code
    small difference
    lots of common code

then you could do

def _common(..., callback):
    lots of common code
    callback()
    lots of common code
def methA(...):
    def _mypart(): do what A does
    _common(..., _mypart)
def methB(...):
    def _mypart(): do what B does
    _common(..., _mypart)

Upvotes: 0

Dave
Dave

Reputation: 3956

It hardly matters. You want the class methods to be as usable as possible for the calling programs, and it's slightly easier and more efficient to have two methods than to have a single method with an additional parameter for the type of object to be created:

def CreateObj(self, obj, o_file, xy)    # obj = 0 for Point, 1 for Line, ...

Recommendation: use separate API calls and factor the common code into method(s) that can be called within your class.

Upvotes: 1

ely
ely

Reputation: 77504

For the pieces of code that will overlap, consider whether those can be their own separate functions as well. Then CreateLine would be comprised of several calls to certain functions, with parameter choices that make sense for CreateLine, meanwhile CreatePoint would be several function calls with appropriate parameters for creating a point.

Even if those new auxiliary functions aren't going to be used elsewhere, it's better to modularize them as separate functions than to copy/paste code. But, if it is the case that the auxialiary functions needed to create these structures are pretty specific, then why not break them out into their own classes?

You could make an "Object" class that involves all of the basics for creating objects, and then have "Line" and "Point" classes which derive from "Object". Within those classes, override the necessary functions so that the construction is specific, relying on auxiliary functions in the base "Object" class for the portions of code that overlap.

Then the ogrGeo class will construct instances of these other classes. Even if the ultimate consumer of "Line" or "Shape" doesn't need a full blown class object, you can still use this design, and give ogrGeo the ability to return the sub-pieces of a Line instance or a Point instance that the consumer does wish to use.

Upvotes: 1

Martijn Pieters
Martijn Pieters

Reputation: 1125308

It's perfectly normal to factor out common code into a (private) helper method:

class ogrGeo(object)
    def __init__(self):
        pass

    def CreateLine(self, o_file, xy):
        #lots of code
        value = self._utility_method(xy)

    def CreatePoint(self, o_file, xy):
        # lot's of the same code as CreateLine(), 
        # only minor differences
        value = self._utility_method(xy)

    def _utility_method(self, xy):
        # Common code here
        return value

The method could return a value, or it could directly manipulate the attributes on self.

A word of advice: read the Python style guide and stick to it's conventions. Most other python projects do, and it'll make your code easier to comprehend for other Python developers if you do.

Upvotes: 2

Fred Foo
Fred Foo

Reputation: 363858

Whether you should merge the methods into one is a matter of API design. If the functions have a different purpose, then you keep them seperate. I would merge them if client code is likely to follow the pattern

if some_condition:
    o.CreateLine(f, xy)
else:
    o.CreatePoint(f, xy)

But otherwise, don't merge. Instead, refactor the common code into a private method, or even a freestanding function if the common code does not touch self. Python has no notion of "private method" built into the language, but names with a leading _ will be recognized as such.

Upvotes: 3

Related Questions