3 ms·
I like to tell people about the UCO or "Unencapsulated Composite Operation". It tends to win arguments over "global functions are evil". Say you have two class
by kabdib 11y ago
I like to tell people about the UCO or "Unencapsulated Composite Operation". It tends to win arguments over "global functions are evil".
Say you have two classes, A and B. You have an operation that uses both of them. You can declare A::func(B) or B::func(A) but this couples the classes together. Yuckko.
So you just make a global function, func(A, B). The function gets its job done using public methods, and the classes remain unaware of each other.
That's the foot in the door. Then you whip multidispatch and CLOS on 'em and watch their eyes get real wide :-)
- arethuza 11y agoMove onto :before :round and :after methods - then finish with the joys of writing your own custom dispatch code. Leave a copy of AMOP as a going away present.
- lackbeard 11y agoIsn't coupling both A and B to the global func(A, B) just as bad as coupling B to A in A::func(B) or A to B B::func(A)? The thing you're trying to avoid with coupling is that when the dependency changes you might have to change the thing that depends on it, right? Isn't global func going to change with the same likelihood as A::func or B::func? I'm not sure if this is a relevant or not, (but since it relates to your post,) I do often find myself wishing I had multiple dispatch and/or some way to extend interfaces to existing types when programming in a language without those features.
- kabdib 11y agoNot the same; you can use A independent of B, they are not coupled and you don't even need them both in the product. You're free to change the global func independent of the classes.