If you look at the layouts, you can see these questions for real. Take VerticalLayout. The idea is to stack children of some component vertically. Those children can be given a) no explicit size, b) an explicit size as pixel values, c) a percentage size. You know what the VerticalLayout is supposed to do, but how it does it depends on the platform. Plus there are some questions:
Do you provide an option to space them (a gap) or is that VerticalLayoutWithGap? Do you provide an option to horizontally align them or is that VerticalLayoutWithHorizontalAlignment? What if you want both a gap and an alignment? Is that VerticalLayoutWithGapAndHorizontalAlignment? Achieving a gap and alignment is pretty easy and I believe can be done within the same loop pass as stacking the elements. We circumvented the gap issue by saying you achieving by giving the children being stacked margin style values. So that eliminates two of the variations. But that comes at a cost on the SWF side (JS side handles margins in the browser) since it is way more complex to account for those margins and it might rightly be put into its own layout bead. And when you make these altered versions, its hard to subclass since you have the layout algorithm that you've have to tap into from the subclass and then call out or use a delegate. ‹peter On 6/6/17, 9:08 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: >On Tue, Jun 6, 2017 at 5:29 PM, Justin Mclean <jus...@classsoftware.com> >wrote: > >> Hi, >> >> > In FlexJS we have a preference towards utility classes. >> >> So say we have existing bead A and we want to add some functionality to >> to. In order to use utility classes we would need to modify bead A and >>pull >> out some of the code into a utility class so bead B can use it. >> >> This will increase the size/runtime cost to existing people using bead >>A. >> Is this accectable? >> > >Yes, there will be a size cost, which is why the inheritance approach is >better than Utils approach for Beads. > >*Utils approach:* > >Bead A supports feature X >Bead B needs to support feature X and Y > >Create a Util class called FeatureXAndY > >Bead A calls util:FeatureXAndY (Now Bead A loads code for unnecessary >feature Y) >Bead B calls util:FeatureXAndY > >*Inheritance approach:* > >Bead A supports feature X >Bead B needs to support feature X and Y > >Bead A has code for feature X alone (no extra code) >Bead B extends Bead A and adds code for feature Y (no extra code) >Moreover, no extra util class to maintain.
