My character generator does the basic task and I want to expand it. Since my experience has been with very small projects I'd like your advice on scaling up well; the project is my path for learning more Ruby and OOP. Are these the right classes and modules given the use cases?
Use Cases
···
=========
UC.1 Create a new character from scratch.
UC.2 Take existing character and add career.
UC.3 Take existing character and add skills.
UC.4 Take existing character and add missing base info (UPP, skin, hair, etc).
UC.5 Run dual careers (Navy and Noble).
UC.6 Convert from format X to format Y.
UC.7 Output to XML, JSON, Wiki, CSV, HTML, Neo4J, SQL.
UC.8 Tk based update tool.
UC.9 Mass modification based on search criteria.
UC.10 Relationships.
Classes and Modules
Class Character
Holds data like UPP, Gender, Name, Skills, Equipment.
Module CharacterTools
Methods to generate character data.
Module Traveller
Methods for common game conventions like dice rolling.
Module Presenter
Methods to format output.
Class Career
Class <Career>
Methods, Attributes, and other stuff to modifiy a character in line
with a specific career. Common career items like college might go
in CharacterTools. These modules use CharacterTools for things
like CharacterTools.modify_stat(options).
I don't immediately see anything massively wrong with this, FWIW, except: You won't know whether these classes are right until you code them.
What I'm trying to say is, take these classes as a rough blueprint, not a fixed plan. Don't be afraid to pick it apart and put it back together again different, half-way through.
Some places that you might end up:
* Maybe you will want the Career as mixin for Character instead of a separate class; maybe not.
* Maybe the skills will end up as mixins or decorators on the character class rather than inside it; maybe not.
* Maybe you will find that CharacterTools and/or Presenter will end up as a list of specific classes, doing one job each?
I can't tell you how the design should look (other than suggesting that a lot of little classes each doing one thing is a good idea); all I can say for sure is that if you design everything up front you will end up with a headache and not the best code you could have written...
So, don't worry too much about the design at this point.
(Aside: ah, Traveller; those black boxes! Although ended up playing a lot more Space Opera... Yes, I am ooold.)
···
-----Original Message-----
From: ruby-talk [mailto:ruby-talk-bounces@ruby-lang.org] On Behalf Of Leam
Hall
Sent: 23 January 2017 11:29 am
To: Ruby users
Subject: Right classes and modules for use cases?
My character generator does the basic task and I want to expand it.
Since my experience has been with very small projects I'd like your
advice on scaling up well; the project is my path for learning more Ruby
and OOP. Are these the right classes and modules given the use cases?
Use Cases
UC.1 Create a new character from scratch.
UC.2 Take existing character and add career.
UC.3 Take existing character and add skills.
UC.4 Take existing character and add missing base info (UPP, skin,
hair, etc).
UC.5 Run dual careers (Navy and Noble).
UC.6 Convert from format X to format Y.
UC.7 Output to XML, JSON, Wiki, CSV, HTML, Neo4J, SQL.
UC.8 Tk based update tool.
UC.9 Mass modification based on search criteria.
UC.10 Relationships.
Classes and Modules
Class Character
Holds data like UPP, Gender, Name, Skills, Equipment.
Module CharacterTools
Methods to generate character data.
Module Traveller
Methods for common game conventions like dice rolling.
Module Presenter
Methods to format output.
Class Career
Class <Career>
Methods, Attributes, and other stuff to modifiy a character in line
with a specific career. Common career items like college might go
in CharacterTools. These modules use CharacterTools for things
like CharacterTools.modify_stat(options).
Andy, thanks! I'm trying to learn "best practices" as well as Ruby and OOP.
I'm watching Robert Martin's Clean Coder stuff an the next big task will be
looking at names and making sure they make sense and are still used. The
code has grown organically and needs some clean-up too.
And, um, when you get the hankering for some Traveller Play by Post, let me
know.
···
On Mon, Jan 23, 2017 at 8:18 AM, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:
I don't immediately see anything massively wrong with this, FWIW, except:
You won't know whether these classes are right until you code them.
What I'm trying to say is, take these classes as a rough blueprint, not a
fixed plan. Don't be afraid to pick it apart and put it back together
again different, half-way through.
Andy, thanks! I'm trying to learn "best practices" as well as Ruby and OOP. I'm watching Robert Martin's Clean Coder stuff an the next big task will be looking at names and making sure they make sense and are still used. The code has grown organically and needs some clean-up too.
Code *should* grow organically -- at least it should if you are doing the Agile thing in any form -- although you have to be careful to design it so it can do so cleanly. Let me add to your learning burden by recommending a book that deals with this: Practical Object-Oriented Design in Ruby, by Sandi Metz (http://www.poodr.com/\). This is One Of Those Books --- where every couple of pages I go "oh" and "aha" and start grinning.
And, um, when you get the hankering for some Traveller Play by Post, let me know.
"Play by _post_"? Holy cow. That takes me back. I'll mail you off-list.
