Prymitywne sposoby rozwiązywania problemów

0

Witam,

Nie wiem czy to dobry dział, ale zaryzykuję ;)

Mam do Was następujące pytanie:

Czy cel uświęca środki? Czyli czy każdy sposób rozwiązania danego problemu może być stosowany, byleby uzyskać spodziewany efekt, czy raczej powinno się dążyć do stosowania poprawnych "książkowych" rozwiązań?

Przykład (delphi):

Mamy okno parent i chcę wywołać okno child, przy czym jego praca ma kończyć się na dwa sposoby w zależności od wywołania tego okna (tj. zależy który button go wywołał).

Właściwie można rozwiązać to na różne sposoby:

  • zadeklarować ładną zmienną
  • sprawdzać Sender
  • wstawić na formę child checkboxa, ukryć go i przy show formy prymitywnie go sobie zaznaczać lub odznaczać, a następnie badać stan
  • przy show formy zmieniać jej caption w zależności od tego, co ją wywołuje, następnie sprawdzać go na zamknięciu.

Zawsze na koniec uzyskam taki efekt, jaki chcę, a ilość kodu i szybkość wykonania każdego z pomysłów jest podobna, przy czym dwa ostatnie trącą prymitywizmem ;-P Nie są pr0 ;-P Ale user i tak nie widzi kodu ;-P No i co teraz - lepiej być pr0, czy iść na łatwiznę i zapodać if'a?

Pozdrawiam ;)

0

Tu nie chodzi o to, ze nie sa "pro".

Problemem jest to, ze jak za jakis czas wpadniesz na pomysl przerobienia aplikacji, dwa ostatnie sposoby moga program czynic podatnym na bledy. Druga sprawa to fakt, ze wstawienie checkboxa, ktory sam w sobie ma pole do przechowania wartosci, oznacza dodanie calej masy niepotrzebnego Ci kodu; po co wstawiac komponent, ktory robi A i B, kiedy elegancko i szybko mozna zrobic samo A, nie zasmiecajac sobie interfejsu uzytkownika.

Wezmy inny scenariusz: napisales fajny/ciekawy program i dajesz kod koledze, by go zmienil (rozbudowal/poprawil/dostosowal). Czy sadzisz, ze kolega, widzac checkbox'a na formie, wpadnie na to, ze nie ma on zadnego znaczenia dla uzytkownika, bez przegladania kodu (lub co gorsza edytora wlasciwosci obiektu!). Prawda jest taka, ze gdy piszesz program sam, to wszystko moze Ci kompletnie zwisac, o ile dziala szybko i nie powoduje bledow.

Zastanow sie tylko nad dwoma rzeczami:

  • czy ktos inny (lub Ty za kilkanascie miesiecy) zorientuje sie w hakach, zastosowanych w programie na tyle, by zmieniajac cos nie spowodowac bledow;
  • czy rozbudowanie programu z takim rozwiazaniem nie bedzie wymagalo przebudowy takiego rozwiazania w wiekszym stopniu niz to konieczne.

Zatem pytanie twoje o cel i srodki jest troche niepotrzebnie zadane. Rozwiazania sa uwazane za "pro", bo sa szybkie, eleganckie, intuicyjne, latwe do poprawy i rozbudowy, a czesto sa po prostu standardowymi metodami realizacji zagadnienia.

0

Zgadzam się ze szczawikiem... jeśli w danej sytuacji masz wystarczające dane (Sender, który wywołuje okno etc.) to nie należy dodawać informacji, które je dublują.

Ale to w sytuacji gdy masz zestaw rozwiązań i możesz swobodnie wybrać. Co w sytuacji, gdy wpadłeś na tylko jeden sposób? I wydaje ci się "prymitywny"? Ja uważam, że głównym celem jest rozwiązanie problemu. Więc sam musisz wiedzieć co bardziej Ci się opłaca? Zaimplementować w 10min prymitywne rozwiązanie i ewentualnie potem zmagać się z konsekwencjami? Czy szukać trzy dni rozwiązania (wymyślać, googlować, pytać na forum ;)) i znaleźć odpowiednie rozwiązanie?

Jeśli potrafisz w takiej sytuacji wybrać dobrze to jesteś pro. Z tego wniosek, że samo stosowanie "bajeranckich" rozwiązań nie zrobi z Ciebie profesjonalisty. Odpowiednie doświadczenie i nauka na własnych błędach- już prędzej.

1 użytkowników online, w tym zalogowanych: 0, gości: 1