On 6/17/06, Laz [email protected] wrote:
You are right Daniel, what I should have been saying was instance
variable. It is a per-object reference that I was thinking about. My
mistake. So in that case then, would you think that it might be better
design to keep the active state stored as that instance variable,
therefore avoiding passing it into all the method calls, or keeping it
explicitly in the method calls?
In my opinion it is definitley good practice for an object to know it’s
state. In theoretical OOP design, an object should not allow other
objects
access to it’s internal workings. It should provide a way for other
objects
to ask it what a property is set to, and also tell it to update it’s
properties. Basically an object should be responsible for it’s data.
There
are many tutorials on OOP design on the web and I suggest that you take
the
time to read some of them. They are generally very good. The Pickaxe
and
Why’s Poignant guide are good. (Whys book is different but informative).
http://www.ruby-doc.org/docs/ProgrammingRuby/
http://poignantguide.net/ruby/
Other book resources for ruby can be found at
http://new.ruby-lang.org/en/documentation/book-list/
This is a very important concept in Ruby since everything is an object
and
basically works this way. So an instance variable regarding status
should
be hidden from other objects, but accessible with instance methods to
get
status and set status. ie I ask an article, are you active? and it
tells me
if it is.
In rails whatever fields the db table has, the corresponding model will
be
endowed with getter and setter methods for each field automatically
That means that if you have a status field in your database table, then
the
model will already have the methods required to access it and set it.
@my_model.status # returns the status variable
@my_model.status = “inactive” # to set the status
To make it’s state persistant (save it to the db) @my_model.save!
ActiveRecord is very nice for this. But this by itself doesn’t help you
find them which I believe was the subject of your initial post. To do
this
you use the find method provided by the ActiveRecord class. Since you
model
inherits from this class, your model gets a find method too. If you
have a
time where you are regularly performing the same action for a given
outcome,
then convinience methods are good.
def self.active_articles
find(:all, :conditions => { :active => true }
end
By declaring this you can now use
Article.active_articles
If you decide to change the definition of what makes an article active,
you
don’t need to surf your code and find everywhere you did
my_method_to_find_articles( “active” ) or
find(:all, :conditions => { :active => true } )
which may appear many times in many files to change the logic.
If in your code you aske the Article class or some parent object to get
all
the active articles when you want them, then you can change your logic
in
one place whenever required.
def self.active_articles
find( :all, :conditions=> { :active => true, :archive => false }
end
This is commonly refered to as DRY (Don’t Repeat Yourself) and makes
code
more readable and maintainable.
I am certainly no expert on this. I am new to programming in general
and
it’s not my day job. I really suggest you try looking at the Wiki on
www.rubyonrails.org and also try to find some blogs about this stuff.
People who know it much better than I do have put a lot of time into
explaining these concepts and you can learn a lot by reading their
blogs.
The rails blog is a good source.
http://weblog.rubyonrails.org/
and they also link to good blogs to get you started.
Cheers
Was there more to your comment as it seems to have been cut off, I think