Setter without a corresponding getter

Question

Possible Duplicate:
Do write-only properties have practical applications?

A getter without a setter makes total sense, of course. Read-only property. Got it, no problem.

But I'm maintaining some code right now where there are setters but no getters and I'm kind of puzzled by that.

Is there any reason I should be hesitant about adding getters? It's hard for me to imagine a setting where it's OK to change a value to whatever the caller wants (there's no sanity checks in the setters), but wherein it's not OK to tell the caller what the current value is.

The code happens to be PHP, if that matters for some reason.

I think this would be better on P.SE, since it is a conceptual question. voted to migrate — Matt Ellen, Nov 06 '11 at 21:21
Can't think of any setup where getters shouldn't be available. If there is a need to make them not public, you can do that. - I think you can just add them without thinking too much about it. — Smamatti, Nov 06 '11 at 21:23
@BoltClock: Not sure about the accepted answer on that question either, but the gentleman who pointed to Java.Random.setSeed() as an example where a setter may make sense without a getter...that seems pretty spot-on. Thanks! — Trott, Nov 06 '11 at 22:50

Deleted · Answer 1 · 2011-11-06T23:07:15.687

2

There are plenty of valid cases.

Consider this (excuse my PHP - it's rubbish):

class User {
    protected $password;
    public function setPassword($newPassword) {
        $this->password = sha1($newPassword);
    }
    public function verifyPassword($against) {
        return $this->password == sha1(against);
    }
}

We do not ever want the password hashed or otherwise to be visible outside of the object, yet we do not want to store the unhashed value in the object. We also do not want to break encapsulation for password validation.

edited Nov 06 '11 at 23:07

answered Nov 06 '11 at 22:59

Deleted

4,804
1
22
17

If I can't get the hash, then how will it get stored? -1 – HappyDeveloper Nov 08 '11 at 19:25
Your ORM (doctrine etc) can read protected fields and persist them to a database. The purpose of storage is not discussed here as it's an "ideal" example. Info here: http://www.doctrine-project.org/docs/orm/2.1/en/reference/basic-mapping.html ... this is a version of the OO principle of Separation of Concerns. – Deleted Nov 09 '11 at 09:34
I can't find in the link you posted where it says doctrine can do that (in those examples not even the setters are shown, so they are not complete). But even if it can, I don't think it's the way to go. We shouldn't go around using hacks like the reflection class to access data that shouldn't be accessed. Sometimes you must have public methods that are not ment to be used by the end user, and are there only to be able to communicate with other components. It's totally normal, and doesn't break the principle of separation of concerns. – HappyDeveloper Nov 09 '11 at 15:17
You are 100% incorrect. The field is protected, not private. Private data is not accessible. The protected field is accessible by proxies provided by the ORM which are superclasses of the object. Reflection is *never* used. You should NEVER expose public methods that aren't designed to be used by the end user - that's that hack here. I fire people for stuff like that! Have you ever used a (proper) ORM before? – Deleted Nov 09 '11 at 21:57
Then you are using protected attributes by default (instead of private), just to be able to access them. Now I know that you are using Active Record, which forces you to extend the ORM classes. Have you tried a Data Mapper-based ORM? Your objects shouldn't have to know at all that they are going to be saved to a database (much less how). They are just objects of your domain, with their own hierarchies, and with the best practice of 'private by default'. – HappyDeveloper Nov 09 '11 at 22:26
To sum up, your example can't be used in the real world, unless you are using active record (in which case, User should be extending another class), or you put a getter in place. – HappyDeveloper Nov 09 '11 at 22:27
@HappyDeveloper: Your assertion is flawed. Active Record is a pattern, not specific to field protection, not an ORM or a specific technology. It's actually mapping style. I suggest you grab a copy of the following book and read it: http://martinfowler.com/books.html#eaa then read http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215 - then I'm sure you will see my point. Protected still maintains encapsulation whereas public setters and getters don't. I think this is plainly obvious. – Deleted Nov 09 '11 at 22:37
Encapsulation is exactly what getters and setters are for. To let the object handle its own state, instead of modifying it directly from outside. Protected can bring trouble if people extend classes and access attributes in ways the class wasn't designed for. And I never said Active Record was an ORM, so don't put words in my mouth. That's why I said 'data mapper-based ORM', because it's a pattern (like AR). – HappyDeveloper Nov 09 '11 at 22:43
Read the DDD book - it goes into this in detail. – Deleted Nov 09 '11 at 22:50

score 0 · Answer 2 · answered Nov 09 '11 at 00:51

0

There is a school of thought that anything which is not needed to satisfy the requirements should not be coded. I suppose some people would even extend that philosophy to getters and setters.

answered Nov 09 '11 at 00:51

Alex D. Campbell

126
3

score 0 · Accepted Answer · edited May 23 '17 at 12:02

0

As pointed out in Do write-only properties have practical applications?, setting a seed for a random number generator is a pretty straightforward case where it totally makes sense to have a setter without a getter.

edited May 23 '17 at 12:02

Community

1
1

answered Nov 11 '11 at 17:35

Trott

66,479
23
173
212

Setter without a corresponding getter

3 Answers3