Mam w swoim programie parę różnych klas i w każdej wykorzystuję ta samą stałą liczbową. Chciałabym zamiast w każdej deklarować ją oddzielnie stworzyć nową klasę w której byłaby tylko ta stała, tak żeby zmieniać jej wartość w jednym miejscu w razie potrzeby. Jak to wygląda z technicznego punktu widzenia? Czy takie rozwiązanie jest praktykowane, aby tworzyć klasę zawierającą tylko jedną zmienną? I jakie modyfikatory powinna posiadać ta klasa i zmienna?
Jestem dość początkująca w temacie więc proszę o wyrozumiałość:)
0
0
Hej
Rozwiązania są takie jakich potrzebujesz, teoretycznie :)
A tak poważnie to zrób sobie klasę i w niej pole statyczne i odwołujesz się do tego pola poprzez nazwę klasy czyli: NazwaKlasy.ZmiennaStatyczna. Idąc dalej dobrze by było zrobić enkapsulację tej zmiennej czyli zrobić "get" i "set", np.:
public static int GetZmienna()
{
return zmienna;
}
public static void SetZmienna(int x)
{
zmienna = x;
}
Pozdrawiam
0
Tak, jak najbardziej mozna:
public static MojaKlasaZeStalymi // <--- STATIC, zeby nikogo nie korcilo robic "new MojaKlasaZeStalymi()"
{
public const int MOJA_STALA_LICZBA = 5;
public const string MOJA_STALA_SCIEZKA = @"C:\blah\bum.dat";
}
Tak, jest praktykowane, bo skoro i tak masz w N klasach X powtorzonych stalych, to wylaczenie tego do jednej wspolnej wyczysci Ci troche kod.
Dodatkowo, jak juz to upakujesz w static-klase, mozesz kiedys w przyszlosci to szybko przerobic na klase nie-static, nazwac 'konfiguracja' i zaczac te ustawienia przelaczac/pobierac/zapisywac na dysk itede
0
Możesz utworzyć osobny plik z klasą, np. Constants.cs, w której zdefiniujesz osobną przestrzeń nazw dla klasy i klasę ze stałymi:
using System;
namespace MojProgram.Constants
{
public static class Constants
{
public string ConnectionString = @"...";
}
}
Tak jak w poście quetz'a
I chcąc użyć tej klasy to wiesz już jak:
using MojProgram.Constants;
...
var connStr = Constants.ConnectionString;
...
0
Dziękuje wszystkim za odpowiedzi:) Będę tu chyba częściej zaglądała i Was gnębiła "łatwymi" pytaniami;)
0
JA bym powiedzial ze zlaeznie od tego czego potrzebujesz, bo zawsze mozesz to zrobic tak:
public abstract class ParentClass{
protected ParentCLass(){
ConnectionString = "MyConnectionString";
}
protected String ConnectionString { get; private set;}
}
Pozdrawiam.
0
@Assassin o_O
jaki ta klasa ma sens?
raz ze potrzebujesz miec klase dziedziczaca (bo dwa)
dwa potrzebujesz stworzyc instancje tej klasy
trzy wlasciwosc ConnectionString jest protected wiec w innej klasie i tak jej nie odczytasz
:)
0
- Enkapsulacja i wspoldzielenie zmiennej
- Taka zmienna moze byc zalezna od konfiguracji
- Rownie dobrze zamiast statycznej klasy mozna uzyc ConfigurationManager.AppSetting.
ad 1) Masz racje nie zawsze mozna jej uzyc ale podalem to jako alternatywe a nie jedyne prawdziwe rozwiazaniue
ad 2) nawet nie mozesz stworzyc jej instancji bo jest abstract ;) wiec musisz dziedziczyc
ad 3) jak juz dziedziczysz to masz dostep, dlatego jest protected.
Sporo zalezy od warunkow i tego co potrzeba
Pozdrawiam
0
Nie twierdze ze mam racje ale:
ad 2) "jest zle" i "powinies uzyc" nic nie znaczy, chyba ze masz jakis argument za tym? Bo twoj static wyglada jak opakowanie zmiennych globalnych ktore takze sa zle, wiec co go czynni tym dobrym/lepszy? Moze po prostu czego nie rozumiem lub nie widze?
ad 3) calkiem ciekawy ten SOLID, dziekuje za linka. Ale przeczytalem LSP i nie ma tam nic przeciwko takiemu uzycu klasy bazowej. Bo o ile zrozumialem LSP to chodzi o to aby metoda ktora uzywa klasy A byla w stanie takze uzyc obiekty klasy B jesli B jest podtypem A. Czyli w przykladzie ktory podalem bedize to mozliwe.
Co do takiego uzycia dziedziczenia zgadzma sie ze sa lepsze metody. Singeloton albo ConfigurationManager, ale wydaje mi sie ze sa tez przyklady kiedy klasa bazowa moze udostepniac taka klasa.
Co do mojego przykladu( po kolejmym przeczytaniu tematu) moge dodac ze klasa powinna byc internal co by nic poza assembly nie moglo jej dostac.
Pozdrawiam.
0
3 i po trochu 2) argument brzmi: wykorzystanie abstract+protected jak proponujesz burzy loose coupling oraz wymusza aby klasy chcace uzyc konfoguracji sztucznie dziedziczyly, co samo w sobie jest niedobre, gdyz albo wymusza sie w ten sposob narzucenie tym klasom pewnych dodatkowych obowiazkow aby byly w zgodzie z LSP, albo tez - łamie się LSP. Poprzez sztuczne narzucenie klasy bazowej, w jezykach typu C# albo Java ktore nie zezwalaja na multipleinheritance, jednoczesnie zamykasz programiscie/designerowi dowolnosc w projektowaniu swojej hierarchii klas i co gorsza - nie pozwalasz im uzyc wlasnej, czesto o wiele odpowiedniejszej dla nich klasy bazowej. IMHO, wystarczy zeby to okreslic co najmniej "w ogolnosci zlym pomyslem". stad, "powinienes uzyc" nie "musisz uzyc". W C++ i innych pozwalajacych na multipleinheritance i/lub mixiny - czemu nie, moze byc, acz w kontekscie LSP i tak taki mixin z configuracja wygladalby dziwnie: LSP po prostu nie trawi "mixin"ów, sa one czystym reużyciem kodu/struktury poprzez dziedziczenie, co jest uwazane za 'evil', ale coz, z racji prostoty tez sie tego uzywa. ale tam gdzie MI jest dozwolone!
@static vs globalne vs object -- nawiazujac do "mojego static wygladajacego jak globalne" -- calkowicie sie zgadzam sie, tym przeciez dokladnie sa static classes/methods/static fields/properties - po prostu globalnymi zatrzasnietymi w ramach klasy dla minimum porzadku. Jest to niedobra praktyka, powinno sie rezygnowac z niej jak najszybciej. Natomiast w przypadku malych rozmiarow kodu calkowicie wystarczajaca, banalnie prosta i i tak o wiele lepsza niz wklejanie stalych od ktorego zaczal autor wątku. W dodatku staticclasses są o wiele prostsze w stworzeniu/uzyciu/napisaniu - wystarczy przeniesc linie i dopisac static/const. Minus jest jeden - ich tresc jest zawsze publiczna, chyba ze umiescisz je jako nonpublic innerclass w czyms, dzieki czemu uzyskasz niejawnosc dla klas innych niz podklasy tej ktore je obejmuje - acz i tak jest nie za dobrze, gdyz co prawda nie wymuszasz wtedy dziedziczenia po klasie "abstract konfiguracjaBase" ale wymuszasz dziedziczenie po klasie X ktora zawiera "nonpublic static innerclass Konfiguracja", praktycznie wychodzi wiec na jedno i to samo, wniosek zostaje ze albo ladne drzewo dziedziczenia, albo niepubliczna tresc.
Wspominajac juz o nim, singleton ma w tym konkretnym w przypadku (stałe const) kompletnie zerowe zyski wzgledem w/w staticclass. jesli pola bylyby bardziej skomplikowane, nie-const, i wymagalyby jakies, zwlaszcza uszeregowanej, inicjalizacji - to pewnie ze lepiej uzyc singletona. ale tutaj? const nie wymagaja inicjalizacji w ogole, wiec sens singletona traci moc. mozna go co najwyzej uzyc dla wprawki albo aby byc o kolejny krok blizej dao dla cfg i managera - lub na przyszlosc, jesli programista/projektant sadzi ze konfiguracji bedzie o wiele wiecej
edit: sorry za dwa i pół kilo tekstu, pisalem jak lecialo:)