Nice discussion.
Thanks Christian.

On Mon, Feb 12, 2018 at 10:36 AM, Christian Haider
<christian.hai...@smalltalked-visuals.com> wrote:
> 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

Reply via email to