[C#] Odwołanie do zmiennej - alias ??

Witam,
Czy w C# (Visual) można zdefiniować alias / odwołanie do zmiennej - nie wiem jak to poprawnie nazwać, więc może opiszę na przykładzie ;)

Mam dwie klasy w dwóch modułach /kod we fragmentach/:
Moduł 1:

using System;
using System.Collections.Generic;
using System.Text;

namespace ETL
{
    class Program
    {
          public static string zmienna_globalna;       //zmienna do której chcę mieć dostęp wszędzie
          
          static void Main(string[] args)
          {
                zmienna_globalna = "Ala ma kota";
                ..................
          }
    }
}

i moduł 2:

using System;
using System.Collections.Generic;
using System.Text;

namespace ETL
{
    class Funkcje
    {          
          public static string zmien(string tekst)     //przykładowa funkcja gdzie chcę korzystać ze zmiennej globalnej
          {
             tekst = <b>zmienna_globalna</b> + "Ala ma też psa";
             return tekst;
          }
    }
}

Moduł 2 wygląda tak, jak chciałbym to uzyskać - niestety, fragment wytłuszczony zwróci błąd, bo muszę się odwołać do niego tak:

tekst = <b>Program.zmienna_globalna</b> + "Ala ma też psa";

Pytanie: co mam zrobić, żebym mógł się odwołać do zmiennej globalnej BEZ podawania klasy w której występuje??

Pozdrawiam,
Marcin

W C# nie ma zmiennych globalnych. Wszystko zaczyna się od nazwy klasy. Tak ci to przeszkadza [???]

Globalizacja w przypadku programowania obiektowego ssie ;) Zmien podejscie, jesli chcesz w pelni z korzystac jego mozliwosci. Ponawiam pytanie adf88 :)

Może i nie ma zmiennych globalnych, ale w niczym nie przeszkadza korzystać z czegoś do nich podobnego ;) Ot, choćby zdefiniować publiczną statyczną klasę zmienne_globalne i wrzucić do niej wszystkie parametry w programie, które chcemy traktować jako zmienne o globalnym zasięgu ;)))

Czy mi przeszkadza odwołanie się z nazwą klasy na początku?? Tylko tyle, że jest więcej pisania ;), a pomyślałem że skoro można zapisać:

Console.WriteLine

zamiast

System.Console.WriteLine

to można w podobny sposób używając Using... uprościć sobie życie ;)
Ale jak się nie da to trudno...

@MarcinC#: autorowi nie przeszkadza nazwa namespace'a tylko nazwa klasy.

Ot, choćby zdefiniować publiczną statyczną klasę zmienne_globalne i wrzucić do niej wszystkie parametry w programie, które chcemy traktować jako zmienne o globalnym zasięgu

I powrocic do wad programowania strukturalnego i ogolnego smietnika w globalnych. Pytanie po co? ;)

@adf88: MarcinC# to zdaje sie autor ;)

Nie rozumiem niechęci do zmiennych globalnych... Może kiedyś, ale jeszcze nie teraz ;)
Odpowiadając na pytanie johny_bravo: jak bez używania czegoś o globalnym zasięgu rozwiązać np. problem z połączeniem do bazy danych (inicjuję połączenie po otwarciu programu, chcę je zamknąć na końcu, a w trakcie korzystać z niego we wszystkich klasach), albo: przy zainicjowaniu programu chcę wczytać różne parametry z pliku z konfiguracją (np. ścieżki dostępu, preferencje użytkownika etc.), z których chcę później korzystać w różnych miejscach programu...
Mi najprościej wydaje się zdefiniować klasę z polami na wymagane parametry o zasięgu globalnym, przy otwarciu programu zainicjować ją danymi i korzystać z nich kiedy będzie taka potrzeba. Ale jestem otwarty na inne sugestie ;P

Są o wiele lepsze, nowsze metody na robienie takich rzeczy. Np. opakować klasę obsługi baz danych czy konfiguracji w interfejsy i Singleton czy bajery typu IoC.

MarcinC# napisał(a)

