开发者

wrapping a function in a class

This is not really language-specific, but I'll use Python to explain my question.

My program has several nearly self-contained functions. The command line arguments select one of these functions, and provide the input file name. The function is then executed:

# main.py:
import functions
def main():
  filename = sys.argv[1]
  function_name = sys.argv[2]
  function = getattr(functions, function_name)
  result = function(filename)
  # do something with result

# function.py contains all the functions:
def function1(filename):
  # ...

I had a feeling that I should probably use classes rather than functions, so I wrapped each function in a class. But now each class looks pretty silly: it开发者_如何学运维's only instantiated once, and all it does is execute its constructor, which does exactly what my old functions did. Then I can call a certain method to retrieve the return value:

# new version of main.py:
import classes
def main():
  filename = sys.argv[1]
  cls_name = sys.argv[2]
  cls = getattr(classes, cls_name)
  calculation = cls(filename)
  result = calculation.result()
  # do something with result

# classes.py:
import functions
class Class1:
  def __init__(self, filename):
    self.result = functions.function1(filename)
  def result(self):
    return self.result

# functions.py is unchanged

This doesn't seem to be any better than when I had functions. Is there a way to make my code object-oriented in a more useful way?


If you were writing Java or C# then you would implement these functions as static methods. In those languages all methods have to be part of a class due to the design of the language. In Python, whilst you can emulate a static method, there is absolutely no need to do so for this example.

Python's creator, Guido van Rossum, has argued in favour of the use of functions rather than methods.

First of all, I chose len(x) over x.len() for HCI reasons (def __len__() came much later). There are two intertwined reasons actually, both HCI:

(a) For some operations, prefix notation just reads better than postfix — prefix (and infix!) operations have a long tradition in mathematics which likes notations where the visuals help the mathematician thinking about a problem. Compare the easy with which we rewrite a formula like x*(a+b) into x*a + x*b to the clumsiness of doing the same thing using a raw OO notation.

(b) When I read code that says len(x) I know that it is asking for the length of something. This tells me two things: the result is an integer, and the argument is some kind of container. To the contrary, when I read x.len(), I have to already know that x is some kind of container implementing an interface or inheriting from a class that has a standard len(). Witness the confusion we occasionally have when a class that is not implementing a mapping has a get() or keys() method, or something that isn’t a file has a write() method.

Saying the same thing in another way, I see ‘len‘ as a built-in operation. I’d hate to lose that. /…/

Whilst this is not directly related to your question it does challenge the sometimes dogmatic stance that methods are always to be preferred to functions.

In my opinion, in Python, using functions is a better solution than creating classes.


Let's look at the specific case you are modeling. You want to associate a function (several functions!) with a string name, that gets passed in as sys.argv[1]. In python, the most convenient way to make an association from strings is with a dict! Your code might look a bit like this:

# main.py:
import functions
function_map = {
    'function1': functions.function1,
    'function2': functions.function2,
    'function3': functions.function3,
}
def main():
  filename = sys.argv[1]
  result = function_map[sys.argv[2]](filename)
  # do something with result

# function.py contains all the functions:
def function1(filename):
  # ...

Ok, so that's enough to get rid of the getattr(), but maybe there's a little more we can do. Some of those functions probably have some code in common; I'd bet that most of them try to open the file, although there may be some that don't. Now we're getting closer to something that might be a use for classes! You can still treat objects the same way as regular functions by defining a __call__ method.

class OpenFileFunctor(object):
    def __init__(self, mode='rb'):
        self.mode = mode
    def __call__(self, filename):
        # do some stuff with self.foo and filename!
        return open(filename, self.mode).read()

Alternately, you might just not have very much to say in the function body. You can use a lambda expression to shorten the function to just the entry in the dict.

# main.py:
import functions
import os
function_map = {
    'function1': functions.function1,
    'slurp_unviersal': functions.OpenFileFunctor('rU'),
    'is_text_file': (lambda fn: fn.lower().endswith(".txt") and os.path.isfile(fn)),
}


There is nothing wrong with global functions in your code if that's all that is needed of them. When you have functions that require being in class, they are normally related to that class and then they are called methods. :) There's no need to add the complexity of nesting a function within a class. Not in Python, anyway.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