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 <s...@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.uh...@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 > > >
