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.
--
https://mail.python.org/mailman/listinfo/python-list
