Design: method in class or general function?

[Leam Hall]

On 09/11/2017 03:30 AM, Peter Otten wrote:
> Leam Hall wrote:

>> 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.)
> 

Haven't read the GoF book. Last time I checked it said "this is only 
useful if you know Java", and I don't. Is there a good Python 2 
compatible reference? I just picked up an old copy of "Programming 
Python" and haven't gotten far into it yet.

My goal isn't to use patterns for the pattern's sake, but to use a 
decently right tool for the job. There will be a Career class that gets 
sub-classed. There are enough differences between the careers to need that.

I do not understand your last sentence about reference cycle. That may 
be where I'm struggling.

	A character is an instance of class Character.
	All characters have base attributes: upp, name, gender.
	A character will usually have a career.
	A character may have more than one career.
	A career modifies the character in one or more of the following:
		attribute skills
		attribute careers
		attribute age
		attribute stuff
		attribute background_info
	
Should the "run_career()" process be a method of character, with 
parameters of career and terms? Or a composite-ing class that created 
the character and then run them through the careers?

The composite model might work better as a future step will be to offer 
different ways to output the character; text to screen, json, sql, etc.

Hmm...thinking about the composite seems useful. That way users could 
add extra composite steps for their needs without flooding class 
Character with extra methods for each use case.