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

Further to Athanasius's comments above:

My understanding is that the object's innards should stay inside the object.

But they can't stay inside forever. After all, an object's innards are data, and data must be accessed and sometimes even (gasp) changed in order to be useful. Consider the 'name' attribute in the example code of the OP. It has no getter/setter method. Except by direct reading or writing via the object reference, which we all agree is a Really Bad Idea and which no one will ever do, this data cannot be accessed in any way. What good is it? Of course, you can imagine you might write another method that would access it, say along the lines of

sub string_of {
    my $self = shift;
    return "$self->{color} $self->{name}";
    }
    
sub print {
    my $self = shift;
    printf "I am a %s \n", $self->string_of;
    }
[download]

Both these methods "expose" object attributes to application code without any risk that they may be changed, and why not? It's up to the library (or class) programmer to decide to offer such methods or not.

Give a man a fish: <%-{-{-{-<

Comment on Re^3: OOP's setter/getter method - is there a way to avoid them? Select or Download Code

Replies are listed 'Best First'.
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
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.	[reply]
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; } [download]	[reply] [d/l]
Re^6: OOP's setter/getter method - is there a way to avoid them? by tiny_monk (Sexton) on Oct 28, 2015 at 06:20 UTC
"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. :)	[reply]