Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^4: OOP's setter/getter method - is there a way to avoid them?

by tiny_monk (Sexton)
on Oct 27, 2015 at 14:38 UTC ( [id://1146121]=note: print w/replies, xml ) Need Help??


in reply to Re^3: OOP's setter/getter method - is there a way to avoid them?
in thread OOP's setter/getter method - is there a way to avoid them?

Hello, AnomalousMonk. Thank you for pointing that out. So, is it safe for me to assume that each object attribute should both have a setter and a getter method? If I understood correctly, there has to be a way to update or access an object attribute.

  • Comment on Re^4: OOP's setter/getter method - is there a way to avoid them?

Replies are listed 'Best First'.
Re^5: OOP's setter/getter method - is there a way to avoid them?
by mr_mischief (Monsignor) on Oct 27, 2015 at 15:50 UTC

    Not all objects need setter methods. Not all values associated with an object with setters needs its own setter. The getter/setter pair is for things that are both to be accessed by other code outside your object and mutable (that is, updatable) outside the object or from elsewhere in the object.

    If you want an immutable value within your object, you don't have to provide a setter. This won't enforce encapsulation by itself, but it makes it apparent that there's an intent that the value not be updated. Actual enforcement of data hiding is a separate topic.

    If some piece of data should remain entirely private to your object or to the class, then there's no need to create a getter for it, either.

    As for encapsulation within the object, yes it's important that if you have a getter or setter that it retrieves or updates the data in the data structure itself. However, there is some convincing argument on either side of the issue of whether one value's setter and getter should ever access another value within the object directly even within the same object. Some people say direct access to another value in the same object is fine. Others recommend that any part of the object that isn't value B's getter or setter use those methods to access value B.

    Maybe you have a fruit that changes color as it ripens, but it's never going to change what kind of fruit it is.:

    use strict; use warnings; package Fruit; sub new { my $class = shift; my $self = { name => shift, color => shift }; bless $self, $class; }; sub get_color { return $_[0]->{ 'color' }; } sub set_color { $_[0]->{ 'color' } = pop; } sub get_name { return $_[0]->{ 'name' }; } package main; my $obj = Fruit->new( 'apple', 'red' ); my $obj2 = Fruit->new( 'banana', 'green' ); $obj2->set_color( 'yellow' ); use Data::Dumper; print Dumper( $obj, $obj2 ); for my $fruit ( $obj, $obj2 ) { printf "The %s is %s\n", $fruit->get_name, $fruit->get_color; }

      "Not all objects need setter methods. Not all values associated with an object with setters needs its own setter."

      mr_mischief, thank you for answering my question. I appreciate it. :)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1146121]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2024-04-24 23:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found