OO -- When to collect attributes into objects?

Ruby
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

2

Hello,

On 8 Νοε 2014, at 12:12 , Leam H. [email protected] wrote:

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: [email protected]
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

3

On Sat, Nov 8, 2014 at 2:40 PM, Panagiotis A.
[email protected] wrote:

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

4

On 11/08/14 08:56, Robert K. 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

5

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.

6

On Sat, Nov 8, 2014 at 3:25 PM, Johnny M. [email protected]
wrote:

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

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

7

On Sat, Nov 8, 2014 at 3:19 PM, Leam H. [email protected] wrote:

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