Ciekawe czy piszesz tak dlatego, że faktycznie projekt ze zmiennymi globalnymi jest dla ciebie trudny do utrzymania, czy dlatego, że tak się utarło, że zmienne globalne to zło i koniec. Mam nadzieję, że to pierwsze. :]
Nigdy nie piszę czegoś, bo tak wypada ;) Jak tak piszę, to uważam :)
No to witaj w klubie. Ale ale — jeśli projekt jest mały, okienek kilka, to i można śmiało korzystać z automatu.
Oczywiście, kwestia w jakiej skali działamy :)
Brzmi jak God Object. Nie żebym mial coś przeciwko, ale… :D
Bo to jest swego rodzaju God Object :D Ale, coś musi wykonać robotę polegającą na wczytaniu konfigów, połączeniu z bazą danych, wyświetleniem okien ewentualnych błędów, czy też zalogowaniem użytkownika. Po poprawnym logowaniu uruchamia niezbędne moduły. Chociaż z drugiej strony taki VCL też ma podobny obiekt inicjujący TApplication Tam zapewne jest jeszcze więcej roboty :)
Zależy od projektu. Ty piszesz w OOP, więc wstrzykiwania to pewnie korpo-norma (przerażają mnie te obiektowe cuda). Ja teraz robię w proceduralnym i jeśli potrzebuję, to deklaruję zmienne lokalne w sekcji implementation (lokalne dla modułu) i daję do nich publiczny, inline'owany getter (plus opcjonalnie setter). Czyli w sumie nie używam zmiennych globalnych w ogóle.
Nie jest to takie czyste OOP z interfejsami ko którym wszystko dziedziczy. Ot jest ok 40 modułów i jeden AppCore który to ma w sobie połączenie do bazy, ustawienia systemu typu format daty itp. Osobiście nie trawię Javy gdzie wszystko dziedziczy po wszystkim i czasami ciężko jest dość co do czego.
Czemu? Zarówno w Pascalach jak i w C/C++ zachowanie w takim przypadku jest zdefinowane — wygrywa ta o mniejszym zasięgu. Najpierw poziom osadzenia (C/C++ lub nowe Delphi), potem zmienna lokalna, potem zmienna lokalna/globalna w module, potem zmienne globalne z innych modułów, wedle ich kolejności w uses.
Na początku, jak jeszcze używałem globali zdarzało mi się pomylić zmienną globalną z lokalną i wtedy była zabawa. Wiadomo, że wygrywa zmienna o mniejszym zasięgu, ale to jest kolejna zasada jaką należy pamiętać, a chciałbym idealnie mieć wyeliminowaną potrzebę pamiętania takich rzeczy. Po prostu nie wierzę sam sobie i eliminuję wszelkie wektory pomyłek.
Nie mam na myśli zmiennej lokalnej dla funkcji wątku (bo każdy wątek miałby własną), a sytuację, w której dana funkcja tworzy i odpala wątki, które modyfikują zmienną lokalną funkcji wywołującej. Wtedy ta funkcja czeka aż wątku zakończą działanie i coś z tą zmienną lokalną dalej robi. Czyli de facto wątki modyfikują dane zmiennej w ramce stosu, nie w obrazie procesu.
Ok, to wtedy racja. Wtedy jednak to funkcja wywołująca ma za zadanie czekać i odpowiednio zarządzać zmienną. Chyba, że owa zmienna jest potrzebna również w innych wątkach. Wtedy robi się bardziej skomplikowanie.
Dziękuję za merytoryczne wypowiedzi! O to mi chodziło, żeby zainicjować dyskusję. Przecież właśnie dzięki forum i ludziom, którzy coś w życiu widzieli i napisali jakiś kawałek kodu, mniej zaawansowani, (tudzież amatorzy) mogą się coś nauczyć, zacząć stosować jakieś sensowne praktyki lub po prostu tworzyć lepszej jakości kod.
Dokładnie też tak myślę, zawsze warto poczytać co inni mają do powiedzenia na dany temat.
Jako amator, zasadniczo nie stosuję się do tych twierdzeń (proszę mnie jako takiego traktować - mimo, że w mojej opinii napisałem kilka super fajnych i przydatnych programów).
Jak tworzę program, to korzystam z formularzy - nie tworzę ich dynamicznie, bo po co (chyba że jest to konieczne, co czasem się zdarza). Zazwyczaj jednak, środowisko (IDE) załatwia za mnie "problemy" tworzenia okna i tysiące innych, o których nawet nie wiem, dzięki "automatowi". To dzięki RAD tworzenie aplikacji jest tak proste... przypomnę, że dobrych kilka lat temu, trzeba było korzystać z WinAPI, co myślę na pierwszy rzut oka odrzucało każdego - składnia skomplikowana, dziwne nazwy, wszystko trzeba było pisać samemu... a teraz? Niebo a ziemia. Nakładanie na siebie kagańca i szukanie trudnych i pracochłonnych rozwiązań jest bezsensowne. Wystarczy z głową korzystać z rozwiązań, które oferuje środowisko... Ale z drugiej strony, nie jest tak, że człowiek nawali formatek, cały kod pisany w zdarzeniach kontrolek, bez składu i ładu... może tak się robi pod presją czasu w korpo, ale jak ktoś koduje dla siebie to wydaje mi się, że dba o to co pisze - jeśli tylko wie co robi. Z pewnością nie jest to kod książkowy, ale działa i wbrew opinii niektórych, można go rozwijać.
Tak, tak samo jak nikt nie pisze już w assemblerze, tylko w językach wyższego poziomu. Co prawda sam zaczynałem od WinAPI i doskonale wiem jaką robotę odwala za nas każda biblioteka typu VCL, Qt czy też .Net Nie wyobrażam sobie pisać coś w WinAPI więcej niż proste crackme...
Żeby nie było, że jestem idealny. Jednak sam też popełniam od czasu do czasu program gdzie wszystko leży na formatkach i IDE tworzy za mnie wszystko. Z reguły są to proste narzędzia wspomagające pracę wdrożeniowców systemu, a i popełniłem tak kilka prostych programów pomocniczych na zasadzie raz zakoduj, zainstaluj, użytkownik używa tego już 8 lat bez żadnej zmiany :)
Tak samo, nie boję się użyć zmiennych globalnych, bo wiem co robię, odpowiednio je nazywam i nie ma opcji, żebym spowodował problemy. Przypominam - nie piszę bardzo dużych i skomplikowanych projektów. Pewnie takowe wymuszają inne podejście (z tym nie będę polemizował - duży projekt, skalowalny to inna bajka) - być może warto użyć innego narzędzia, a nie psioczyć na RAD. Poza tym, zmienne globalne (jak już przy nich jesteśmy) istnieją nie po to, żeby istnieć tylko żeby ich używać.
O ile wiesz co robisz, to jak najbardziej. Jeśli się samemu trzyma jakiejś konwencji to bardzo dobrze. Nawet jeśli jest ona dziwaczna. Ważne, aby robić to konsekwentnie. Przypomina mi się tu jednak dyskusja na temat goto która też wywołuje zażarte dyskusje.