jak bez używania czegoś o globalnym zasięgu rozwiązać np. problem z połączeniem do bazy danych (inicjuję połączenie po otwarciu programu, chcę je zamknąć na końcu, a w trakcie korzystać z niego we wszystkich klasach), albo: przy zainicjowaniu programu chcę wczytać różne parametry z pliku z konfiguracją (np. ścieżki dostępu, preferencje użytkownika etc.), z których chcę później korzystać w różnych miejscach programu...

Najprościej - dobrym projektem.

Odpowiadając na pytanie johny_bravo: jak bez używania czegoś o globalnym zasięgu rozwiązać np. problem z połączeniem do bazy danych

Jak wspomniano - np. singletonem. Jak rowniez wspomnial @somekind: dobrym projektem. A laczac te dwie rzeczy zauwazysz, ze dobry DUZY projekt nie wymaga wiecej niz 3-4 singletonow. A i to czasem wygorowana liczba.

Czemu globalne zmienna ssa? W duzym projekcie ilosc zmiennych szlaby w tysiace. Po 100 stracilbys pomysly na unikalne i cos mowiace nazwy. Projekt z tysiacem zmiennych globalnych i nic nie mowiacych nazwach nie nadaje sie nawet do kosza. Nie wspominajac juz o tym, ze nie korzystasz z ZADNYCH zalet obiektowosci jak enkapsulacja (bo wszystkie dostepne publicznie) czy polimorfizm i dziedziczenie (bo statyczne), nie mowiac juz o abstracji (bo to tylko zamykanie zmiennych w pojemnik).

Acha - laczenie z baza mozna zalatwic przez pule polaczen, ktora w .net jest dostepna za darmo ;) Wtedy .net martwi sie o minimalizacje ilosci polaczen, Ty 'laczysz' sie do woli. I tak dalej. W ten sposob moze sie okazac, ze projekt nie wymaga zadnego singletona :)

Hmm... Nazwy Singleton czy IoC nic mi nie mówią, o interfejsach coś tam przeczytałem zapoznając się z językiem C#, ale używając Visual C# do tej pory nie natknąłem się na potrzebę ich stosowania :) Z "zalet" obiektowości nie korzystam - przynajmniej nie świadomie - bo nie potrzebuję ;) Nie pracuję nad jakimiś ogromnymi projektami gdzie każdy robi swoją część i nie wie co robią pozostali - piszę swoje programy od początku do końca, a jeżeli program DZIAŁA, jest zabezpieczony przed błędami użytkownika, podzielony na dobrze skomentowane i logiczne części, ma ładny interfejs graficzny - a jego użytkownicy są zadowoleni, to nie widzę potrzeby stosowania "dziwnych" mechanizmów których działania do końca nie rozumiem. Dla mnie podstawą jest napisać działający problem w zadanym terminie (zwykle: jak najszybszym) bo to interesuje mojego pracodawcę z za to mi płaci, a nie tworzyć trochę sztukę dla sztuki bo "tak się robi". ALe dziękuję za rady.
Pozdrawiam!

O mój boże, za to ci jeszcze płacą ? 8-O

Żałosne. Mając podstawy algorytmiki i inżynierii oprogramowania tworzyłbyś oprogramowanie zdecydowanie szybciej, nie pisałbyś bzdur o problemach nierozwiązywalnych w języku... Nie korzystasz z obiektowości w języku stricte obiektowym, może czas zmienić zawód? Tak się składa, że dobrze napisany kod sam siebie komentuje, odpowiednio dobrane nazwy i logiczny podział sprawiają, że od razu wiadomo o co chodzi.
W każdym sensownym projekcie GUI jest oddzielone od logiki aplikacji. Przy dobrej separacji powinno dać się podpiąć drukarkę wierszową zamiast interface'u 3D bez zmiany chociaż jednej linijki kodu, który za frontend nie odpowiada.

nie widzę potrzeby stosowania "dziwnych" mechanizmów których działania do końca nie rozumiem.

