From: "Jesús Gabriel y Galán" <jgabrielygalan@...>
Date: 2013-07-02T21:37:55+09:00
Subject: Re: Designing a Cabinet class

On Tue, Jul 2, 2013 at 1:26 PM, Mike Vezzani <lists@ruby-forum.com> wrote:
> So here is my most recent work. I decided to completely set aside the
> idea of class Cabinet for now, and I have since designed a working class
> Drawer with the desired functionality. It works. I have run the program
> through and through and it accomplishes what I set out to do with a
> Drawer.
>
> My next challenge is understanding how to make a drawer object interact
> with its parent object Chest_of_drawers. I want to be able to write the
> following code:
>
> chest_of_drawers = Chest_of_drawers.new(4)
>
> and have a new chest of drawers object that contains 4 drawers. This
> goal pushes me past my understanding. I have no clue where to go next.
> Once again, sample code is welcomed, but ideally I'd like to have an
> explanation or a direction to some materials that I can read, and then
> try (and likely fail) on my own first before someone hands me ready made
> code that will accomplish what I'm looking for. I find that trial and
> error tend to teach me much more effectively than simply reading through
> correct code (though I see the value in that as well.)

Create a new class which contains the drawers. In the initialize
method, you can create that number of drawers and store them in an
instance variable (start with @), for example in an array. You can
then create a method in the Chest_of_drawers class to get at each of
the drawers by index (0 to 3). By the way, the convention in Ruby is
to use CamelCase for class names: ChestOfDrawers.

> @tamouse: I really appreciate your feed back (along with everyone
> else's). I'm curious, in what ways can I remove the user interaction
> portion of my code from my instance method and still have a class that
> will allow me to have an object with which I can interact?

You should move all the puts and gets to a different place (the top
level, for example), and change the interface of the Drawer class, so
that it receives the object to place, for example:

class Drawer
  attr_reader :drawer_contents # this creates a method that returns
@drawer_contents
[...]


  def place object
     raise "The drawer appears to be closed. Try opening it first."
unless @drawer_position
    @drawer_contents << object
  end
end

and in the main:

drawer = Drawer.new
puts "What would you like to put into the drawer for storage?"
thing_to_put_into_drawer = gets.chomp
drawer.place thing_to_put_into_drawer
puts "You now have #{drawer.drawer_contents} in the drawer"

This way, your Drawer class is much more reusable, for example if you
want to use it in a web application instead of a command line app. In
general a class should have one concern and mixing the drawer logic
with the user interaction logic is bad.

Jesus.