2009-10-29 14 views
6

Przeczytałem w różnych miejscach, że posiadanie zmiennych o zasięgu globalnym, tj. Publicznej klasy statycznej ze statycznymi elementami, jest uważane za sprzeczne z filozofią OO i nie jest dobrym projektem. (Na przykład, widziałem komentarze na następującej zasadzie: "Jeśli używasz globalnego, nie robisz tego dobrze." Albo słowa w tym znaczeniu.)Zmienne globalne v Ustawienia w C#

Ale jeśli użyjesz mechanizmu Ustawienia dostarczonego przez Visual Studio, np "Settings.Default.MySetting" itd. Jest dostępna globalnie w całej aplikacji, więc jak to się różni od korzystania z publicznej klasy statycznej?

Te same wyniki można osiągnąć za pomocą pojedynczego obiektu, ale to także prowokuje różne opinie.

Zmienne globalne są po prostu użyteczne, (moduł VB, ktoś?), Ale staram się nauczyć, jak to zrobić, OO malarky właściwie, więc jeśli globalne zmienne zapachu źle z punktu widzenia OO, co jest alternatywą?

Jestem szczególnie zainteresowany opiniami ludzi na temat korzystania z funkcji "Ustawienia". Czy uważa się to za dobry projekt OO?

Dziękuję za wszelkie uwagi.

Odpowiedz

14

Metody statyczne i inni członkowie nie są złymi praktykami. Po prostu ludzie mniej zaznajomieni z koncepcjami OO mają tendencję do zaśmiecania swojego kodu statycznymi metodami, własnościami i polami wszędzie, nie zdając sobie sprawy z tego, jakie są konsekwencje.

Ogólnie rzecz biorąc, takie ustawienia konfiguracji, klasy pomocnicze i narzędzia, abstrakcyjne fabryki, singletony itp., Posiadanie statycznych elementów jest całkowicie dopuszczalne.

1

Publiczna klasa statyczna lub członek nie zawsze jest złym pomysłem (nawet jeśli nie jest idealnie OO). Wiele dobrych projektów OO korzysta z publicznych statycznych elementów takich jak Loggers lub Settings (jak zauważyłeś). Dobrym przykładem tego, jak to zrobić w sposób OO jest Static Gateway.

1

Zmienne globalne, takie jak goto, są czymś, czego powinni unikać wszyscy początkujący, ale są niezwykle przydatni dla zaawansowanych programistów.

Powiedziałbym, że jeśli nie czujesz się pewnie i nie masz konkretnego, uzasadnionego powodu, dla którego jest to dobre zastosowanie, nie używaj ich. Mistrz OO przed powrotem do zmiennych globalnych.

0

Ustawienia mechanizm ... hmm ...

patrzę na tych, głównie w ramach środowiska. Podobnie jak system operacyjny lub czas, ale dla aplikacji. Nie są to tak naprawdę "zmienne", które zadeklarowałbyś podczas INIT.

Jednak można owinąć obiekt wokół nich i uzyskać do nich dostęp tylko za pośrednictwem tego obiektu, zamiast czytać je, gdy były potrzebne w czasie wykonywania. Nie testowałem tego, ale prawdopodobnie jest to mycie wydajności (lub negatywne w stosunku do czytania ich w stanie surowym, jeśli nie wykonujesz dobrego zarządzania pamięcią).

W końcu, w miarę dojrzewania aplikacji, takie rzeczy w końcu powodują, że obiekty wokół nich są owinięte. Moją zasadą jest, gdy zaczynam myśleć: "Nah, to zbyt proste, zbyt atomowe i nie wymagające przedmiotu ..." to moja wskazówka, aby uczynić z tego obiekt.

2

W języku C# będziesz mieć problemy z dobrym designem OO, ponieważ nie możesz uciec od OO. To nie jest tak, jak w C++, w którym można łączyć ze strukturą z programowaniem OO - dziedziną, w której często występują tego typu argumenty. Członkowie statyczni w klasie są OO. Ustawienia wygenerowane przez Microsoft są generowane, ponieważ generowanie kodu tworzy dla nich enkapsulację OO lub co najmniej "kontener obiektów" wokół nich. Więc nigdy nie są zmiennymi globalnymi, ponieważ nie istnieją w języku C# - są po prostu statycznymi elementami na klasach - nic tam nie ma OO.

Jeśli argument dotyczy pojedynczego kontra członu statycznego, to przyjmuje on jedną argument OO przeciwko innemu argumentowi OO.

Następnie zawsze jest filozoficzny punkt widzenia a praktyczny punkt widzenia. W większości królestw idealny filozoficzny punkt widzenia nie jest opłacalny sam, z wyjątkiem studiów akademickich. Prawdziwy świat potrzebuje prawdziwych rozwiązań, mieszanych rozwiązań.

+2

Trudny czas? Tak. Czy trudno będzie powstrzymać zdeterminowanego, niekompetentnego dewelopera? Nigdy. Straciłem liczbę razy, gdy widziałem coś zrealizowanego w sposób, który jest zarówno trudniejszy, jak i mniej poprawny niż projektowany sposób. (I kłamałbym, gdybym powiedział, że nigdy nie byłbym winien takiej rzeczy.) –

+0

Dobra sprawa, Greg D. Powinieneś zobaczyć część mojego przeszłego snafu! –