Heirarchy Troubles

[CBlair1986]

Hello all. I've got a somewhat unique problem, I think. I have a list
of classes planned out, with the attributes needed for them and
everything else, but I want to figure out how the classes should relate
to one another, so that I don't need to needlessly repeat myself.

For instance, say I have the classes planned as such:
class Apple
attr_accessor :taste, :type, :flavor, :flesh, ...
end
class Orange
attr_accessor :taste, :type, :flavor, eel, ...
end
and so on.

How would I go about fitting these together, so that I could have more
general classes such as Fruit and Vegetable and so on?

Thank you!

 

[Matthew Smillie]

Hello all. I've got a somewhat unique problem, I think. I have a list
of classes planned out, with the attributes needed for them and
everything else, but I want to figure out how the classes should
relate
to one another, so that I don't need to needlessly repeat myself.

This isn't unique at all, but is in fact one of the defining aspects
of all object-oriented design. You can learn about it in the Pickaxe
here: http://www.whytheluckystiff.net/ruby/pickaxe/html/tut_classes.html

For instance, say I have the classes planned as such:
class Apple
attr_accessor :taste, :type, :flavor, :flesh, ...
end
class Orange
attr_accessor :taste, :type, :flavor, eel, ...
end
and so on.

class Fruit
attr :taste, :flavor, ...
end

class Apple < Fruit
attr :something_unique_about_apples
end

class Citrus < Fruit
def prevents_scurvy?
true
end
end

class Orange < Citrus
# has everything from Fruit and Citrus and whatever's unique about
Oranges
end

class Lime < Citrus
# has everything from Fruit and Citrus and whatever's unique about
Limes
end


For simple, every-day objects, this is a fairly straight-forward
process: Take an apple, and take an orange. Make a list of the
properties of the apple you want to represent, and a similar list for
the orange. When you want to represent the same thing for both of
the objects, make a superclass for them for those attributes/methods
(Fruit, Citrus).

 

[Daniel Schierbeck]

Hello all. I've got a somewhat unique problem, I think. I have a list
of classes planned out, with the attributes needed for them and
everything else, but I want to figure out how the classes should relate
to one another, so that I don't need to needlessly repeat myself.

For instance, say I have the classes planned as such:
class Apple
attr_accessor :taste, :type, :flavor, :flesh, ...
end
class Orange
attr_accessor :taste, :type, :flavor, eel, ...
end
and so on.

How would I go about fitting these together, so that I could have more
general classes such as Fruit and Vegetable and so on?

Thank you!

class Fruit
attr_accessor :type, :taste, :flavor

def initialize(type = nil, taste = nil, flavor = nil)
@type, @taste, @flavor = type, taste, flavor
end
end

class Apple < Fruit
def flesh
# flesh the apple
end
end

class Orange < Fruit
def peel
# peel the orange
end
end

 

[David A. Black]

Hi --

Hello all. I've got a somewhat unique problem, I think. I have a list
of classes planned out, with the attributes needed for them and
everything else, but I want to figure out how the classes should relate
to one another, so that I don't need to needlessly repeat myself.

That's unique?!

For instance, say I have the classes planned as such:
class Apple
attr_accessor :taste, :type, :flavor, :flesh, ...
end
class Orange
attr_accessor :taste, :type, :flavor, eel, ...
end
and so on.

How would I go about fitting these together, so that I could have more
general classes such as Fruit and Vegetable and so on?

You could encapsulate the non-shared behaviors (or even the shared
ones, if you wanted) in modules:

module Peelable
attr_accessor eel
end

module Fleshy
attr_accessor :flesh
end

class Fruit
attr_accessor :taste, :type
end

class Apple < Fruit
include Fleshy
end

class Orange < Fruit
include Peelable
end

etc. That way, if you had more than one peelable class, and the
nature of peelability changed, you could change it all in one place.


David