In other words: don't ask - tell. Instead of writing something like: object isSomething ifTrue: [ object doSomething ] ifFalse: [ object doSomethingElse ]
just write it: object doSomething that gives you much less code bloat, and much clear view of your intent(s) and even in case of exception , you can always interpret DNU as "object are missing feature, you asked for", which is again, reveals your intent. Also things like: object isSomething ifTrue: [ self doSomethingWith: object ] ifFalse: [ self doSomethingElseWith: object ] in general considered as anti-pattern, because you basically implementing polymorphic behavior in wrong place i.e. in code that using object, instead of code that belongs to the object itself. On 31 March 2017 at 03:05, Ben Coman <b...@openinworld.com> wrote: > > > On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont <step...@stack.nl> > wrote: > > On 30/03/17 16:03, Marc Hanisch via Pharo-users wrote: > >> > >> Reading this, I realized, that I never saw such type-checking in > >> Pharo production code. So the question is, what are recommended > >> design principles for that problem in Smalltalk? Do you use what is > >> called duck typing? > > > > > > Normally I'm not interested in what an object is, but what it can do. > > So a test on #respondsTo: can tell me if the object knows how to do > > something. > > > > In smalltalk, I can add methods to existing classes, so there are a lot > of > > extension methods on Object isXYZ, returning false. Morph returns true to > > isMorph, so all subclasses of Morph can be recognized that way. > > Many people also technically frown on isXYZ is a similar way to isKindOf:, > but it is a lesser evil and pragmatically is used reasonably often. > > > > > Instead of adding a test method, there are also empty implementations > > Like this, what you can do is refactor that guarded code into a method > #myAction > and add Object>>myAction which throws the exception. > Thus you condense multiple condition statements into > one location and your application code becomes much cleaner. > > Object may end up loaded with a lot of methods not of interest to every > object, > but the trade-off of cleaner application code is generally worth it. > > btw, Here you start to see how using Pharo/Smalltalk "changes the way you > think about programming". > > Further, the exception thrown by Object>>myAction > should signal the error on a custom error object, similar to ZeroDivide > for example. > > > > or ones that return self or an appropriate null-value. > > Within your framework where you control all the objects > the Null-object pattern is probably the cleanest OO approach, > but it can't control what the user passes across the public API. > https://en.wikipedia.org/wiki/Null_Object_pattern > > btw, you can search null-object pattern in Spotter using " Null #c " > > > cheers -ben > > -- Best regards, Igor Stasenko.
