Kezdőoldal » Számítástechnika » Programozás » C# -ban egy osztály elérése...

C# -ban egy osztály elérése az összes többi osztályból "public static" megkerülésével?

Figyelt kérdés

Az alap elképzelés az, hogy lenne egy konténer osztály, pl. Container néven, ami tartalmaz mindent. Ebbe kerülne az osztályokhoz tartozó Lista, és minden egyéb függvény, változó, amire szükség lehet, és ami nem konkrétan egy adott osztályhoz tartozik, hanem magában a konténer osztályban lenne megvalósítva. Úgy kell működnie mindennek, hogy A, B, C, stb. osztályokból el tudjam érni ezt a fő konténer osztályt, és a konténer osztály is hozzá tudjon férni bármelyik osztályhoz (ez a listákon keresztül történne). Tehát a lényeg, hogy ha valamilyen módosítást hajtok végre egyik osztályban, akkor az egyetlen darab konténer osztályban kerüljön szintén módosításra. Ily módon az öröklődés nem működőképes, mert az osztályok példányosításkor külön létrehozzák önmagukban a konténer osztály egy új példányát.

A mostani megoldásom az, hogy mint függőség, paraméterként átadom az adott osztályban minden egyes függvénynek a Container osztályt. Működni működik, ezzel meg tudom kerülni a statikus osztály, függvény, változó használatát. Tehát itt van egy egyszerű példa, értelme nincs, nyilván a valóságban ez összetettebb lenne, de most hirtelen így kell elképzelni:


class ClassA

{

public void Method1(Container cont)

{

cont.count++;

}


public void Method2(Container cont)

{

cont.count--;

}


public void UpdateAll(Container cont)

{

Method1(cont);

Method2(cont);

}

}


class ClassB

{

public void Method1(Container cont)

{

cont.count++;

}


public void Method2(Container cont)

{

cont.count--;

}


public void UpdateAll(Container cont)

{

Method1(cont);

Method2(cont);

}

}


class Container

{

List<ClassA> cA = new List<ClassA>();

List<ClassB> cB = new List<ClassB>();

public int count = 0;


public void Initialization()

{

cA.Add(new ClassA());

cA.Add(new ClassA());

cA.Add(new ClassA());

cA.Add(new ClassA());

cA.Add(new ClassA());


cB.Add(new ClassB());

cB.Add(new ClassB());

cB.Add(new ClassB());

}


public void Update()

{

for (int i = 0; i < cA.Count; i++)

{

cA[i].Method1(this);

}


for (int i = 0; i < cB.Count; i++)

{

cB[i].Method2(this);

}


Console.WriteLine("count:" + count);

}

}


class Program

{

static void Main(string[] args)

{

Container cont = new Container();

cont.Initialization();

cont.Update();

Console.ReadKey();

}

}


Ez így jónak is tűnik, de több függvény használatakor, mindegyikben külön meg kell adni a konténer osztályt mint függőség. Tehát mindig lesz egy darab kötelező függősége az osztályoknak. Itt gondoltam arra, hogy valami hasonló megoldás lenne jó, mint az öröklődés, csak hogy ne saját példányként működjön, hanem egy közösre hivatkozzon. Tehát úgy kell elképzelni, mintha minden osztályom örökölné ugyanazt a konténer osztályt, pontosabban annak egyetlen darab példányát. Létezik ilyen megoldás a "static" használata nélkül?



2021. szept. 12. 16:57
 1/3 anonim ***** válasza:
67%
Ha jól értelmezem amit írsz, szerintem az egyke tervmintára (singleton pattern) lesz itt szükséged. Mondjuk ahogy elképzelem, ahhoz kéne egy extra wrapper class, és oda átpakolni a listákat, de így hirtelen nem látok más megoldást (azon kívül, hogy egy az egyben máshogy futsz neki a problémamegoldásnak)
2021. szept. 12. 17:07
Hasznos számodra ez a válasz?
 2/3 anonim ***** válasza:
