From: Gregory Brown <gregory.t.brown@...>
Date: 2007-01-04T08:37:57+09:00
Subject: Re: Object design

On 1/3/07, Krekna Mektek <krekna@gmail.com> wrote:

>  File object   -->  where methods are able to give the name, change
> the file name, changing the permissions of the file name
>
> Directory object  --> where methods are able to do the same sort of
> things as with the file name. This object can be a parent of the File
> object maybe.

Use the ruby classes for this, adding a few things if needed.  If you
need more than a few things, you can probably just subclass them, or
use Forwardable to avoid duplicating effort.

> SiteList object --> I now have this array just in my front-end code,
> but it could better be in an object? However, it is data, and should I
> put data in an object? It only changes when a site is added, which
> happens two times a year at a maximum.

Is your SiteList anything more special than an Array?  If it isn't
there is nothing wrong with an array.   If it is, you can preserve
much of your functionality by implementing a meaningful SiteList#each
and including Enumerable

> ThisSpecialTool object --> Do I need to make an object from this
> special tool which I use non-interactively?

Not necessary, but good for organization, future use, and of course, unit tests.

> Some sort of Ruby front-end is initializing the the objects and needs
> to be simple, the real code will be in the Site.class.rb,
> File.class.rb and Directory.class.rb

site.rb, file.rb, directory.rb

but there is no need for file.rb / diretory.rb unless the ruby classes
are too far from the mark.