On 12 October 2012 19:37, Colin Putney <colin at wiresong.com> wrote:
> On Fri, Oct 12, 2012 at 9:21 AM, Chris Cunnington
> <smalltalktelevision at gmail.com> wrote:
>
>> And so I'm guessing that this idea of splitting a protocol from its class
>> has bled into Squeak from Objective-C in the form of Traits. Casimiro must
>> have a reason for using them that he likes. But they do seem like a
>> workaround as a result of a shallow hierarchy. I think I'd rather create my
>> own abstract superclass to define an interface.
>
> You might find this interesting:
>
> http://www.jot.fm/issues/issue_2002_05/article1/
>
> It's a paper about SmallInterfaces, which created first-class
> interfaces (in Java parlance) for Smalltalk. There was a Squeak port
> that ran in Squeak 3.2 IIRC.
>
> I find it much more fruitful to think about protocols rather than
> classes when designing or analyzing OO systems.

Same here. I think i even have class or two who serving just for
documentation purposes,
i.e. having no much sense to be inherited from, but just indicate what
protocol(s) should be
used for interacting with such kind of objects.

Today, i base my design on protocols and roles. By role i mean any
object at some certain place,
and that place (method argument, instance variable etc), defines what
protocol(s) a given role should conform to.
The inheritance is relevant only when you need polymorphism and to
reuse (inherit) large amount of common code, which every subclass
should (or can) use.


-- 
Best regards,
Igor Stasenko.