model normalny, metody robia tylko to, co do nich nalezy, i tylko tyle, co do nich nalezy, sa tak male jak tylko mozliwe, a rozne rzeczy do zrobienia sa w roznych metodach.
class X : Forms
{
public X() { InitializeComponent(); jakasFunkcjaA(); }
private void button_Click(object sender, EventArgs e) { jakasFunkcjaB(); }
private void jakasFunkcjaA()
{
zachowanieA;
}
private void jakasFunkcjaA()
{
zachowanieB;
}
}
model "upakowany1", metody robia to, co do nich nalezy, i tylko tyle, co do nich nalezy, ale jedna metoda potrafi robic wiele podonych rzeczy. metody pobieraja wszystkie chwilowo uzywane wartosci przez argumenty, zachowanie jest ustalane przez wlasnie te argumenty. jezeli nie ma 'zachowaniawspolnego', jest to blad projektowy.
*takie cos dostajesz, w momencie kiedy starasz sie pisac normalnie, ale "zeby zaoszczedzic na ilosci metod" dopychasz nowa logike do starych metod, ktore juz sa gdziestam uzywane. czesty przypadek: to dodatkowe zachowanie rozni sie tylko troche od oryginalnego i nie chcesz kopiowac kodu
class X : Forms
{
public X() { InitializeComponent(); jakasFunkcja(false); }
private void button_Click(object sender, EventArgs e) { jakasFunkcja(true); }
private void jakasFunkcja(bool closing)
{
zachowaniewspolne
if(closing)
zachowanieA;
else
zachowanieB;
zachowaniewspolne
}
}
model "upakowany2", metody robia to, co do nich nalezy, i tylko tyle, co do nich nalezy, ale jedna metoda potrafi robic wiele podonych rzeczy. niektore argumenty zostaly przeniesione do stanu obiektu, bo sa potrzebne jeszcze w wielu innych metodach - szkoda je ciagle przepuszczac przez argumenty, ostatecznie troche to kosztuje.
*typowy przyklad takiego zachowania, to obiekty o silnie konfigurowalnych zachowaniu, np. w stanie obiektu jest jakas flaga mowiaca czy ladowac dane z bazy, czy z plikow, itp
- ponizszy przyklad jest pogladowy i pokazuje idee. taki konkretny uklad jest bledny, poniewaz fromButton jest uzywane chwilowo i ustalane kazdorazowo przed wywolaniem metody, wiec powinno byc jej argumentem
class X : Forms
{
public X() { InitializeComponent(); fromButton = false; jakasFunkcja(); }
private void button_Click(object sender, EventArgs e) { fromButton = true; jakasFunkcja(); }
private bool fromButton;
private void jakasFunkcja()
{
zachowaniewspolne
if(fromButton)
zachowanieA;
else
zachowanieB;
zachowaniewspolne
}
}
model nienormalny, "inteligentny", metody robia automagicznie to, co komus sie wydawalo ze do nich nalezy, i robia rozne rzeczy w malo jasnych warunkach.
*w ogolnosci, jezeli stosowane przez poczatkuajcych, zazwyczaj jest bledne -- wszystko zalezy od tego, co dokladnie sa to zachowania.. zwykle zachowania roznia sie bardzo i wowczas model ten powinien sie nazywac "debilny" poniewaz wprowadza innych ludzi czytajacych kod w blad/zdumienie.
*czasami natomiast jest wymuszony, mowi sie 'trudno' i zyje dalej, bo akurat jest to duzy punkt decyzyjny aplikacji i innego nie ma bo framework nie przewidzial, albo (..)
*czasami jest ok - jezeli metoda trzyma sie reszty zasad, a rozpoznawanie caller'a jest czescia intuicyjnego interfejsu obiektu
class X : Forms
{
public X() { InitializeComponent(); jakasFunkcja(this, EventArgs.Empty); }
private void button_Click(object sender, EventArgs e)
{
if(sender is Form)
zachowanieA; // np. pokoloruj pola na zielono
else if(sender is Button)
zachowanieB; // np. przeladuj dane i wyslij maila
}
}
i mozna jeszce pare wymyslic.. ale to Ci wystarczy