0

I have the following scenario: I have Button and PreviewButton in Gui layer they have a common part named BasedButton. Button only knows IButtonPresenter, the interface of ButtonPresenter. The button should have no logic, the presenter could contain some logic. The problem is PreviewButton is so simple class that it hasn't need any presenter. Except one thing: hasLed() function which determines based on the button type (simple switch-case) that the Button and PreviewButton has a led or not. Where should be this common hasLed() function? My idea:

  1. PreviewButton should also have presenter and the hasLed() function should be in the common part of Button's and PreviewButton's presenter. Problem: it seems overengineering that only for this one function i should introduce the presenter.

  2. Put it this logic: hasLed() into the BasedButton (in common part of Button and PreviewButton). Problem: i tried to avoid putting any logic in my native Gui.

  3. Make some namespace (or use the button type enum namespace!) and put this simple function as inline function into it. Problem: the "logic" is placed in a "strange" and not expected class.

  4. Put hasLed() function into one of my our manager class in my presenter layer. Advantage: the manager interface is reachable for all native Gui class. And the code remains common (no code duplication). Disadvantage: my managers with such a function seems a little bit strange.

  5. Other idea?

Maybe now i would choose the 4th...

Gergely Tóth
  • 23
  • 4

1 Answers1

0

I'd go with the option 1. It's not over-engineerig (whereas trying to distinguish the PreviewButton from Button on the interface level does look like over-engineering to me), it's just boilerplate, but you avoid the unnecessary complication of the design that way.

vines
  • 5,160
  • 1
  • 27
  • 49