Andrew look at Josh's example. That's an= observer. A great example. The Baz Observer pattern =3D)

Also consi= der this. Baz becomes sort of like main ... but just for object's it= 9;s aware of. If you had another set like classes for a Lorem class and Ips= om class which instances are owned by a Dolor Observer object you could cre= ate another level observer which owns both Baz and Dolor.

Of course there are more than one way to skin a cat. Considering top le= vel of your application where self is actually main you can simply remove s= cope and program it like a shell script where everything is accessible from= your normal top down execution. Your dots act like pipes because ruby allo= ws data types to be first class which makes object.method or object.send( := method, :&message)

> %w{LOrem IPsum DOlr}.send( :map, &:swapcase)
=A0=3D> [&q= uot;loREM", "ipSUM", "doLR"]

Of cours= e send doesn't have to be used. You could just do:
%w{LOrem IPsum DO= lr}.map( &:swapcase)

or with a multi-line

["loREM", &= quot;ipSUM", "doLR"].map do |baz|
=A0 baz.swapcase
end=

and one liner

["loREM", "ip= SUM", "doLR"].map {|baz| baz.swapcase}

Though I'm using string objects in an array it would be = no different than your custom classes communicating within their own functi= onality and definition.

Using foo-bar-baz for learning th= is probably isn't the best approach. It may be better to talk about wha= t your modeling and what your program will be doing. It will get you furthe= r if your going for a proper abstraction which subsequently is something th= is programming language proves to impose no limitations on whether your imp= lementing on the classical class templates and returned results by falling = through ancestor inheritance which is an abstraction itself of the message = passing paradigm from smalltalk or doing it like a procedural macro shell s= cript or stack based C program or functional lispy meta programming yieldin= g values forward recursively. Ruby will allow you to do this any way you pl= ease. It's up to you to find which style you prefer and of course solve= your domain problem in the process.

Good luck and enjoy hacking Ruby

~Stu
<= /div>

On Tue, Jul 2, 2013 at 12:03 AM, Andrew S. <= span dir=3D"ltr"><lists@ruby-forum.com> wrote:

Jeremy Bopp wrote in post #1114156:

>
> Why do you have so many apparently rather tightly coupled classes? May= be
> the solution is to rethink your overall design to create fewer,
> more generalized classes.
>

This is a fair comment. =A0I think I need to step back and look at my=
design as a next step.

Cheers,

Andrew

--
Posted via http://= www.ruby-forum.com/.

--089e0160c5ce911ca904e0821d39--