Sławomir Czerwiński

Miałem pisać porady a nie krytykować, ale czasami niekompetencja niektórych osób sprawia, że krytyka aż sama się ciśnie na klawiaturę. Poza tym jeżeli ustrzegę przynajmniej jedną osobę przed popełnieniem tych samych błędów, może się to okazać nieocenionym dobrodziejstwem dla świata.

Na temat Delphi można powiedzieć wiele złego i wiele dobrego. Jako środowisko RAD pozwala w znacznym stopniu ograniczyć nakłady pracy związane z tworzeniem interfejsu użytkownika. Wprawdzie wiele osób ma zastrzeżenia do języka Pascal, ale poza ceną ciężko znaleźć jakieś poważne wady. Moim zdaniem jest to środowisko jak każde inne – dobry programista napisze dobry program, a zły nie.

A jednak wiele programów pisanych w Delphi zawiera ogromną ilość błędów, których poprawianie jest dla programistów prawdziwą udręką. Nie wspomnę nawet o szybkości obliczeń, która często pozostawia wiele do życzenia.

1. Podporządkowanie programu interfejsowi graficznemu

   Delphi umożliwia szybkie tworzenie graficznego interfejsu użytkownika. Jest to znaczne udogodnienie, ale i niebezpieczna pułapka. Wiele osób zapomina, że program to nie tylko ładne okienko, ale przede wszystkim logika biznesowa.

2. Pisanie całego kodu w zdarzeniach

   Klikając dwukrotnie na przyciksu można przejść do pisania kodu obsługującego zdarzenie OnClick, czyli zwyczajne wciśnięcie przycisku. Ale kod logiki biznesowej powinien być uporządkowany według funkcjonalności a nie nazwy przyciku. Dlatego też kod samego zdarzenia należy ograniczyć do minimalnej liczby wywołanych funkcji.

3. Tworzenie jedynie klas TForm i TDataModule

   Nie należy całego kodu programu zamykać w klasach okienek czy modułów danych. To są klasy służące uproszczeniu procesu projektowania interfejsu użytkownika i obsługi bazy danych. Logika biznesowa powinna znajdować się w klasach związanych z logiką biznesową.

4. Dodawanie nowego okna przy każdej nowej funkcjonalności

   Wiele elementów interfejsu użytkownika da się uogólnić. Przy odpowiednim zastosowaniu parametrów i dziedziczenia można wykorzystać to samo okno wielokrotnie.

5. Umieszczanie wszystkich komponentów statycznie na oknie

   Dokładnie rozplanowany interfejs może być ładny, ale czasem wymagane jest użycie różnych komponentów w zależności od sytuacji. Dlatego niektóre elementy interfejsu należy tworzyć dynamicznie.

6. Pozostawianie domyślnych nazw komponentów

   Jeżeli wszystkie obiekty nazywają się Label293 czy Button74, to… chyba już nic więcej nie dodam.

7. Brak komentarzy

   Jeżeli tworzy się projekt razem z grupą programistów, którzy nie mają umiejętności telepatycznych, należy opisać każdą nieoczywistą linię kodu.

8. Ścisła specjalizacja kodu

   Nie należy pisać wielokrotnie tego samego kodu w różnych fragmentach programu. Zamiast tego można utworzyć funkcje, które będą wykonywać te same czynności dla różnych obiektów czy zmiennych.

9. Nadużywanie parametrów

   Pewne parametry bardziej komplikują kod niż go uogólniają. Jeżeli w programie istnieje zmienna typu String, której wartość (jedna z 20) determinuje ciąg wykonywanych operacji, należy zamiast niej skorzystać z polimorfizmu.

10. Programowanie bez posiadania wiedzy programistycznej

    Właściwie jest to przyczyna wszystkich pozostałych błędów. Delphi umożliwia pisanie aplikacji osobom, które nie mają żadnego pojęcia o programowaniu. Każdy uczeń podstawówki albo – co gorsza – przekwalifikowany matematyk czy fizyk, który poklika pół godziny na komponenty, myśli że potrafi programować. Może „przekwalifikowany” to złe słowo, gdyż – wbrew praktyce – powinno ono oznaczać zdobycie nowych kwalifikacji.

    Żaden framework, żadne środowisko RAD nie zastąpi wiedzy i umiejętności człowieka. Jeżeli tych umiejętności brakuje dziecku z podstawówki – trudno – ma czas, żeby je zdobyć – w szkole czy na studiach (sam taki kiedyś byłem). Jednak osoba nazywająca siebie specjalistą powinna coś sobą reprezentować.

Mimo iż pisałem tu o Delphi, wszystkie powyższe uwagi dotyczą w równym stopniu też innych środowisk RAD – C++Builder, Visual Basic, wxDevCpp itp.