67%
Igen, namost egy úgy sz.r ahogy van. Egy osztály lényege, hogy valamilyen szempont alapján egységet alkot. Ha a,b,c,d stb osztály mindenhez hozzá kell férjenek mindenhol, akkor azok NEM külön osztályok, hanem egy. Ha nagyon fel akarod osztani több fájlba akkor simán használ partial class-t.
2021. szept. 12. 23:38
Hasznos számodra ez a válasz?
 3/3 A kérdező kommentje:

Köszönöm a válaszokat.

Éreztem, hogy nincs rá egyszerűbb megoldás, ami az én fejemmel kompatibilis (számomra egyszerű és átlátható), én is ezt a Singleton -t találtam még a kérdés előtt. Lényegében majd játékhoz kell (MonoGame framework -ben készülne), amit nyilván egyedül fejlesztenék, vagyis alapból csak én fogom látni a kódot. Mivel önszorgalomból kezdtem el a programozást tanulni, ez nekem mindig is probléma volt, vagyis, ösztönből inkább a struktúrált megoldás felé hajlottam, aminek az lett a vége, hogy minden osztálynak volt kötelezően egy statikus, globális Listája, ahogy az osztályban lévő összes függvény is statikus volt. Vagyis csak az osztály példányok adattagjai voltak nem statikusak, de publikusak. Aztán egy for ciklus bejárta az adott statikus Lista összes elemét (ami ciklus szintén egy statikus függvényben volt), és az adott indexű példányon elvégezte az összes frissítést, módosítást. Ebből következett, hogy nyomatékosan jelezték különböző fórumokon, hogy ez így nagyon nem jó megoldás (meg is értem utólag), meg hogy nem lehet unit tesztelni, stb, és hogy inkább dependency injection -el kéne az adatokat átszivárogtatni egyik helyről a másikra, meg hogy a kódot nem csak magamnak írom, hanem más programozónak is (bár utóbbit sosem terveztem).

A mostani megoldással teljesen meg van kerülve a statikusság, lényegében szinte ugyanazt kapom, mint a régi jól bevált statikus módszerrel, csak ide pluszban kell a konténer osztály, ami majd összefog mindent és mindenkit. A framework által legenerált fő „Game1” osztályban pedig csak létrejönne a konténer osztályból egy példány, amit egyszer inicializálnék, majd a Game1 Update függvényben meghívná a konténer osztály fő Update függvényét, a Draw osztályban meg ugyanúgy a konténer osztály Draw függvényét.

Az, hogy a konténer osztály pontosan miket tartalmazna önmagában direktben, vagy pedig ezek is külön osztályokban lennének megvalósítva, majd a konténer osztályban csak meghívva belőle egy-egy példány, az még időközben kiderül. Leegyszerűsítve, ha már valahol ömlesztett kódhalmaz generálódik, az ne az adott osztályt terhelje, hanem akkor legalább a saját osztályok önmagukban csak saját magukat definiálják, így tisztábbak is maradnak, és a konténer osztályt terhelje az a sok egyéb. Alapvetően a külön-külön osztályok önmagukban kell, hogy létezzenek, nem parciális osztályok.

Topológiailag így kell elképzelni a dolgokat (egyelőre):


[link]


A Container osztály pl. függne a Game1 -től olyan értelemben, hogy ott van megvalósítva a ContentManager, amit a framework biztosít a fő Game -n keresztül. Tehát a kis osztályok önmagukban kezelnék a saját kontentjüket (hang, textúra), de csak közvetetten a Container osztályon keresztül, mert utóbbi a Game1 osztálytól kapja meg a ContentManager példányát. Mindez tudom, hogy mások szerint rossz elképzelés, de nekem valamiért mindig is ez volt legátláthatóbb, és még mindig jobb, mint hogy minden "public static" legyen, amivel mindenki elérhet közvetlenül mindenkit. Mert bár most is látszólag ugyanezt teszem, csak itt már közvetett módon történnek a dolgok.

2021. szept. 20. 03:26

Kapcsolódó kérdések:





Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!