Może czas się nauczyć, zrozumieć? C# i stosowane w nim koncepcje i wzorce są proste jak budowa cepa (narzędzia, nie użytkownika), to nie jest cholera wie jak skomplikowany mechanizm. Wiesz, te 'mechanizmy, których nie rozumiesz' to jest właśnie programowanie, język to tylko narzędzie, nie ten to inny.
Fakt, po co się przejmować tworzeniem sensownego kodu, byle działało... i tak do emerytury co drugi projekt będziesz podobną mechanikę implementować bo poprzednia, jest cytując cepę, 'z d**y' i nawet do oglądania się nie nadaje... 'ale działa'. Jak widać rozwojem oprogramowania się nie zajmujesz, co więcej pojęcie ponownego wykorzystania kodu jest Ci obce.

Dla mnie podstawą jest napisać działający problem w zadanym terminie (zwykle: jak najszybszym) bo to interesuje mojego pracodawcę z za to mi płaci, a nie tworzyć trochę sztukę dla sztuki bo "tak się robi".

Istnieje pewien kompromis pomiędzy sztuką a realnym wypełnianiem potrzeb klienta. Wiesz jak najszybciej napisać program? Jak najmniej zaprojektować i naklepać. Żeby tak podejść do problemu to trzeba mieć możliwość wykorzystania poprzednio napisanego kodu, a ten bez faktycznie dobrej architektury będzie bezużyteczny.
Cóż, jaki pracodawca taki pracownik. Z jednym możemy się zgodzić, Ty faktycznie piszesz programy, bo nie programujesz.

@adf88, nie dość, że płacą to płacą na tyle dobrze, że stać go aby siedzieć cały czas na gprs-ie.

Żałosne to są komentarze co niektórych - widzę musicie się dowartościować kosztem innych, cóż... Macie swój punkt widzenia ale nie potraficie zrozumieć argumentów innych niż Wasze... Swoją drogą - zadałem w tym wątku KONKRETNE pytanie, a zamiast dostać konkretną odpowiedź - przerodził się on w dyskusję o "wielkości i nieomylności" jednych metod nad innymi. Skomentuję to krótko bo kończę ten temat - uważałem i będę uważał, że pisanie programów to nie tylko znajomość zaawansowanych elementów języka, ale też umiejętność kontaktów z ludźmi, określania ich potrzeb, rozumienie celu który chcą osiągnąć etc.
A sposób ich realizacji - mniej lub bardziej "elegancki" - jest drugorzędny tak długo, jak długo program spełnia swoją funkcjonalność w sposób zadowalający. Przykro mi że nie wszyscy to rozumieją ale cóż, nie moja sprawa. A teraz wracam do "pisania programów".

Takie pytanie trzeba było zadać w Newbie. C# nie ma zmiennych globalnych. Zresztą już to ktoś pewnie napisał, to jest konkretna odpowiedź. Namespace można włączyć, klasy nie... co wie nawet początkujący. Do składowych klasy musisz się przez klasę odwoływać. Drugą konkretną odpowiedzią było użycie singletonów, też ją otrzymałeś.

To Ty nie rozumiesz, że 'klepanie na odczep i zapomnij' jest dobre tylko przy hello-world. Przy realnym sofcie liczy się możliwość ponownego wykorzystania kodu przy kolejnym projekcie aby obniżyć koszty, skrócić czas rozwoju i zmniejszyć ilość błędów. Jak rozumiem po tym jak zadowolony z żywota konsument otrzyma wasz produkt to od razu go kasujecie? Późniejsza konserwacja kodu pisanego haxami może się okazać niemożliwa bez przepisania większej części softu, zawsze zaś będzie kosztowna. Wiesz kochany, po kilku dobrych projektach nowe na ich bazie tworzy się szybciej i taniej niż klepiąc na szybko i byle jak od postaw - czyli tak jak robisz.

