[Adium-devl] A thorny design problem

[David Smith]

On Nov 10, 2008, at 12:14 PM, Evan Schoenberg wrote:

>
> On Nov 10, 2008, at 2:51 PM, David Smith wrote:
>
>> 	In my ongoing project to get contacts in multiple groups working  
>> and simplify the implementation of the offline group, I've been  
>> attempting to make visibility of a contact depend on where it's  
>> being displayed, rather than being inherent to the contact. With  
>> visibility now being recalculated on request instead of cached,  
>> this is simply a matter of changing the visible property to also  
>> take a 'container' argument.
>>
>> 	However, this introduces a nasty issue: Part of the visibility  
>> logic is shared (handling 'always visible', for example) and part  
>> isn't (handling 'show offline' differs between the offline group  
>> and regular groups for example). If I duplicate the shared logic it  
>> violates Don't Repeat Yourself, with all the expected maintenance  
>> headaches that brings. If I leave the visibility logic in one place  
>> and add special cases for each type of container, that makes it  
>> difficult to extend, and violates encapsulation.
>
> What if rather than an object having a visible property at all --  
> which no longer makes much sense if one object can be in multiple  
> containers and therefore have a visible state in one situation but  
> an invisible state in another -- the logic were delegated to the  
> container?
>
> Container subclasses can call super's implementation to get the  
> shared logic, then OR this with their own visibility logic.
>
> Something like:
> -[NSObject<AIContainingObject> objectIsVisibile:(AIListObject  
> *)object]
> ?
>
> Cheers,
> Evan

The two are equivalent; in fact, my test implementation has - 
visibleInContainer: simply call the container's -visibilityForObject:  
method. The difficulty with using super to get the shared logic is  
that the return value is a boolean, so you can't tell (for example)  
whether the contact is invisible because it's offline (which the  
offline group does want to ignore) or because it doesn't match the  
current search (which it doesn't want to ignore). I suppose we could  
change the return value to be a bitfield of which conditions it  
matches... I'm not sure if I like that or not.

			David