Am 11.02.2018 um 21:34 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Arghhhhhh no magic please. I got burned by too much DNU override.
+ magic number Norbert
On Sun, Feb 11, 2018 at 8:17 PM, Christian Caldeiro <christian.caldeiro@gmail.com> wrote:
Maybe using directly TwitterClient, but using #doesNotUnderstand: to delegate there message sends to the configuration object(kind of a proxy pattern). That way the TwitterClient class doesn't became so heavy.
Christian
On Sun, Feb 11, 2018 at 1:35 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Why not directly on TwitterClient ? That would be easiest for the user, then they do not need to know about TwitterConfiguration. Anyway, that is how I do it most often. The disadvantage is that TwitterClient might become a bit heavy, API wise, but you can delegate internally.
On 11 Feb 2018, at 16:25, Peter Uhnák <i.uhnak@gmail.com> wrote:
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