Cóż, witamy w świecie polskiego oprogramowania - czyli The Daily WTF na żywo i w kolorze, świat gdzie 'poważne aplikacje' piszą głodni studenci za konserwy. Przypomina mi się jedna znana firma, której połowa aktualizacji softu to usuwanie jakiejś funkcjonalności i ponowne jej dodawanie za pół roku. Pewnie nie jeden programista wypowiadający się tutaj miał zaszczyt, bo o przyjemności nie może być mowy, poprawiać po takich 'pisaczach programów'. Od pierwszych chwil człowiek nabiera chęci wysłania kolegów aby zrobili z nim to samo co on zrobił z projektem.

A tak swoją drogą, w firmie zwykle programista nie zajmuje się kontaktami z ludźmi ani określaniem ich potrzeb.

MarcinC# napisał(a)

Żałosne to są komentarze co niektórych - widzę musicie się dowartościować kosztem innych, cóż...

patrzac po Twoich rozmowcach, wierz mi, ze nie musza.. moze nie wszystkie sa politycznie poprawne, ale tak to juz jest w internecie w czesci IT, ze objawy bezmozgowia zwykle sa natychmiast tepione. nie ma celu ocenianie ich.

MarcinC# napisał(a)

Macie swój punkt widzenia ale nie potraficie zrozumieć argumentów innych niż Wasze... Swoją drogą - zadałem w tym wątku KONKRETNE pytanie, a zamiast dostać konkretną odpowiedź - przerodził się on w dyskusję o "wielkości i nieomylności" jednych metod nad innymi. Skomentuję to krótko bo kończę ten temat - uważałem i będę uważał, że pisanie programów to nie tylko znajomość zaawansowanych elementów języka, ale też umiejętność kontaktów z ludźmi, określania ich potrzeb, rozumienie celu który chcą osiągnąć etc.

i dostales kilka konkretnych odpowiedzi. nie doczytales postow? co do dyskusji, patrz powyzej. Twoje podejscie zostalo uznane za niewlasciwe, stad reakcja. Nie dasz rady nikogo przekonac, ze Twoje podejscie jest ok --- poniewaz nad tymi sprawami myslalo juz wiele osob, takze zwacych sie naukowcami, socjologami, projectmanagerami, dyrektorami (..) i stworzylo cos, co zwie sie inzynieria oprogramowania, metodykami prowadzenia projektow, cyklami zycia projektow (..) slowem - teorie programowania, teorie informacji, oraz algorytmike. i szczerze mowiac, to co jak do tej pory napisales, w wiekszosci stoi z nimi w sprzecznosci. pytanie: myla sie setki ludzi przez dziesiatki (juz!) lat, czy jedna osoba ... ktora w dodatku widac ze nie zna jezyka ktorym sie posluguje. spojrz z tej strony, a moze zrozumiesz ostra reakcje forumowiczow - oni w znacznej czesci znaja i stosowali podejscie podobne do Twojego, oraz znaja i stosuja w/w teorie, i .... znaja wady/zalety obu.

MarcinC# napisał(a)

A sposób ich realizacji - mniej lub bardziej "elegancki" - jest drugorzędny tak długo, jak długo program spełnia swoją funkcjonalność w sposób zadowalający.

zgadza sie. to jest podstawowe prawo kazdej rzeczy ktora sie wykonuje. szkopul tkwi w slowie "zadowalajacy".. raz, ze musi spelniac wymagania uzytkownikow, dwa, ze musi, o dziwo, pozwalac Tobie na dalsza, sensowna prace nad nim. oczywiscie, mozna rzec, ze skoro zamawiajacy twierdzi ze masz pisac byle jak byle dzialalo i bylo tanio, ze nigdy nie bedziesz musial tego rozbudowywac ani poprawiac - to nie ma co sie szczypac i nie ma co tej drugiej kwestii brac pod uwage.. jest to jednak kopanie dolkow pod soba samym, klienci zazwyczaj szybko to odszczekuja i okazuje sie ze masz duzo jeszcze dodatkowych rzeczy do dodania. w tym momencie, jesli Twoj twor jest wiekszy niz kilkanascie klas (ew. paredziesiat funkcji) na krzyz, okazuje sie ze takie terminy jak 'elastycznosc', 'latwosc rozbudowy' czy 'koszt utrzymania kodu' okazuja sie niebanalne i Twoje 'praktyczne' podejscie przegrywa z 'teoriami'. um. wlasciewie.. nie przegrywa. w takim momencie, ono przychodzi zebrac do teorii po jakikolwiek ratunek. na Twoim miejscu radzilbym Ci potraktowac tutejsze ostre slowa jako ostrzezenia przed potencjalna katastrofa ktora sam sobie przygotowujesz..

