OO -- When to collect attributes into objects?

ruby-talk
1

Naturally, learning Ruby is helped by linking it to a game. In this case Traveller. Leads me to a question about when something should be an attribute of the primary class or a class in itself.

In the game you have a character. Characters have stats like Strength, Intelligence, etc. Also things like age, skills, etc. Characters can acquire things like vehicles, ships, and money. It makes sense to make a space ship be a different class.

In the game characters tend to join some career for sets of 4 years. These careers provide more skills, rank, decorations, etc. Much of the character's nature is defined by the career path they choose. For example, a character might have spent 4 terms (16 years) in the Imperial Navy and earned a rank, learned several skills, attended specialty schools, and earned medals for valor. Each career path has a structure similar to the other careers but the class attributes would vary from career to career. A Navy rank would be different than an Army rank.

So the question is, should the career and subsumed attributes be a part of the character class or a class unto itself?

Thanks!

Leam

···

--
http://31challenge.net
http://31challenge.net/insight

2

Hello,

Naturally, learning Ruby is helped by linking it to a game. In this case Traveller. Leads me to a question about when something should be an attribute of the primary class or a class in itself.

In the game you have a character. Characters have stats like Strength, Intelligence, etc. Also things like age, skills, etc. Characters can acquire things like vehicles, ships, and money. It makes sense to make a space ship be a different class.

In the game characters tend to join some career for sets of 4 years. These careers provide more skills, rank, decorations, etc. Much of the character's nature is defined by the career path they choose. For example, a character might have spent 4 terms (16 years) in the Imperial Navy and earned a rank, learned several skills, attended specialty schools, and earned medals for valor. Each career path has a structure similar to the other careers but the class attributes would vary from career to career. A Navy rank would be different than an Army rank.

So the question is, should the career and subsumed attributes be a part of the character class or a class unto itself?

IMHO that's the most difficult programming problem: design :slight_smile:

I often reach a point where my program works, but then I find out that my models (design) are wrong, or not *as dynamic as they should* and re-write the entire thing (when possible/sensible to do so).

I don't think anyone can answer the question from the introduction you gave. In order for anyone to really help, you should provide at least *some* chunk of code, to see how it is structured.

Reasoning in terms of models (e.g. databases) I'd say that it's a better approach to create a different class for the attribute and just connect the attributed to the character, once the character has earned these attributes.

Thanks!

Leam
--
http://31challenge.net
http://31challenge.net/insight

Have a nice day! :slight_smile:

Panagiotis (atmosx) Atmatzidis

email: atma@convalesco.org
URL: http://www.convalesco.org
GnuPG ID: 0x1A7BFEC5
gpg --keyserver pgp.mit.edu --recv-keys 1A7BFEC5

"As you set out for Ithaca, hope the voyage is a long one, full of adventure, full of discovery [...]" - C. P. Cavafy

···

On 8 Νοε 2014, at 12:12 , Leam Hall <leamhall@gmail.com> wrote:

3

IMHO that's the most difficult programming problem: design :slight_smile:

And actually the most important one because it determines how you
reason about code, how well other people will be able to read it and
in what ways you can extend it.

I don't think anyone can answer the question from the introduction you gave. In order for anyone to really help, you should provide at least *some* chunk of code, to see how it is structured.

I beg to differ in this case. It is pretty obvious that a character
has any number of careers. That makes it a quite natural case for a
one to many relationship.

Reasoning in terms of models (e.g. databases) I'd say that it's a better approach to create a different class for the attribute and just connect the attributed to the character, once the character has earned these attributes.

Right.

Kind regards

robert

···

On Sat, Nov 8, 2014 at 2:40 PM, Panagiotis Atmatzidis <atma@convalesco.org> wrote:

--
[guy, jim].each {|him| remember.him do |as, often| as.you_can - without end}
http://blog.rubybestpractices.com/

4

A change in prospective is worth 80iq points. ~Alan Kay

Designing object classes with growth in mind, with the future in mind, is
the art of programming.

···

On Sat, Nov 8, 2014 at 6:19 AM, Leam Hall <leamhall@gmail.com> wrote:

On 11/08/14 08:56, Robert Klemme wrote:

And actually the most important one because it determines how you

reason about code, how well other people will be able to read it and
in what ways you can extend it.

Extensibilty is key. In theory others will take what I write and add stuff.

One option is to have all the possible attributes/methods as a part of the
base class and then do sub-classes that inherit the base. That covers 98%
or so of the use cases. But what if a person changes careers? That's a bit
trickier.

Since some places discourage inheritance I wasn't sure if it was the best
choice. I know Ruby allows inheritance; do it encourage it? Is there
another way to link one class to another?

Thanks!

Leam

--
http://31challenge.net
http://31challenge.net/insight

5

Extensibilty is key. In theory others will take what I write and add stuff.

One option is to have all the possible attributes/methods as a part of the base class and then do sub-classes that inherit the base. That covers 98% or so of the use cases. But what if a person changes careers? That's a bit trickier.

Since some places discourage inheritance I wasn't sure if it was the best choice. I know Ruby allows inheritance; do it encourage it? Is there another way to link one class to another?

Thanks!

Leam

···

On 11/08/14 08:56, Robert Klemme wrote:

And actually the most important one because it determines how you
reason about code, how well other people will be able to read it and
in what ways you can extend it.

--
http://31challenge.net
http://31challenge.net/insight

6

There is just one tricky thing about the future: you cannot know it
today. The number of systems designed with all sorts of future
requirements in mind that then were never needed is legion. This type
of over engineering has killed no few projects.

I am not saying it should not be done. But designing for the future
that will actually happen is quite difficult.

Kind regards

robert

···

On Sat, Nov 8, 2014 at 3:25 PM, Johnny Merrill <ruralhack@gmail.com> wrote:

Designing object classes with growth in mind, with the future in mind, is
the art of programming.

--
[guy, jim].each {|him| remember.him do |as, often| as.you_can - without end}
http://blog.rubybestpractices.com/

7

And actually the most important one because it determines how you
reason about code, how well other people will be able to read it and
in what ways you can extend it.

Extensibilty is key. In theory others will take what I write and add stuff.

One option is to have all the possible attributes/methods as a part of the
base class and then do sub-classes that inherit the base. That covers 98% or
so of the use cases.

If I understand what you are suggesting here you want to lump the
superset of all attributes needed by all sub classes in the base class
and only use part of them in any given subclass. That is an absolute
no go.

But what if a person changes careers? That's a bit trickier.

Objects cannot change their type. Rather you need aggregation for
this: the character _has a_ career (or multiple careers) but the
career is not an intrinsic property of him.

Since some places discourage inheritance I wasn't sure if it was the best
choice. I know Ruby allows inheritance; do it encourage it? Is there another
way to link one class to another?

Inheritance is generally overrated in my opinion. It does have its
uses and languages like Eiffel which allow fine grained controlled
inheritance may encourage to use it more often. But from what I see
inheritance is often used in places where composition would have been
more appropriate.

Kind regards

robert

···

On Sat, Nov 8, 2014 at 3:19 PM, Leam Hall <leamhall@gmail.com> wrote:

On 11/08/14 08:56, Robert Klemme wrote:

--
[guy, jim].each {|him| remember.him do |as, often| as.you_can - without end}
http://blog.rubybestpractices.com/