Sens dziedziczenia po System.Windows.Forms.Form w formatkach

Cześć koledzy,

Ostatnio zajmuję się głębszą analizą kodu dla co poniektórych rozwiązań, które można spotkać i które są proponowane jako słuszne. Stąd też pytanie nurtujące: jaki jest sens przy tworzeniu formatki by klasa dziedziczyła po System.Windows.Forms.Form?

Co stoi na przeszkodzie by klasa obsługująca formatkę wygląda w ten sposób:

namespace WindowsApplication1
{
    public class ClassForm
    {
        public ClassForm()
        {
            this.form = new System.Windows.Forms.Form();
            this.label = new System.Windows.Forms.Label();


            this.label.Text = "Helo";
            this.label.AutoSize = true;


            this.form.Controls.Add(this.label);
            this.form.Text = "Okno klasy";
            this.form.Size = new System.Drawing.Size(300, 300);


            this.form.Show();
        }


        System.Windows.Forms.Form form;
        System.Windows.Forms.Label label;
    }
}

Poproszę Was o komentarze.

Pozdrawiam,
Grzegorz

Nic nie stoi na przeszkodzie, przechodzisz z dziedziczenia do kompozycji, ktore w niektorych przypadkach jest wrecz zalecane. Ale w tym przypadku zauwaz, ze utrudniasz sobie zycie bo dodajesz sobie pare linijek kodu i chocby dlatego, ze takiej kompozycji nie wspiera designer ;) Oprocz tego nie masz dostepu do chronionych metod klasy Form, a moze to byc przydatne. Dziedziczenie jest tu naturalnym podejsciem, skoro ClassForm ma byc Twoja wersja okna. Innymi slowy rezygnujesz z czesci funkcjonalnosci, ktora zostala napisana juz w klasie Form.

Jeżeli by dorzucić do tego drugą formatkę, to byłoby to wygodne, żeby ułatwić sobie komunikację między nimi. Ale przez to wymusza się ścisłe powiązanie tych formatek. Tj. jeżeli będzie potrzeba użycia jednej formatki bez drugiej pojawi się problem rozdzielenia kodu obu formatek. To jest jeden argument przeciw takiej konstrukcji.

Drugi to podział aplikacji na warstwy. Taka konstrukcja byłaby czasem bardziej wygodna, ale jest niebezpieczna z tego względu, że zachęca do umieszczania logiki biznesowej, dostępu do danych i GUI w jednym miejscu. A co z tego wynika to chyba nie muszę tłumaczyć. Dziedziczenie każdej formatki z Windows.Forms.Form wymusza zastanowienie się nad tym jak formatki powinny się komunikować i jakie przekazywać między sobą (a nawet jeszcze lepiej między sobą a warstwą biznesową) dane.

Chyba że są jakieś mocne argumenty za użyciem takiego sposobu ;)

Kojarzy mi się to trochę z osobami, które piszą cały kod aplikacji w jednej metodzie i nazywają np. etykiety label1, label2 itd. Jest to wygodne do napisania prostej aplikacji do której nigdy się nie wraca. Ale przy ponownym otwarciu projektu jest on zupełnie bezużyteczny. Zdarza się tak, że czas napisania 'poprawnie' aplikacji jest wtedy krótszy od wprowadzenia najmniejszej zmiany.

Prowadząc jeszcze dywagację uniwersytecką, zastanawiam się czy jeśli pominiemy problem dostępu do metod prywatnych klasy Form, mimo wszystko nie uzyskamy większego rozbicia części aplikacyjnej od GUI.

W modelu kiedy za każdym razem gdy chcę stworzyć formatkę muszę dziedziczyć po klasie Forms.Form powoduje, że de facto łącze model aplikacji z GUI. Jeśli jednak uznał bym, że formatka mnie w żaden sposób nie interesuje, a skupiam się jedynie na części aplikacyjnej mogę doprowadzić do tego by jedna klasa reprezentowała GUI (może w tym wypadku dziedziczyć nawet to Forms.Form), a druga odpowiadała za część wynikającą z aplikacji, np. wypełnianie ListView z DataReadera, obsługę eventów itd..

W podobnym klimacie tworzona jest formatka z kreatora w VS C# 2005 - tyle, że w niej używana jest możliwość podziału klasy na osobne pliki.