Marcinie,

W C# wygodnie jest wykorzystać do tego co napisałeś wzorzec projektowy Singleton. Tutaj masz więcej informacji na jego temat:
http://www.yoda.arachsys.com/csharp/singleton.html

Generalnie wygląda to tak jak niżej. W sumie nie jest to zalecana wersja, ale jak nie używasz wielowątkowości to nie ma problemu. Wersje dla wielowątkowych aplikacji są na stronie wyżej:

public sealed class Singleton
{
    static Singleton instance=null;

    public string NazwaAplikacji;
    public string WersjaAplikacji;

    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            if (instance==null)
            {
                instance = new Singleton();
            }
            return instance;
        }
    }
}

Sigleton to po prostu klasa z jedną właściwością statyczną, która jest instancją tej klasy. Przez to masz pewność, że w całej aplikacji będzie występować tylko i wyłącznie jedna instancja tej klasy. W klasie umieszczasz swoje właściwości itd. np. NazwaAplikacji i WersjaAplikacji i odwołujesz się przez Singleton.Instance.NazwaAplikacji itp. Mam nadzieję że ten post będzie pomocny.

Dwa ostatnie posty są bardziej stonowane i pomocne albo uargumentowane, autorom dziękuję. Można?? Można!!
Po co od razu mieszać człowieka z błotem??
Oczywiście przeczytałem wszystkie odpowiedzi - podważałem natomiast kierunek w jakim zaczęła toczyć się dyskusja.
Oczywiście nie do końca zgadzam się ze stwierdzaniem jakoby programy które piszę były niefunkcjonalne czy trudne do modyfikacji, ponieważ jak pisałem stosuję w nich czytelny - jak dla mnie ale sądzę że i dla ewentualnych "innych" - podział logiczny, na funkcje, procedury, staram się dawać dużo komentarzy, przestrzegać wcięć w kodzie etc... Jeśli zachodzi potrzeba modyfikacji - bez specjalnego problemu jestem w stanie to zrobić...
Zgadzam się z argumentem że pewnie setki "tęgich głów" nad tym myślały, ale - o ile mi wiadomo - są też języki w których nacisk na tą całą "obiektowość" nie jest tak duży (np. PHP) a osoby w nich piszące jakoś z tego powodu larum nie podnoszą... Wiem że i zakres zastosowań PHP jest inny niż C#, ale to dowodzi tego że obiektowość nie zawsze jest ono wymagana.

W języku Polskim jest pewnie kilkaset tysięcy słów, ale podobno do codziennej komunikacji większości osób wystarczy 3-5 tysięcy. :)
Pozdrawiam

Marcin, piszesz, że twój dotychczasowy styl jest w porządku. A jaki masz punkt odniesienia ? Nie masz go wcale.
Jak poznasz w pełni programowanie obiektowe i inne bajery, to będziesz pluł sobie w brodę "ale ja idiotą byłem, że tkwiłem w tym średniowieczu ..."
Osobiście, jak dogłębnie poznałem programowanie obiektowe było to dla mnie olśnieniem, chyba największym krokiem naprzód w historii mojego hobby.
Do dziś uważam, że najlepsze co w naszej dziedzinie wymyślili to właśnie obiektowość. Tego mechanizmu nic nie przebije.

Co do PHP to akurat bardzo dobry anty-przykład dałeś, z kodu szybko robi się spaghetti, ciężko się go czyta, ciężko wprowadza się w nim modyfikacje.

Aha, jeszcze z nie wspomnianych dotychczas zalet programowania obiektowego, to ilość bug'ów która spada i łatwość ich znajdowania która rośnie.

adf88,

Nie rozumiem czemu się tak uparłeś żeby nawracać na "jedynie słuszną obiektowość".

