That’s not what I’m suggesting at all. If utility classes (or utility functions) are bloated with lots of functionality then they are not done right.
Utilities should be reserved for well defined functionality. A good example of this is AnimationUtil. Imagine you have two animation beads which do different things, they would both use AnimationUtil for requestFrame and cancelFrame. The same goes for SolidBorderUtil (which should really be split into two). Any bead which needs to apply a border just calls the utility. So: Bead A supports feature X Bead B needs to support feature X and Y feature x used functionality a and b feature y uses functionality c and d Create a Util classes a, b, c and d which beads a and b use as needed. This is obviously not a pattern useful everywhere, but where applicable, has many advantages. Harbs > On Jun 7, 2017, at 4:08 AM, OmPrakash Muppirala <bigosma...@gmail.com> wrote: > > *Utils approach:* > > Bead A supports feature X > Bead B needs to support feature X and Y > > Create a Util class called FeatureXAndY
