Design: method in class or general function?

Peter Otten __peter__ at web.de
Mon Sep 11 03:30:12 EDT 2017


Leam Hall wrote:

> On 09/08/2017 03:06 AM, Peter Otten wrote:
>> leam hall wrote:
>> 
>>> On Thu, Sep 7, 2017 at 8:16 AM, Steve D'Aprano
>>> <steve+python at pearwood.info> wrote:
>>>
>>>> On Thu, 7 Sep 2017 07:20 pm, Leam Hall wrote:
>>>>
>>>>> OOP newbie on Python 2.6.
>>>>
>>>> Python 2.6 is ancient, and is missing many nice features. You should
>>>> consider
>>>> using the latest version, 3.6.
>>>>
>>>
>>> I've wrestled with that discussion for a while and Python 3 loses every
>>> time. There's literally no good reason for me to move to Python 3
>>> earlier than mid-2020's. Please accept the fact that there are hundreds
>>> of thousands of servers, if not millions, running Python 2.x. Whether or
>>> not Python 3 has any neat cool stuff is irrelevant to those of us
>>> seeking to use Python to get today's work done.
>>>
>>>> I create instances of Character class with an attribute dict of
>>>>> 'skills'. The 'skills' dict has the name of a skill as the key and an
>>>>> int as a value. The code adds or modifies skills before outputting the
>>>>> Character.
>>>>>
>>>>> Is it better design to have a Character.method that takes a 'skill'
>>>>> key and optional value or to have a general function that takes an
>>>>> instance, a dict, a key, and an optional value?
>>>>
>>>> I'm afraid your example is too generic for me to give an opinion. Do
>>>> you literally mean a method called "method"? What does it do?
>>>>
>>>
>>>
>>> Using this:
>>> https://github.com/makhidkarun/py_tools/blob/master/lib/character.py
>>>
>>> Line 19 sets "self.skills" either from the passed in data or from
>>> 
https://github.com/makhidkarun/py_tools/blob/master/lib/character_tools.py
>>> #L34-L48
>>>
>>> So Character.skills is a dict with a string key and an int value. I need
>>> to be able to add skills and my first attempt is a function:
>>> 
https://github.com/makhidkarun/py_tools/blob/master/lib/character_tools.py
>>> #L52-L56
>>>
>>> Should the "add_skills" function be a method in the character class or
>>> be made a more generic function to add/modify a key/value pair in a dict
>>> that is an attribute of an instance? Other tasks will require the
>>> add/modify functionality but coding that increases complexity. At least
>>> for me, anyway.
>>>
>>> Sorry about being unclear earlier, coffee was still kicking in and I'm
>>> still a newbie that mixes up terms.
>> 
>> I'm pleading "method" as it allows per-class implementation.
>> 
>> Say you use per-career subclasses of a general Character class. There are
>> default per-career skill sets, but usually a Character can acquire a
>> skill that is not needed in his career -- with the exception that Rogues
>> cannot tap dance ;)
>> 
>> Below is a way to implement that with a specialised add_skill() method:
>> 
>> $ cat basic_oo.py
>> from __future__ import print_function
>> import random
>> from collections import defaultdict
>> 
>> 
>> class Character(object):
>>      DEFAULT_SKILLS = ['Blade', 'GunCbt', 'Admin', 'Streetwise']
>> 
>>      def __init__(self):
>>          self.skills = defaultdict(int)
>> 
>>      def add_random_skills(self, terms):
>>          skillnames = self.DEFAULT_SKILLS
>>          for _ in range(2*terms):
>>              self.add_skill(random.choice(skillnames))
>> 
>>      def add_skill(self, name, amount=1):
>>          self.skills[name] += amount
>> 
>>      def __str__(self):
>>          skills = ", ".join(
>>              "{}={}".format(name, amount)
>>              for name, amount in sorted(self.skills.items())
>>              if amount != 0
>>          )
>>          return "{}({})".format(self.__class__.__name__, skills)
>> 
>> 
>> class Rogue(Character):
>>      def add_skill(self, name, amount=1):
>>          if name == "TapDance":
>>              raise ValueError("Sorry, this rogue will never tap dance")
>>          super(Rogue, self).add_skill(name, amount)
>> 
>> 
>> class Marine(Character):
>>      DEFAULT_SKILLS = ['GunCbt', 'VaccSuit', 'Leadership', 'Vehicle']
>> 
>> 
>> def main():
>>      NUM_CHARACTERS = 5
>>      CHARACTERS = [Marine, Rogue]
>> 
>>      characters = [
>>          random.choice(CHARACTERS)() for _ in range(NUM_CHARACTERS)
>>      ]
>> 
>>      for c in characters:
>>          c.add_random_skills(5)
>>          c.add_skill("RepairBicycles", random.randrange(3))
>>          try:
>>              c.add_skill("TapDance", 3)
>>          except ValueError as err:
>>              print(err)
>> 
>>      for c in characters:
>>          print(c)
>> 
>> 
>> if __name__ == "__main__":
>>      main()
>> 
>> $ python basic_oo.py
>> Sorry, this rogue will never tap dance
>> Sorry, this rogue will never tap dance
>> Sorry, this rogue will never tap dance
>> Rogue(Admin=3, Blade=4, GunCbt=2, Streetwise=1)
>> Marine(GunCbt=5, Leadership=4, TapDance=3, VaccSuit=1)
>> Rogue(Blade=3, GunCbt=2, RepairBicycles=2, Streetwise=5)
>> Rogue(Admin=1, Blade=2, GunCbt=5, RepairBicycles=1, Streetwise=2)
>> Marine(GunCbt=1, Leadership=3, RepairBicycles=2, TapDance=3, VaccSuit=2,
>> Vehicle=4)
> 
> 
> Okay Peter, I took your idea and mangled it beyond recognition. There's
> a design constraint I hadn't mentioned: an instance of Character should
> be able to have multiple careers.
> 
> Also, an instance can be created from scratch, created from a full set
> of data, or created from a partial set of data.
> 
> Here's my current code, focusing on creating a lot of merchants:
> 
https://github.com/makhidkarun/py_tools/blob/merchant/lib/character.py#L60-L61
> 
> python chargen.py
> Toby Verstraeten     564775     [M] Age: 41
>    Merchant (5 terms)
>    Computer-2 Engineering-5 Navigation-2 Pilot-1
> 
> Captain Ian Domici           789987     [M] Age: 24
>    Firster (3 terms) Merchant (3 terms) Noble (2 terms)
>    Broker-2 GunCbt-1 Streetwise-2
> 
> Rosa                 66495B     [F] Age: 24
>    Merchant (1 terms)
>    Computer-1 Navigation-1
> 
> 
> As you can see, lots to work on. However, with a very loose definition
> of "work", this works.
> 
> The goal is to have a set of Career classes. The program will allow a
> user to select one or more Careers. The program will create a basic
> character and then modify the character by the selected Career class(es).
> 
> If the Career does not exist in a file then the character gets assigned
> a generic Career based on social status.
> 
> Careers are each in their own file and the program builds the list of
> available careers by slurping up those file names.
>    Adding a Career should just be adding a properly formatted file.
>    Import happens when a Career is selected to modify the character
> 
> I've done this in Ruby so my guess is it can be done in Python. Even
> Python 2.  :D
> 
> The Career seems to be a "Decorator" pattern given my limited
> understanding of design patterns. Concur? If so I'll go study that some
> more.

The first thought that triggered was @decorator, and only then, because that 
didn't make sense, the focus changed on "design patterns". While I would 
tend to "composite" rather than "decorator" it's been some time since I read 
the book...
 
> Do you feel this path should still make a Career a class?

As long as it's only a dictionary entry

    self.character.careers['Merchant'] = self.terms

and the addition of some skills a function would work fine, too.
If you expect that you will later add other features which vary over careers 
you should consider a Career base class that you can subclass as needed. If 
you use a class it's worthwhile to keep the instance around

    self.character.careers['Merchant'] = self  # a careers set 
                                               # would work, too.

(If you want to avoid the reference cycle do not store the character as an 
attribute.)




More information about the Python-list mailing list