Marcin,

Rzeczywiście, są przypadki kiedy obiektowość nie jest 'wygodna'. Zależy co się robi.

TomaszSmykowski napisał(a)

Nie rozumiem czemu się tak uparłeś żeby nawracać na "jedynie słuszną obiektowość".
Nie jedynie.

TomaszSmykowski napisał(a)

Rzeczywiście, są przypadki kiedy obiektowość nie jest 'wygodna'. Zależy co się robi.
Przytocz przykład ... coś się znajdzie na pewno, ale ciężko nie ? ;)

asdf88,

W stopce masz że piszesz programy w Pascalu. Powinieneś teraz splunąć przez ramię, odmówić 10 zdrowaśiek i wyprzeć się tego języka :-D

Tomku, nie twierdzę, że obiektowość jest lekiem na całe zło, jednak w mocno przeważającej ilość przypadków jest bardzo pomocna.

No to się zgadzamy. A tak BTW. obiektowość obiektowości nierówna. Te wszystkie kursiki obiektowości w Internecie to tylko czubek góry lodowej. Żeby poznać obiektowość dobrze to trzeba poczytać jakąś dobrą książkę na ten temat.

Nie no jedna książka to za mało. Przede wszystkim dużo praktyki potrzeba.

To co byś polecił do nauki obiektowości, rozszerzalności itd.?

MarcinC# napisał(a)

Zgadzam się z argumentem że pewnie setki "tęgich głów" nad tym myślały, ale - o ile mi wiadomo - są też języki w których nacisk na tą całą "obiektowość" nie jest tak duży (np. PHP) a osoby w nich piszące jakoś z tego powodu larum nie podnoszą...

Ja bardzo dobrze rozumiem, że strona-wizytówka wcale nie potrzebuje setek linii kodu, wzorców projektowych i innych rzeczy do działania, ale większe projekty w PHP owszem, korzystają z projektowania obiektowego, a jeżeli nie, to ich twórcy zmierzają w tym kierunku.

stosuję w nich czytelny - jak dla mnie ale sądzę że i dla ewentualnych "innych" - podział logiczny, na funkcje, procedury, staram się dawać dużo komentarzy, przestrzegać wcięć w kodzie etc

Nie czepiajac sie wiele, zeby nie bylo znowu obrazania sie na caly swiat - sprawdzales swoje podejrzenia? Na przyklad z innymi programistami? Wez pod uwage, ze jak ktos PIERWSZY raz widzi program na oczy, do tego jest tego wiecej niz 1000 linii kodu, to kazdy ma prawo sie na dzien dobry zgubic. Jakakolwiek pomoc w kierunku przejrzystosci jest wtedy wskazana. A doswiadczenie (moje) mowi, ze najbardziej jasny kod dla nas moze byc istna lamiglowka dla innej osoby niewtajemniczonej w temat.

Wydaje mi się że trochę nie słusznie zjechaliście gościa. Przecież większość zaczynała jak on. Ktoś zaczynał inaczej ? Każdy z was od razu tworzył projekty w pełni zgodne z filozofią obiektowości ?
Ktoś powiedział że przekona się kolo jak jest naprawdę jak zobaczy prawdziwy projekt - i to są święte słowa. Wtedy do niego dotrze po co to wszystko jest. Ale może jeszcze nie miał okazji, a może to 14 latek ...
To co mówi jest be, ale wystarczyła jedna wypowiedź żeby mu to przedstawić czarne na białym. Ja natomiast odniosłem wrażenie że jest to kłótnia dwóch osób o takim samym 'poziomie' - jedna twierdzi tak a druga inaczej i jest spór.

Pozdrawiam

b0bik napisał(a)

Ktoś powiedział że przekona się kolo jak jest naprawdę jak zobaczy prawdziwy projekt - i to są święte słowa. Wtedy do niego dotrze po co to wszystko jest. Ale może jeszcze nie miał okazji, a może to 14 latek ...

Wedle tego co napisał ma szefa, pracuje i rozwija komercyjne projekty...