devel.cz

Pracujeme pro jednu firmu, kde se podílíme na vývoji jejich appky a jako součást iterace děláme vetší code review s SW Architektem. Na některých věcech se úplně neshodneme, na tom není ovšem nic špatného. Někdy mi však chybí smysluplné argumenty, na obouch stranách. Tak alespoň ne té mé bych s tím rád něco udělal. :-) Rád bych Vás tedy poprosil o Váš názor.

Zkusím časem přidávat další věci, které mě straší ve věži a třeba z toho vznikne pěkný seriál. Prosím zkuste k danému tématu přistupovat z rozmyslem a chladnou hlavou, ať z toho nemáme nějaký flameware. Stále se učím, tak mi prosím odpuste, že se sem tam objeví dirka v mých znalostech. Je to dáno nedokonalostí mého systému. Děkuji.

Budiž příklad z praxe, Round #1:

• implementace pro ovládání kamery, která lze zapnout, vypnout, zoom in, zoom out, nastavit 4 hodnoty pro WhiteBalance, 3 hodnoty pro kontrast
• limity: Net 4.0, WPF app, Castle Windsor, distribuovaný tým(DE, CZ), různý level znalostí (Jr,Sr).

Vedli jsme diskuzi, jak navrhnout interface pro přístup k výše definované funkcionalitě. Vcelku triviální téma, ale různé návrhy můžou značně změnit implementaci. Takže jaké jsou vaše argumenty pro a proti pro níže popsané konstrukty? Případně, přidali byste nějaký další?

1) metoda per action

public interface ICameraController{
    void SwitchOff();
    void SwitchOn();
    void ZoomIn();
    void ZoomOut();
    ...
}

2) Metody s argumenty

public interface ICameraController{
    void CameraEnabled(bool isEnabled);
    void Zoom(ZoomActionType zoomType );
    ...
}

3) Generic + commands

    public interface ICameraController
    {
        void RunCommand<TCommand>(TCommand command) where TCommand : ICameraCommand;
    }

Odpověd: Začnu od sebe, ať máte mustr.
Ad #1
Pro: Jednoduchost a přímočaré použití i pro začátečníka. Není nutné validovat žádné vstupní proměnné.
Proti: Mnoho metod. Při rozšíření funkčnosti nutné změnit interface. Duplikace kódu.
Ad #2
Pro: Stále jednoduché a pochopitelné pro začátečníka. Méně metod a méně kódu; Né pro všechny změny je nutno měnit interface, stačí třeba rozšíření enumerace vstupního parametru.
Proti: Pro některé typy nutná validace vstupní hodnoty, alespoň na null nebo invalid. Některé změny vyžadují změnu interface.

• v tomto řešení vidím minimální přínos, osobně bych preferoval řešení 1 oproti 2.
  Ad #3
  Pro: Jednoduše rozšiřitelné. Lze využít immutable command, které lze třeba použít až k samotnému zařízení.
  Proti: Komplexní řešení vyžadující mnoho tříd. Težší na použití. Nutno vytvářet commandy. Začátečník může mít problémy pochopit plně implementaci a vidět všechny relevantní podpůrné třídy (validace, factory, etc).
• Jo, je to určitě více rozšířitelné a univerzálnější, ale kódu napíši furt stejně. Navíc o dost komplexnejší použití.

Teším se na vaše plnohodnotné názory a případné návrhy, jak k danému problém přistupovat. Děkuji.

Pár otázek navíc k zamyšlení?
1) Kde je hranice, kdy interface má již mnoho metod? 10,20,50?
2) Jaký je argument pro použití proměnných oproti jednotlivým metodám?

Update

• trochu více k tomu kde zhruba je ten interface použit. Jde o interface , který je použit v UI vrstvě v WPF appce postavené na MVVM, takže v modelu. V podstatě je to Fire and Forget implementace, alespoň v tom controlleru. Jelikož na tom dělá ale tým v DE, tak jsme jim to chtěli udělat co nejjednodušší. Proto jsme na začátek volili #1. Během review jsme ale řešili, že je tam dost duplicit a že by to šlo zjednodušit do #2. Což se mi mo moc nelibilo, ale předělávat to do #3 je dost práce na víc. Nic proti tomu, jen jsem si chtěl potvrdit, že to má smysl. Do budoucna se tento scénář jistě bude opakovat a tak podle mě má smysl kouknout kolem a vyřešit to pořádně.
• Aleš nastínil zajímavé řešení v jednom komentáři, tak ho snad z něj vytáhnu.