Hi,
sorry to jump in here, but I think that this pattern is bad.
For your approach, you need to have setters on the configuration.
Do you really want to have methods to set the username and password from the
outside – maybe even after you logged in?
To me an object like your configuration should be a value, which can be created
but may never be modified after creation.
For this I would define a constructor:
TwitterConfiguration class>>username: aString password: anotherString
| inst |
inst := self new.
inst initializeUsername: aString password: anotherString.
^inst
And an initializer:
TwitterConfiguration>> initializeUsername: aString password: anotherString
username := aString.
password := anotherString
The two setters #username: and #password: should be deleted.
With TwitterClient at top, I would use constructors as well:
TwitterClient class>>username: aString password: anotherString
| inst |
inst := self new.
inst initializeConfiguration: (TwitterConfiguration username:
aString password: anotherString).
^inst
The nice thing about constructors is that the user knows what arguments are
expected to get a valid object.
The initializers are intentionally prefixed with the cumbersome “initialize…”
to indicate that they should not be confused with (multi-)setters.
(in VW, I additionally make these kinds of objects immutable to really make
sure that the object cannot be modified after creation.)
So, please, think twice about using setters. They should be not used for
initialization / configuration!
My 2 cents.
Cheers,
Christian
Von: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] Im Auftrag von
Peter Uhnák
Gesendet: Sonntag, 11. Februar 2018 16:26
An: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Betreff: [Pharo-users] Object configuration idioms
Hi,
are there any best practices/idioms in regards to object configuration/building?
Let's say I want to configure a TwitterClient that requires a username and a
password that is stored in a separate object TwitterConfiguration
a) the basic approach (either separate sends or via cascade, that is not
relevant here)
client := TwitterClient new.
client configuration username: 'XX'.
client configuration password: 'YY'.
b) #in: ...
It feels a bit more organized as it basically groups related operations
together.
Also maybe avoiding demeter a bit?
client := TwitterClient new.
client configuration in: [ :config |
config username: 'XX'.
config password: 'YY'.
].
c) custom #somethingDo: method that basically does #in:
Again, feels more organized. Additionally one could perform some validation
afterwards (to make sure the credentials are ok or whatever).
client := TwitterClient new.
client configurationDo: [ :config |
config username: 'XX'.
config password: 'YY'
].
Any thoughts on this?
Thanks,
Peter
