I am developing some custom controls in an Object Oriented language (using Swift/Cocoa but this is a technology agnostic question). In particular, I have a horizontal and vertical set of buttons that behave very similarly except for the fact that one is oriented vertically and the other horizontally.My question: what is the correct way to structure these two 'things' in my project:Should I have a (abstract) parent class that has common functionality and then two derived concrete classes for the specifics needed for horizontal-ness vs vertical-ness. This feels the most correct but given that the object is composed of other objects you are then going to have proliferated throughout the view hierarchy going downwards.Alternately, should I design one highly generalised class that has a property for orientation and then a lot of if/switch logic in the code to drive behaviour based on this. This feels like a code-smell.Just go and create two separate similar but technically unrelated classes and just do a little more repeated typing. Since so many things are driven by the orientation this almost seems simpler than 1 above.Or is there another alternative?Other canonical examples where this would arise could be horizontal vs vertical:     - scrollers     - stacking panelsTo attempt to clarify on regarding design goals and requirements, I would like the question answered in terms of how Apple Software Architects might have approached the NSScrollView class (or how any large organization might approach similar UI library code with mirror horizontal and vertical components).The answer impacts several related vertical vs horizontal classes that aggregate these buttons into rows and columns respectively as the rows and columns themselves are also very similar save for the vertical vs horizontal orientation.
What is the correct Object Design/Architecture for the following scenario?
object oriented;gui;cocoa
As a note up front, I am not familiar with how the Apple UI components commonly work and I mostly have experience working with Qt. This might influence the applicability of my answer.I would start with a set of widgets that are orientation-neutral, but that can naturally be used where you expect an orientation-specific widget. For example a button where both dimensions can be set as fixed size or stretching and a grid with multiple rows and columns. These are concrete classes that can be used as-is.With these orientation-agnostic widgets, a vertical button is just a button with a (relatively small) fixed-size width. And a row is just a grid with only one row.How to realize this depends mostly on how the UI is typically being built.If the UI is mostly coded by hand, you can create orientation-specific derived classes that do nothing more than set the appropriate defaults of their orientation-agnostic base classes. A VerticalButton class would only have a constructor to set the button's width as a fixed value.This doesn't prevent someone from changing the width back to being variable, but that would be their own fault.If the UI is mostly generated from a graphical designer, I would look into the possibility of having the designer provide the widgets in multiple tastes (horizontal, vertical and orientation-agnostic) that instantiate each the same class with different settings.If that fails, I can always fall back to the first option.Only if the orientation-specific widget needs behaviour that can't be provided by the orientation-agnostic variant would I consider making a full-fledged class (with more than a constructor) for the orientation-specific widget.For example, if the text on a vertical button needs to be rotated, but the regular button class doesn't support text rotation.