Message passing between objects

I posted a question on this topic yesterday but used an example
specific to my application. But I wanted to re-post with a slightly
more abstract example and see what responses there are. My question:
How does ruby implement passing messages between objects.

An example might be a course registration system. In this system you
have student objects and a registration object. Your student object
can call the method student.register_for_course method. Now, before the
studen can register for the course we need to make sure the student has
met all the prerequisites. So ideally the student object would pass
the request to the registration object along with the name of the
course, the students id, etc. The registration object would call the
registration.prerequisite_met? method. Then it would return the
response back to the student object which could then procede with
either registering for the class or indicate that registration would
not be allowed.

Someone yesterday said you would create a superclass that both of these
objects would share and this superclass would handle communication
between the objects. I can see how that would work. But is that the
only way? Is there no way for ruby objects to communicate directly with
one another?

Thanks. TOD

On Wed, Sep 20, 2006 at 10:05:12PM +0900, Tod wrote:
[snip question]
Was it really necessary to send the exact same message twice, with a
slighty different Subject line?

Logan C. wrote:

On Wed, Sep 20, 2006 at 10:05:12PM +0900, Tod wrote:
[snip question]
Was it really necessary to send the exact same message twice, with a
slighty different Subject line?

Operator error. Too many things going on at once.

I do apologize.

TOD

Tod <todbramble gmail.com> writes:

not be allowed.
Well, one way to do it would be as follows. You could argue that there
are
better ways to fail Registration generation then raising exceptions, but
it’s
just an idea…

====================================
class Course
attr_accessor :name
attr_accessor :number
end

class Student
attr_accessor :name
end

class Registration
def initialize(student, course)
if student.name == “Bob”
raise ArgumentError, “Student doesn’t fulfill prerequisites for
the course”
end
end
end

s = Student.new
s.name = Bob
c = Course.new
c.name = “Advanced Hydronomics”
c.number = 1234
r = Registration.new(s,c)

Gareth

Tod wrote:

/ …

Someone yesterday said you would create a superclass that both of these
objects would share and this superclass would handle communication
between the objects. I can see how that would work. But is that the
only way? Is there no way for ruby objects to communicate directly with
one another?

No, in fact, there are any number of ways to do this. The question you
should be asking is which of the available methods meets your
requirements
most efficiently.

Obviously, using your example of a student registration system, the
student’s identity is the key to the relationship between objects.
Therefore a parent class containing everything that is known about the
student should deal with various aspects of the student – registration,
arranging for classes, health care, grades, whatever.

In the process of applying for a particular class for example, the
object
responsible for requesting a particular course would pass this request
to a
parent class that coordinates all activities for that particular
student,
and that class on turn would communicate with a class responsible for
assigning courses university-wide.

The student’s data is obviously self-contained, no peer-to-peer
transactions
required. But the communication between the student’s data and that
belonging to the university would be by way of another hierarchy of
classes, one in which the university’s master record-keeping system
would
be the parent of each student record.

My point is true peer-to-peer transactions without a parent class to
coordinate the activities are rare, and should be avoided if possible.
Many
data relations are naturally hierarchical, and this architecture is also
easy for the maintainer to understand and modify.

Paul L. wrote:

No, in fact, there are any number of ways to do this. The question you
In the process of applying for a particular class for example, the object

My point is true peer-to-peer transactions without a parent class to
coordinate the activities are rare, and should be avoided if possible. Many
data relations are naturally hierarchical, and this archite


Paul L.
http://www.arachnoid.com

Thank you so much Paul for taking the time to lay that out for me. I
appreciate it. The reason for the persistent nature of my question
originates from a book I have on Java (I am not a Java programmer but
this book helps me object oriented concepts) in which there is a
sub-heading in a chapter: Message Passing Between Objects (hence my
post title). In this section it appears (to my hazy mind) that they
are describing a direct object to object interaction. But I may be
wrong.

Here is what it appears to be saying using the student example:

Student s = new Student()
Course c = new Course()

Course c recieves the message: c.register(s)

before Course c can register s it sends a message to Student s, perhaps
s.successfullyCompleted(c2) where c2 is some other course that is
required for the current registration request. Student s replies to
Course c with true. Now Course c can register Student s and confirms
the to whatever originated the request (a GUI perhaps) by returning
true.

To me that looks like two objects communicating directly with one
another. But I am way out of my league here. The book is "Beginning
Java Objects (2nd Ed) Jacquie Baker (2005 Apress).

But again, thank you for your post above. TOD

Tod wrote:

/ …

To me that looks like two objects communicating directly with one
another.

It is, and IMHO it should be avoided to the degree possible. Again IMHO,
the
best data structure is a pure object-oriented one, in which all the data
objects are related by a class hierarchy, rather than by ad hoc
message-passing.

In the above example, the “registrar” class would possess the data
available
for each student and allow by direct access what would otherwise require
a
message protocol.

Example:


#!/usr/bin/ruby -w

class Registrar

Names = [ “Tom”,“Dick”,“Harry”,“Moe”,“Larry”,“Curly” ]

Classes = [ { :name => “Home economics”, :gpa => 2.0 },
{ :name => “Post-modernism”, :gpa => 1.5 },
{ :name => “Literature”, :gpa => 3.2 },
{ :name => “Comparative blogging”, :gpa => 3.0 },
{ :name => “Quantum physics”, :gpa => 3.5 } ]

def initialize
@student_list = []
1000.times do |n|
@student_list << Student.new(n,Names[n % Names.size],2.0 +
rand(100) / 50.0)
end
end

def get_student_data(n)
return @student_list[n]
end

def handle_application(student,class_data)
if student.gpa < class_data[:gpa]
puts “\tNo, forget it, #{student.name}, you aren’t smart enough
for
the #{class_data[:name]} class.”
else
student.class_list << class_data
puts “\t#{student.name}, you have been accepted for the
#{class_data[:name]} class.”
end
end
end

class Student < Registrar
attr_reader :name
attr_reader :id
attr_reader :gpa
attr_accessor :class_list

def initialize(id,name,gpa)
@name = name
@id = id
@gpa = gpa
@class_list = []
end

def list_classes
list = []
class_list.each do |item|
list << item[:name]
end
return list.join(",")
end

def to_s
return “ID: #{id} Name: #{name} GPA: #{gpa} Classes:
#{list_classes}”
end

def apply_for_class(class_data)
handle_application(self,class_data)
end
end

registrar = Registrar.new

100.upto(104) do |n|

student = registrar.get_student_data(n)

puts “Student #{student.name} applying for classes …”

Registrar::Classes.each do |class_data|
student.apply_for_class(class_data)
end

puts “Student data:”
puts “\t#{student}\n\n”

end


Try running this program, and examine how it works. It shows very simply
how
a class hierarchy can handle communication between objects (and it
should
be obvious how one student object could communicate to any other student
object by way of the registrar class).

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs