Autor Wątek: Przesyłanie zmiennych pomiędzy dwoma okanmi  (Przeczytany 4587 razy)

Offline Xayan

  • Użytkownik

# Luty 27, 2011, 14:42:07
Hiho.

Uczę się C# i zdecydowałem się stworzyć program, który wymaga stworzenia kilku okien (czyli, w wypadku C#, form). Mam jednak problem: jak, pomiędzy tymi oknami, przekazywać zmienne?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Ajgor

  • Użytkownik

# Luty 27, 2011, 15:00:49
zaczynasz naukę i od razu dotykasz trudniejszej sprawy :)
Używasz do tego Delegatów. Poczytaj o Delegate.

Offline Frondeus

  • Użytkownik

# Luty 27, 2011, 15:16:29
ew klasa Parent dla obu ...

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Luty 27, 2011, 15:50:00
W jednym oknie definiujesz zmienną jako publiczna, np.:
public uint Zmienna;Jeśli drugie okno ma referencję do pierwszego, bo na przykład samo go stworzyło:
Form1 form = new Form1();
form.ShowDialog(this);
To może się odwołać do zmiennej z klasy tego okna:
uint KopiaZmiennej = form.Zmienna;
Chyba, że nie o to chodziło?...

Offline Ajgor

  • Użytkownik

# Luty 27, 2011, 15:54:54
Pierwsza zasada programowania obiektowego - nie definiujemy zmiennych jako publiczne.
Już lepiej napisać metodę publiczną, która odwołuje się do prywatnych zmiennych.

Offline FoToN

  • Użytkownik

# Luty 27, 2011, 16:11:47
@up A property to już w c# nie istnieje? :P

Offline menajev

  • Użytkownik
    • Karate Inowrocław

# Luty 27, 2011, 17:18:25
Pierwsza zasada programowania obiektowego - nie definiujemy zmiennych jako publiczne.
Czy to jest zapisane w konstytucji? Bo się trochę jak kryminalista poczułem.

Offline Ajgor

  • Użytkownik

# Luty 27, 2011, 17:43:20
Heh...
Gdyby istniała konstytucja programistów, to by było zapisane w preambule :) Publiczne zmienne mogą oznaczać na przykład zawieszanie komputera bez ostrzeżenia w czasie działania.
Ale nie martw się. Nikt nie przestrzega konstytucji, i jakość nikt nie ma z tego tytułu wyrzutów sumienia.

Offline DamorK

  • Użytkownik

# Luty 27, 2011, 17:50:58
Publiczne zmienne mogą oznaczać na przykład zawieszanie komputera bez ostrzeżenia w czasie działania.

Że co?

Offline Frondeus

  • Użytkownik

# Luty 27, 2011, 18:37:20
Heh...
Gdyby istniała konstytucja programistów, to by było zapisane w preambule :) Publiczne zmienne mogą oznaczać na przykład zawieszanie komputera bez ostrzeżenia w czasie działania.
Ale nie martw się. Nikt nie przestrzega konstytucji, i jakość nikt nie ma z tego tytułu wyrzutów sumienia.
O... czyli dlatego Windowsy sie zacinają! ha! OPP nie jest jedynym słusznym stylem :)

Offline Ajgor

  • Użytkownik

# Luty 27, 2011, 18:45:41
Przyczyn zawieszania windy moze byc wiele. Jedna z nich jest popelnainie bledow przez programistow. na przyklad przez definiowanie zmiennych jako publicznych, i pozniej wpisywanie do nich roznych wartosci w roznych miejscach programu. Wpisujesz w jednym miejscu, poizniej w drugim, odczytujesz jeszcze w innym, robi sie balagan i moze dojsc do zawieszenia.
Czy nie po to wymyślono enkapsulację, żeby uniknąć takich sytuacji?
« Ostatnia zmiana: Luty 27, 2011, 18:49:18 wysłana przez Ajgor »

Offline Kos

  • Użytkownik
    • kos.gd

# Luty 27, 2011, 20:51:51
Przyczyn zawieszania windy moze byc wiele. Jedna z nich jest popelnainie bledow przez programistow. na przyklad przez definiowanie zmiennych jako publicznych, i pozniej wpisywanie do nich roznych wartosci w roznych miejscach programu. Wpisujesz w jednym miejscu, poizniej w drugim, odczytujesz jeszcze w innym, robi sie balagan i moze dojsc do zawieszenia.
Czy nie po to wymyślono enkapsulację, żeby uniknąć takich sytuacji?

*facepalm*
Najgorsze wyjaśnienie ever. Srsly. Odeślij swojego nauczyciela OOP-u z walizkami i znajdź sobie nowego.


Enkapsulację (czyli też gettery i settery) wymyślono po to, by móc wprowadzić do kodu warstwę abstrakcji poprzez oddzielenie interfejsu obiektu (w tym dostęp do jego stanu) od implementacji - choćby po to, by móc później zmienić implementację nie ruszając interfejsu.

Jeśli sytuacja X cechuje się tym, że tej warstwy abstrakcji nie potrzeba, to olanie getterów i setterów nie jest błędem. Nic nie stoi na przeszkodzie, by jawną część stanu obiektu potraktować jako część jego interfejsu. Takie rozwiązanie ma swoje własne zalety i wady. Robione świadomie w żaden sposób nie czyni kodu Uniwersalnie Gorszym.


Offline Xayan

  • Użytkownik

# Luty 28, 2011, 22:07:18
Rozwiązałem sprawę bardzo fajnie, mianowicie zrobiłem coś takiego:

form2 = new Form2(this);
form2.Show();

public Form2(Form1 form1)
Ważne, że wszystko ładnie działa. Dobra, można zamknąć temat.

bs.mechanik

  • Gość
# Marzec 01, 2011, 14:39:22
Wpisujesz w jednym miejscu, poizniej w drugim, odczytujesz jeszcze w innym, robi sie balagan i moze dojsc do zawieszenia.
Czy nie po to wymyślono enkapsulację, żeby uniknąć takich sytuacji?

Tak, enkapsulacje stwrzono jako panaceum na zawieszajace sie programy.

Offline Dab

  • Redaktor
    • blog

# Marzec 04, 2011, 03:20:58
Cytuj
Tak, enkapsulacje stwrzono jako panaceum na zawieszajace sie programy.

Dzięki niej programy działają tak wolno, że nie zdążają się zawiesić. :)