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
