Instance variables and method parameters

Discussion in 'Ruby' started by Sam Kong, Aug 12, 2005.

  1. Sam Kong

    Sam Kong Guest

    Hello!

    I have a question about using instance member variables in a method.
    This is rather a general OO implementation question than specific Ruby
    one.

    As you know, all instance methods can access insatance member variables
    freely.
    Thus, instance member variables are like global variables in a class (I
    mean... in an object).
    So you don't have to pass those data beween methods in a class.

    However, I feel more comfortable when I make those data passed as
    arguments.

    See the examples (very simple and stupid one):

    class Tax1
    def initialize(emp_id)
    @emp_id = emp_id
    end

    def tax
    #explicitly pass the argument even if get_salary can access @emp_id
    salary = get_salary(@emp_id)
    return salary * 0.1
    end

    def get_salary(emp_id)
    #do some calcuation using emp_id and data from db
    #...
    return salary
    end

    private :get_salary

    end

    class Tax2
    def initialize(emp_id)
    @emp_id = emp_id
    end

    def tax
    salary = get_salary #no argument
    return salary * 0.1
    end

    def get_salary
    #do some calcuation using @emp_id and data from db
    #...
    return salary
    end

    private :get_salary

    end


    For public methods, it's obvious that you shouldn't put arguments as
    the format affects objects' clients.
    But for private methods, I like to make the methods more standalone
    (not depending the member variables).

    Is this an acceptable habit?
    Do you feel the same way as I do?

    Thanks.

    Sam
    Sam Kong, Aug 12, 2005
    #1
    1. Advertising

  2. Sam Kong <> wrote:
    > Hello!
    >
    > I have a question about using instance member variables in a method.
    > This is rather a general OO implementation question than specific Ruby
    > one.
    >
    > As you know, all instance methods can access insatance member
    > variables freely.
    > Thus, instance member variables are like global variables in a class
    > (I mean... in an object).
    > So you don't have to pass those data beween methods in a class.
    >
    > However, I feel more comfortable when I make those data passed as
    > arguments.
    >
    > See the examples (very simple and stupid one):
    >
    > class Tax1
    > def initialize(emp_id)
    > @emp_id = emp_id
    > end
    >
    > def tax
    > #explicitly pass the argument even if get_salary can access @emp_id
    > salary = get_salary(@emp_id)
    > return salary * 0.1
    > end
    >
    > def get_salary(emp_id)
    > #do some calcuation using emp_id and data from db
    > #...
    > return salary
    > end
    >
    > private :get_salary
    >
    > end
    >
    > class Tax2
    > def initialize(emp_id)
    > @emp_id = emp_id
    > end
    >
    > def tax
    > salary = get_salary #no argument
    > return salary * 0.1
    > end
    >
    > def get_salary
    > #do some calcuation using @emp_id and data from db
    > #...
    > return salary
    > end
    >
    > private :get_salary
    >
    > end
    >
    >
    > For public methods, it's obvious that you shouldn't put arguments as
    > the format affects objects' clients.
    > But for private methods, I like to make the methods more standalone
    > (not depending the member variables).
    >
    > Is this an acceptable habit?


    Well, acceptable by whom? If you work on this code with other people you
    should ask them. If you're doing it all on your own and don't plan to
    distribute it you decide. :)

    > Do you feel the same way as I do?


    Not exactly. I usually draw a line between general algorithms and methods
    specific to an instance. When implementing general algorithms, I choose
    static methods in Java and class methods in Ruby thus making clear they
    don't depend on instance state.

    class SillyExample
    attr :foo

    def initialize(foo) @foo = foo end

    def to_s
    # instance method
    SillyExample.transform foo
    # alternative invocation:
    # self.class.transform foo
    end

    def self.transform(s)
    # algorithm
    s.gsub(/^.*$/, '<\\&>')
    end
    end

    In your example I'd probably try to keep the DB code completely out of the
    class. There are plenty smart ways in Ruby to fetch data from a DB
    (ActiveRecord etc.) which don't make it necessary to scatter all persistency
    code throughout classes. If you want it in there then I'd prefer a mixin
    module that does all the db stuff. This can be reused by several classes.

    HTH

    Kind regards

    robert
    Robert Klemme, Aug 12, 2005
    #2
    1. Advertising

  3. Sam Kong

    Sam Kong Guest

    Hi, Robert!

    > Not exactly. I usually draw a line between general algorithms and methods
    > specific to an instance. When implementing general algorithms, I choose
    > static methods in Java and class methods in Ruby thus making clear they
    > don't depend on instance state.


    This is exactly what I was asking for.
    I'll follow the way you do.
    Thanks.


    Sam
    Sam Kong, Aug 12, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David Garamond
    Replies:
    5
    Views:
    243
    Ara.T.Howard
    Jun 8, 2004
  2. Phrogz
    Replies:
    1
    Views:
    106
    Phrogz
    Dec 24, 2006
  3. Raj Singh
    Replies:
    2
    Views:
    196
    Rick DeNatale
    May 29, 2008
  4. Greg Hauptmann
    Replies:
    9
    Views:
    245
    Loren Segal
    Jun 16, 2008
  5. Leslie Viljoen
    Replies:
    8
    Views:
    117
    Intransition
    Oct 29, 2009
Loading...

Share This Page