Tworzenie tablic obiektów/klass

0

Witam,

 
class Program
    {
        class osoba
        {
            public string imie;
            public string nazwisko;

            osoba()
            {
                this.imie = Convert.ToString(Console.ReadLine());
                this.nazwisko = Convert.ToString(Console.ReadLine());
            }
            public void wyswietl(int[] tablica)
            {
                for (int i = 0; i < tablica.Length; i++)
                    Console.WriteLine("Imie, Nazwisko: {0}", tablica[i]);
            }
            static void Main(string[] args)
            {
                // Jak sobie z tym poradzić? 

                string[] tablica = new string[5]; ???
                osoba member = new osoba(); ??? 
                tablica[0] = new osoba(); ??? 
                }
            }

Na obecną chwile nie wiem jak tworzyć tablicę, które posiada obiekty. Zamysł tego krótkiego programu było przećwiczenie wprowadzania obiektów do tablicy, problem tkwi w tym, ze stwarza mi to ogromne problemy.

Error: "Cannot implicitly convert type 'ConsoleApplication1.Program.osoba' to 'string'"

Jak się poprawnie tworzy tablice obiektów?
Czy można bez problemu zrobić to w pętli for?

1
 class Program
    {
        static void Main(string[] args)
        {
            List<Osoba> Osoby = new List<Osoba>();

            //siejemy danymi
            for (int i = 0; i < 10; i++)
            {
                var o = new Osoba
                            {
                                imie = i.ToString(),
                                nazwisko = "Nazwisko"
                            };
                Osoby.Add(o);
            }

            foreach (var osoba in Osoby)
            {
                Console.WriteLine(osoba.nazwisko + ", " +osoba.imie);
            }

            Console.Read();

        }
    }

    class Osoba
    {
        public string imie { get; set; }
        public string nazwisko { get; set; }
    } 
0
  string[] tablica = new string[5]; ???
                osoba member = new osoba(); ??? 
                tablica[0] = new osoba(); ???  

Najpierw tworzysz tablice w której będziesz trzymał obiekty typu string, a później próbujesz wsadzić do niej obiekty typu Osoba.. no to nic dziwnego że masz błąd :)

Zastanów się przez chwile co piszesz i przeczytaj jeszcze raz książkę czy z czego się tam uczysz (ewentualnie kup sobie książkę).

0
 
class osoba
        {
            public string imie;
            public string nazwisko;
            public int wiek;

            osoba()
            {
                Console.Write("Imie:");
                this.imie = Convert.ToString(Console.ReadLine());
                Console.Write("Nazwisko:");
                this.nazwisko = Convert.ToString(Console.ReadLine());
                Console.Write("Wiek");
                this.wiek = Convert.ToInt32(Console.ReadLine());
            }

            public void wyswietl()
            {
                Console.WriteLine("{0}, {1}, {2}", imie, nazwisko, wiek);
            }
            static void Main(string[] args)
            {
                osoba[] tablica = new osoba[3];
                for (int i = 0; i < tablica.Length; i++)
                {
                    tablica[i] = new osoba();
                }

                for (int i = 0; i < tablica.Length; i++)
                    tablica[i].wyswietl();
                Console.ReadKey();
            }

Poradziłem sobie.. dzięki.

0

Nie, nie poradziłeś sobie tylko stworzyłeś koszmarka.

  1. Po co metoda Main w klasie osoba?
  2. Dlaczego w konstruktorze piszesz i pobierasz dane z konsoli? Wiesz do czego w ogóle służą konstruktory?
2

@ne0

Czemu nie tak:

		var persons = Enumerable.Range(0, 10).Select(i => new Person {
			FirstName = i.ToString(),
			LastName = "Nazwisko"
		}).ToList();
		persons.ForEach(Console.WriteLine);
1

I po co chcesz wyświetlać "ConsoleApplication.Person" dziesięciokrotnie?

2

@only, nie zadawaj w komentarzach pytań dotyczących swojego wątku. Komentarze są do prowadzenia dyskusji poza tematem.

Odnoszę się do Twojego komentarza:

  1. Jeżeli rozumiem, nie powinno się tak robić, tylko dwa osobne projekty? Jeżeli o to chodzi, to wersja Visual Studio którą posiadam, nie pozwala na otwieranie dwóch projektów równocześnie.

Nie dwa projekty, tylko dwie klasy. Klasa Program z metodą Main (tak, jaka jest domyślnie), natomiast kod swojej nowej klasy Osoba umieść w oddzielnym pliku, i nie umieszczaj tam metody Main.

  1. Na obecnej fazie, konstruktor rozumiem jako "metoda" która wykona się automatycznie przy tworzeniu obiektu (jego wywołaniu).

Tak, dobrze to rozumiesz. Ale konstruktor ma się wykonać od początku do końca automatycznie, bez żadnej integracji z użytkownikiem, czytania z pliku, bazy danych, itd.

Jeśli chcesz pobrać od użytkownika dane potrzebne do stworzenia obiektu, zrób to na razie w metodzie Main, przypisz je do jakichś zmiennych, a potem te zmienne przekaż do konstruktora klasy Osoba, aby ustawił odpowiednie pola. Tak będzie dużo lepiej i czytelniej.

2

@only

Niestety, obecnie na zajęciach jesteśmy na innym etapie niż kolega zaprezentował, mało co rozumiem z jego kodu.

A to bardzo proste, tylko pare zbednych rzeczownikow jest, ze wzgledu na obiektowosc jezyka. Tlumaczy sie tak:

  1. wiersz Dla kazdego elementu z przedzialu <0;10) wykonaj funkcje podana w nawiasach, a rezultat umiesc w sekwencji, nastepnie ta sekwencje zamien na liste.
  2. wiersz Dla kazdego elementu z listy z poprzedniego punktu wykonaj funkcje Console.WriteLine

I po co chcesz wyświetlać "ConsoleApplication.Person" dziesięciokrotnie?

Zeby wyswietlic wynik poprzednich operacji.

2

@_13th_Dragon: akurat Ty jesteś osobą która nie powinna wypowiadać się na temat uczenia poczatkujących. Kod który podajesz dla poczatkujących w wielu firmach nie przeszedłby code review...

Jedną sprawą jest podsuwanie komuś dobrych, alternatywnych rozwiązan które zawierają "nowe" konstrukcje/elementy, a drugą sprawą jest zasypywanie kogoś nowościami (List<T>, delegaty, operator lambda, LINQ) tylko po to żeby napisać kod który nie jest krótszy, jest mniej elastyczny, nie kompiluje się i zawiera buga. :)

0
dlaczegotak napisał(a):

@_13th_Dragon: akurat Ty jesteś osobą która nie powinna wypowiadać się na temat uczenia poczatkujących. Kod który podajesz dla poczatkujących w wielu firmach nie przeszedłby code review...
W jak wielu firmach pracowałeś? O którym kodzie konkretnie mówisz?

0

@_13th_Dragon: zależy co rozumiesz przez wiele, a konkretnego kodu nie będę przytaczał, bo temat zmieni się we flame. Wiem, że komentarz podobny do mojego pojawiały się wielokrotnie. :P

@n0name_l: chyba nigdzie się nie skompiluje, a błędem jest to, że dziesięciokrotnie wyświetlasz nazwę typu zamiast imienia i nazwiska.

Error 1 A namespace cannot directly contain members such as fields or methods C:\Users\x\documents\visual studio 2013\Projects\ConsoleApplication24\Program.cs 1 9 ConsoleApplication24
Error 2 Expected class, delegate, enum, interface, or struct C:\Users\x\documents\visual studio 2013\Projects\ConsoleApplication24\Program.cs 1 63 ConsoleApplication24

Ponadto czy możesz pokazać kod który zapyta użytkownika o imię/wiek ("Podaj imię:", "Podaj wiek:") i następnie wczyta dane z konsoli, a na koniec wyświetli gotową tablicę/listę w konsoli? Poniżej wklejam swoje rozwiązanie:

using System;

class Program
{
    static void Main(string[] args)
    {
        Person[] persons = new Person[3];
        for (int i = 0; i < persons.Length; i++)
        {
            var p = new Person();
            Console.Write("Podaj imię: ");
            p.Name = Console.ReadLine();
            Console.Write("Podaj swój wiek: ");
            p.Age = int.Parse(Console.ReadLine());
            persons[i] = p;
        }

        for (int i = 0; i < persons.Length; i++)
            Console.WriteLine("persons[{0}] ma na imię {1} i ma {2} lat.", i, persons[i].Name, persons[i].Age);
        Console.ReadLine();
    }
}

class Person
{
    public string Name;
    public int Age;
}
2

chyba nigdzie się nie skompiluje, a błędem jest to, że dziesięciokrotnie wyświetlasz nazwę typu zamiast imienia i nazwiska.

Rozumiem, w takim razie polecalbym zaprzestac tobie wypowiadania sie w jakimkolwiek dziale technicznym do czasu nabycia umiejetnosci aplikowania czyjegos kodu w programie. Reszty co wypisales nie ma sensu nawet komentowac, bo chyba nie wiesz co znacza te przymiotniki, ktore uzyles.

3

Reszty co wypisales nie ma sensu nawet komentowac

Oczywiście, bo wiesz że kod który napisałeś jest nieelastyczny i nie da się go zmienić żeby wykonać powyższe zadanie. Rozwiązanie które zaproponowałeś jest gorsze od tych które były podane przed Twoim:

  • jest bardziej skomplikowane
  • jest mniej elastyczne na zmiany

Jak przeczytam takie rozwiązanie w "prawdziwym" projekcie, to wiem że ktoś akurat się dowiedział o istnieniu LINQ. Uroczy drobiazg. :) Jednak dając takie rozwiązanie początkującemu możesz go przytłoczyć i powiedzieć w ten sposób "żeby rozwiązać ten problem potrzebujesz jeszcze poświęcić kilka godzin nauki". To tak jakbyś miał dziecko które ma zadanie zsumować 1+2+3+4+5+6+7+8+9, a Ty byś powiedział "skorzystaj z sumy ciągu arytmetycznego", czyli dziecku które raczkuje w dodawaniu mówisz "potrzebujesz jeszcze nauczyć się mnożenia i dzielenia żeby rozwiązać ten problem".

Oczywiście warto pokazać dzieciakowi, że można zauważyć, że można te liczby zapisać "sprytniej", zamiast sumować 1 2 3 4 5 6 7 8 9, można zrobić 1 9 2 8 3 7 4 6 5, co ułatwi zadanie. Ty natomiast usiadłeś koło dziecka które ma za zadanie zsumować 1+7 i powiedziałeś mu "użyj sumy ciągu arytmetycznego", można, tylko po co? :) Ani to łatwe, ani to sprytne.

0

nie da się go zmienić żeby wykonać powyższe zadanie.

Da sie, w gruncie rzeczy na kilka sposobow.

  1. Oddzielajac kompletnie interakcje z uzytkownikiem, wyciagniecie danych gdzies na zewnatrz i przekazanie ich w metode budujaca.
  2. Oddzielajac delikatnie poprzez jeszcze jedno wywolanie metody po drodze, zbudowanie tupli i wrzucenie tego w nastepny algorytm tworzenia obiektu.
  3. Mieszajac, przekazywac dane wpisane od uzytkownika bezposrednio w liscie inicjalizacyjnej.

Rozwiązanie które zaproponowałeś jest gorsze od tych które były podane przed Twoim:

Dla kogos kto wciaz go nie rozumie? Z pewnoscia.

Jak przeczytam takie rozwiązanie w "prawdziwym" projekcie, to wiem że ktoś akurat się dowiedział o istnieniu LINQ

Rozumiem, nazywa sie to srednia umiejetnosciowa, ktora z czasem jest wyrownywana do najslabszego osobnika z zespolu, w ktorym sie przebywa. Potem ciezko sie wyleczyc.

ednak dając takie rozwiązanie początkującemu możesz go przytłoczyć i powiedzieć w ten sposób

Jesli twierdzisz, ze moje zalozenie co do sprawnosci intelektualnej autora bylo bledne i powinien go traktowac jak idiote, odpowiem - nie umiem.

Natomiast wciaz jedyna nowoscia jest uzycie lambdy, ktora mozna wyrzucic.

Co do elastycznosci, na ktora sie tak czesto powolujesz a nie masz o niej pojecia, to:
#Moj algorytm nie wymusza znajomosci sposobu iteracji po kolekcji.
#Wszystkie czesci sa atomowe i moga byc reuzywane w osobnych miejscach, niezaleznie od rodzaju obiektow czy kolekcji agregujac.
#Kod wykonujacy iteracje jest sprawny i przetestowany przez dobre kilka lat.
#Sam algorytm jest oddzielony od interakcji z uzytkownikiem.
#Nie korzystam z zadnych wnetrznosci specyficznych dla danej kolekcji, nie wymagam indeksera czy dostepu do losowego elementu. Nie wymaga, zeby argumentem tego indeksera byl int. W gruncie rzeczy nic nie wymagam, tylko korzystam z abstrakcji dostarczonej przez MS.

Twoj kod natomiast uzywa prymitywnych rozwiazan rodem z C, ale nie przejmuj sie, kiedys zrozumiesz ile wnosi przekazywanie odpowiedzialnosci za iteracje do kolekcji, ktora ma wieksza wiedze o tym jak ja wykonac i jaka modularnosc i elastycznosc to powoduje. Zarowno w programowaniu rownoleglym, jak i 1-watkowym.

Jesli chcesz pokazywac zle metodyki kodzenia zaslaniajac sie pustymi frazesami, ktorych nie rozumiesz, to zycze powodzenia w przyszlosci.

2
		var persons = Enumerable.Range(0, 10).Select(i => new Person {
			FirstName = i.ToString(),
			LastName = "Nazwisko"
		}).ToList();
		persons.ForEach(Console.WriteLine);

Natomiast wciaz jedyna nowoscia jest uzycie lambdy, ktora mozna wyrzucic.

Szablony, delegaty, wyrażenie lambda czyli również uwiązanie zmiennej/leniwa ewaluacja, enumeracje, iteratory, sekwencje, metody rozszerzające, ogólnie LINQ, a na koniec polimorfizm. Faktycznie, 5 minut nauki dla osoby która raczkuje w programowaniu. :)

Co do elastycznosci, na ktora sie tak czesto powolujesz a nie masz o niej pojecia, to:

Mam kod który działa podobnie do Twojego, czyli

        for (int i = 0; i < persons.Length; i++)
        {
            var p = new Person();
            p.Name = "Jan";
            p.Age = i.ToString();
            persons[i] = p;
        }

Jednak chcę go zmienić żeby wczytawał dane z konsoli, nie ma problemu (u Ciebie też).

        for (int i = 0; i < persons.Length; i++)
        {
            var p = new Person();
            p.Name = Console.ReadLine();
            p.Age = int.Parse(Console.ReadLine());
            persons[i] = p;
        }

Po chwili dostaję informację "użytkownik nie wie co zrobić, należy mu wyświetlić komunikat". U siebie dopiszę dwie naturalne linijki, a Ty albo całkowicie zmienisz swój kod, albo stworzysz babola.

       for (int i = 0; i < persons.Length; i++)
        {
            var p = new Person();
            Console.Write("Podaj imię: ");
            p.Name = Console.ReadLine();
            Console.Write("Podaj swój wiek: ");
            p.Age = int.Parse(Console.ReadLine());
            persons[i] = p;
        }

"Program się wysypał jak użytkownik przypadkiem wpisał literę w wieku", znowu zmieniam w prosty sposób kod i mam:

         for (int i = 0; i < persons.Length; i++)
        {
            var p = new Person();
            Console.Write("Podaj imię: ");
            p.Name = Console.ReadLine();

            while (true)
            {
                Console.Write("Podaj swój wiek: ");
                if ( int.TryParse(Console.ReadLine(), out p.Age))
                    break;
                else
                    Console.WriteLine("Podany wiek nie jest liczbą.");
            }
            persons[i] = p;
        }

Wracając do przykładu z dzieckiem i dodawaniem. Zadanie brzmi

Podaj sumę:
a) 1+5 = ? (Ty uczysz sumy ciągu arytmetycznego)
b) 2+9 = ? (dzieciak używa wzoru)
c) 1+2+4 = ? (dzieciak nie ma żadnego pożytku z sumy ciągu arytmetycznego...)

W tym zadaniu można pokazać użytkownikowi "zamiast z tablic możesz skorzystać z List<int>, a wynik możesz wyświetlić za pomocą foreach".

#Moj algorytm nie wymusza znajomosci sposobu iteracji po kolekcji.
#Wszystkie czesci sa atomowe i moga byc reuzywane w osobnych miejscach, niezaleznie od rodzaju obiektow czy kolekcji agregujac.
#Kod wykonujacy iteracje jest sprawny i przetestowany przez dobre kilka lat.
#Sam algorytm jest oddzielony od interakcji z uzytkownikiem.
#Nie korzystam z zadnych wnetrznosci specyficznych dla danej kolekcji, nie wymagam indeksera czy dostepu do losowego elementu. Nie wymaga, zeby argumentem tego indeksera byl int. W gruncie rzeczy nic nie wymagam, tylko korzystam z abstrakcji dostarczonej przez MS.

  1. Algorytm, to chyba zbyt wielkie słowo. :) W kuchni korzystasz z przepisu na wrzącą wodę? :)
  2. KTÓREKOLWIEK części Twojego kodu są atomowe? Co może byc używane ponownie, te 4 linie kodu które napisałeś i nawet nie są ujęte w metodę czy chodzi Ci o kod które Ty nie napisałes czyli Select, Range? Równie dobrze mogę napisać, że "moje rozwiązanie" jest używane w milionach miejc, bo programy korzystają z for czy i++. :D
  3. Ja for (int i = 0; i < persons.Length; i++) wymyśliłem wczoraj, a teraz czekam na odpowiedź z biura patentowego, bo to świeży i innowacyjny kod. :P
  4. Sam "algorytm" działa na stałych, nie ma interakcji z użytkownikiem. Równie dobrze mogę napisać, że "mój algorytm jest oddzielony od bazy danych".
  5. Korzystasz z List<T>.ForEach który nie występuję w innych kolekcjach.

Twoj kod natomiast uzywa prymitywnych rozwiazan rodem z C

Tak, bo one są najodpowiedniejsze w tym momencie.

Jesli chcesz pokazywac zle metodyki kodzenia zaslaniajac sie pustymi frazesami, ktorych nie rozumiesz, to zycze powodzenia w przyszlosci.

Rozwiazanie które zaproponowałeś nie jest krótsze, nie jest czytelniejsze, nie jest wydajniejsze, nie jest w żaden sposób lepsze, a ma wad - trudno je zmienić, rozwinąć. Proszę Ciebie, pokaż KOD gdzie do swojego rozwiązania dodajesz np. wyświetlanie komunikatów lub weryfikację czy dane są prawidłowe.

Odnośnie pustych frazesów to Ty piszesz: "Moj algorytm" (?), "atomowość" (?), "reużywalność" (?), "kolekcji agregujac" (?).

Żeby było jasne, uwielbiam "zgrabny" kod. Taki który jest "intensywny", czyli krótki i korzystając z wszystkich możliwości języka/bibliotek, ale tutaj Twój kod wcale nie jest krótszy, czytelniejszy czy cokolwiek... Nawet nie jest równorzędną alternatywą.

0

Szablony, delegaty, wyrażenie [...]

Duzo buzzwordow, moze skupmy sie na wywolaniu kilku metod i przekazywaniu do nich obiektow? Bo rownie dobrze moge i twoj kod rozpisac na 100 slowek ;>

U siebie dopiszę dwie naturalne linijki, a Ty albo całkowicie zmienisz swój kod, albo stworzysz babola.

To nie sa 2 naturalne linijki. Nikt takich linijek nie pisze w kazdym miejscu bo jest to dosc czesty use-case. Ja natomiast wyciagne sobie odpowiedni typ (czy nawet stringa) dla uproszczenia, podajac komunikat do metody i zwracajac wprowadzone dane.

Co do reszty twojego 'pokazu' -> Nie wiem czy zdajesz sobie sprawe, ale w tej metodzie, ktora przekazuje do Select moze byc dowolnie skomplikowany kod.

  1. Algorytm, to chyba zbyt wielkie słowo. :) W kuchni korzystasz z przepisu na wrzącą wodę? :)

W kuchnii korzystam z algorytmu parzenia herbaty, a zeby dojsc do kuchnii, uzywam algorytmu dochodzenia do kuchnii, cos w tym dziwnego?

  1. KTÓREKOLWIEK części Twojego kodu są atomowe? Co może byc używane ponownie, te 4 linie kodu które napisałeś i nawet nie są ujęte w metodę czy chodzi Ci o kod które Ty nie napisałes czyli Select, Range?

Jak juz pisalem, sposob tworzenia kolekcji, zakres, algorytm tworzenia mozna dowolnie wymienic. I te kilka metod, mozna wykonywac w roznych miejscach programu.

Równie dobrze mogę napisać, że "moje rozwiązanie" jest używane w milionach miejc

Oczywiscie, ze jest uzywane. Ale skoro ty piszesz iteracje, ty musisz ja testowac.

  1. Korzystasz z List<T>.ForEach który nie występuję w innych kolekcjach.

Tak pominalem ten blad w sztuce .NET. Ja mam ForEach dla kazdej kolekcji, po ktorej chce iterowac, ale znow... musialem to napisac, przetestowac i w gruncie rzeczy zajelo calosc wiecej niz 5 minut.

krótszy, czytelniejszy czy cokolwiek...

Oczywiscie, ze jest. Moj kod mowi o tym, co chce zrobic, twoj jak to zrobic.

Nie wiem dlaczego na sile przytaczasz ten denny przyklad z dzieckiem. Duzo latwiej jest zrozumiec cos co jest ekspresywne, bo nie ma zbednych rzeczownikow (choc to i tak trudne w .NET bo wystepowac one czasem musza).

Do tego, jesli myslisz, ze trzeba znac wszystkie interale tego jak dzialaja te metody, ktore uzylem, zeby wiedziec co robia, no to wspolczuje.

Anyway... wydaje mi sie, ze problem jest z toba taki, ze wiedza ogranicza twoje myslenie. Myslisz, ze kod korzystajacy z prymitywow jest prosty, bo sam zaczynales od takich i ci dobrze szlo. A ta abstrakcja jest trudna, bo wewnetrznie korzysta z trudnych mechanizmow. I w gruncie rzeczy, tym drugim nie warto glowy zawracac poczatkujacemu. Jednak IMO cala trudnosc w nauce programowania dla poczatkujacego, to przestawienie sie z jezyka naturalnego, na jezyk maszynowy w wyrazaniu mysli.

Nikt nie mowi przy stole:

Podnies reke
Przesun reke w kierunku soli
Zlap sol
Przesun reke do mnie
Zabieram sol
Wroc z reka do poczatkowej pozycji

Tylko:

Podaj sol

Dlatego tez nie widze zadnego sensu w uczeniu ludzi mowienia komputerowi pokolei jakie rozkazy ma wykonywac.

0

może dacie ten wątek do MS niech oni rozstrzygną?

Ilu programistów tyle kodu proste, nie ważna jest droga ważny jest CEL, tak czy siak co za różnica? chyba ważne aby działało?

0

Duzo buzzwordow, moze skupmy sie na wywolaniu kilku metod i przekazywaniu do nich obiektow? Bo rownie dobrze moge i twoj kod rozpisac na 100 slowek ;>

Każde z tych słów dla początkującego oznacza od kilku do kilkudziesięciu minut nauki. Możesz wypisać 100 słówek, ale każde z nich będzie się odnosiło również do Twojego kodu. Stosuję podstawy które tworzą bardziej zaawansowane rzeczy.

Wydaje mi się, że Ty te podstaw pominąłeś lub nie zrozumiałeś ich. Przykładowo zdanie: Wszystkie czesci sa atomowe i moga byc reuzywane w osobnych miejscach, niezaleznie od rodzaju obiektow czy kolekcji agregujac. :D W odniesieniu do operacji które nie są atomowe, według Twojej definicji KAŻDY kod jest reużywalny (bo korzysta z kontrukcji które są użyte gdzie indziej), a kolekcje agregujące chyba Ci się pomieszały z metodami aggregującymi... z których nie skorzystałeś w kodzie. :) Chciałeś użyć "mądrych" słów tak jakby Ci one imponowały.

Oczywiscie, ze jest. Moj kod mowi o tym, co chce zrobic, twoj jak to zrobic.

Nie, nie mówi.

    IEnumerable<Person> GetPersons(int count)
    {
        return Enumerable.Range(0, count)
                         .Select(i => new Person("xyz", i));
    }

    IEnumerable<Person> GetPersons(int count)
    {
        for (int i = 0; i < count; i++)
            yield return new Person("xyz", i);
    }

Powyższe kody w gruncie rzeczy nie różnią się. Gdybyś napsiał: Enumerable.Repeat(Person.Create(), 10), to wtedy faktycznie wprowadzasz abstrakcję. Ty tego nie zrobiłeś. Swoją drogą dodawnie abstrakcji kiedy jest zbędna jest... zbędne.

Anyway... wydaje mi sie, ze problem jest z toba taki, ze wiedza ogranicza twoje myslenie. Myslisz, ze kod korzystajacy z prymitywow jest prosty, bo sam zaczynales od takich i ci dobrze szlo

Moja wiedza wystarcza żeby zrozumieć Twój kod, a doświadczenie mówi "to nie jest narzędzie potrzebne do tego zadania".

A ta abstrakcja jest trudna, bo wewnetrznie korzysta z trudnych mechanizmow. I w gruncie rzeczy, tym drugim nie warto glowy zawracac poczatkujacemu

Te trudne mechanizmy to for które tak się boisz, czy foeach? :)

Jednak IMO cala trudnosc w nauce programowania dla poczatkujacego, to przestawienie sie z jezyka naturalnego, na jezyk maszynowy w wyrazaniu mysli. Dlatego tez nie widze zadnego sensu w uczeniu ludzi mowienia komputerowi pokolei jakie rozkazy ma wykonywac.

Nie do końca rozumiem jaki jest Twój przekaz. Nie chodzi mi o to żeby wynajdować koło na nowo, ale żeby pisać prosty kod. Ty utrudniłeś zapis. Reguła KISS się kłania, a Twoja metoda "podaj sól" ma trzy odpowiedzialności. :P

1

Każde z tych słów dla początkującego oznacza od kilku do kilkudziesięciu minut nauki. Możesz wypisać 100 słówek, ale każde z nich będzie się odnosiło również do Twojego kodu.

Ktorych nie musi poswiecac, bo nie sa one jawne, tylko ukryte za implementacja ow metod.

Stosuję podstawy które tworzą bardziej zaawansowane rzeczy.

Nie, petle nie sa podstawa.
Podstawa jest:
#Tworzenie wyrazen prostych (np. 2)
#Przypisywanie wyrazeniom prostym nazw (np. int a = 10)
#Mechanizmy abstrakcji umozliwiajace z wyrazen prostych tworzenie wyrazen zlozonych.
#Wykorzystywanie wyrazen zlozonych zaimplementowanych w jezyku/bibliotece.

Jesli myslisz, ze petla for ma cos wspolnego z podstawowym mechanizem programistycznym, to coz... tego juz nie przeskocze.

Nie, nie mówi.

Oczywiscie, ze mowi. Twoj (nowy) kod natomiast mowi w jezyku bardziej specyficznym dla omawianej domeny.

Te trudne mechanizmy to for które tak się boisz, czy foeach? :)

Oczywiscie, wszystkie mechanizmy wykraczajace poza podstawowe sa skomplikowane dla nowicjuszy co jest calkowicie naturalne. Widzisz w tym cos dziwnego?

ale żeby pisać prosty kod.

Petle nie sa prostym kodem, trzeba sie martwic o inicjalizacje, warunek zakonczenia, krok - w moim kodzie nie trzeba, bo jest to niejawne. Ta petla jest prosta bo podrecznik tak mowi czy wtf?

Twoja metoda "podaj sól" ma trzy odpowiedzialności.

Na tym polega programowanie. Kombinacja wyrazen prostych i zlozonych do wyrazen bardziej zlozonych w celu utworzenia abstrakcji i odsuniecia klienta metody od wnetrznosci. Spales na wykladach?

1
n0name_l napisał(a):
		var persons = Enumerable.Range(0, 10).Select(i => new Person {
			FirstName = i.ToString(),
			LastName = "Nazwisko"
		}).ToList();
		persons.ForEach(Console.WriteLine);

Bardzo naciągany przykład. Gdy chcemy coś wykonać wiele razy, to używamy pętli, a nie tworzymy niepotrzebną kolekcję liczb, i wołamy na niej metodę.

n0name_l napisał(a):

Moj algorytm nie wymusza znajomosci sposobu iteracji po kolekcji.

Dzięki czemu może być użyty przez kogoś, kto nie zna pętli. Coś pisałeś chyba o równaniu średniej umiejętnościowej, ale aż tak?...

Wszystkie czesci sa atomowe i moga byc reuzywane w osobnych miejscach, niezaleznie od rodzaju obiektow czy kolekcji agregujac.

Naprawdę trudno mi znaleźć jakieś części w tak krótkim kawałku kodu. :)

Nie korzystam z zadnych wnetrznosci specyficznych dla danej kolekcji, nie wymagam indeksera czy dostepu do losowego elementu. Nie wymaga, zeby argumentem tego indeksera byl int. W gruncie rzeczy nic nie wymagam, tylko korzystam z abstrakcji dostarczonej przez MS.

Właśnie wymieniłeś wszystkie zalety foreach.

Twoj kod natomiast uzywa prymitywnych rozwiazan rodem z C, ale nie przejmuj sie, kiedys zrozumiesz ile wnosi przekazywanie odpowiedzialnosci za iteracje do kolekcji, ktora ma wieksza wiedze o tym jak ja wykonac i jaka modularnosc i elastycznosc to powoduje. Zarowno w programowaniu rownoleglym, jak i 1-watkowym.

No i prymitywne rozwiązanie z Lispa jest argumentem na prymitywne rozwiązanie z C? ;P

Po pierwsze, to foreach nie jest pętlą. To tylko zgrabne opakowanie składniowe na abstrakcję, którą dostarcza IEnumerable. To jest elastyczne i modularne rozwiązanie.
Po drugie, foreach jest w wielu zastosowaniach wydajniejszy, bo jest optymalizowalny przez kompilator, np. w przypadku iterowania po stringu albo tablicy.

n0name_l napisał(a):

Tak pominalem ten blad w sztuce .NET. Ja mam ForEach dla kazdej kolekcji, po ktorej chce iterowac, ale znow... musialem to napisac, przetestowac i w gruncie rzeczy zajelo calosc wiecej niz 5 minut.

To nie jest błąd w sztuce, to jest celowe i spójne działanie. Metoda ForEach nie jest częścią LINQ, i została zaimplementowana tylko tam, gdzie ma ona sens.

Metody z LINQ zawsze zwracają wartość i nie powodują skutków ubocznych - co jest zgodne z funkcyjnymi założeniami tej technologii. Metoda ForEach jest całkowitym przeciwieństwem tego - jej jedynym sensem jest powodowanie skutków ubocznych, a nie zwracanie wyniku. Jako, że LINQ nie powoduje skutków ubocznych, to może działać na IEnumerable<T>, czyli na kolekcjach z definicji niezmiennych. Tworzenie metody zmieniającej stan tam, gdzie chodzi właśnie o niemutowalność, wygląda mi na lekką paranoję.

Oczywiscie, ze jest. Moj kod mowi o tym, co chce zrobic, twoj jak to zrobic.

Ty chyba chcesz z C# zrobić coś, czym on nie jest.

Fakty są takie, że C# jest językiem imperatywnym. Sterowanie w nim odbywa się poprzez pętle i instrukcje warunkowe. Te kilka funkcyjnych dodatków, które posiada, absolutnie nie czynią z niego języka funkcyjnego. Są miłe i przydatne, bo pozwalają pominąć pisanie żmudnych pętli w wielu typowych przypadkach, ale nie zastępuję one typowych, imperatywnych operacji.

Jak ktoś chce pisać funkcyjnie, to niech robi to w języku funkcyjnym, a nie w C#.

Dlatego tez nie widze zadnego sensu w uczeniu ludzi mowienia komputerowi pokolei jakie rozkazy ma wykonywac.

Nikt nie mówi nikomu dokładnego algorytmu, tylko wywołuje funkcję. Jak najbardziej imperatywną, bo ludzie są imperatywni, myślą i działają w ten właśnie sposób.

0

Mam coraz więcej frajdy z rozmowy z Tobą. :) Podoba mi się jak np. nie odnosisz się do zdania w którym palnąłeś trzy głupoty.

Ktorych nie musi poswiecac, bo nie sa one jawne, tylko ukryte za implementacja ow metod.

Pogubiłem się... Odnosisz się do mojego kodu w którym mógłbyś wypisać słówka typu "deklaracja zmiennych", "inkrementacja", "wywołanie metody" i gdzie jedynym elementem który nie zawiera Twój kod jest skorzystanie z "for". Za to wymagasz nauki Szablony, delegaty, wyrażenie lambda czyli również uwiązanie zmiennej/leniwa ewaluacja, enumeracje, iteratory, sekwencje, metody rozszerzające, ogólnie LINQ.

Podstawa jest:

Kto o tym decyduje? W ksiązce C# 5.0 in a nutshell pętle są w dziale drugim "C# language basic" i na for jest poświęcone pół strony. W czwartym dziale "advanced c#" znajdziemy delegaty (9 stron), lambda expressions (7 stron), metody anonimowe (jedna strona), enumerator i iteratory (5 stron).

Tak swoją drogą korzystanie z pętli nie zalicza się do punktu 4? :) Czy pisanie jakkolwiek skomplikowanego programu nie zalicza się do punktu 4? Dla Ciebie wszystko jest podstawą podobnie jak każdy kod jest "reużywalny"?

Oczywiscie, wszystkie mechanizmy wykraczajace poza podstawowe sa skomplikowane dla nowicjuszy co jest calkowicie naturalne. Widzisz w tym cos dziwnego?

Cieszę się, że otwarcie piszezs o tym ze jestes nowicjuszem. :)

Ta petla jest prosta bo podrecznik tak mowi czy wtf?

Tak.

Na tym polega programowanie. Kombinacja wyrazen prostych i zlozonych do wyrazen bardziej zlozonych w celu utworzenia abstrakcji i odsuniecia klienta metody od wnetrznosci. Spales na wykladach?

Twoja metoda "podaj sól":

  1. Podaje sól
  2. Przekazuje ją.
  3. Cofa rękę.

To tak jakbyś napisał metodę "otwórzy plik" która otwiera plik, przetwarza go, zapisuje wynik, zamyka plik. Zapoznaj się z haslemsingle responsibility principle.

0

To nie jest błąd w sztuce, to jest celowe i spójne działanie.

To jest blad w sztuce, metoda ta powinna byc dostepna dla wszystkiego po czym moge iterowac. Nikt nie pisal, ze ma byc w jakims specjalnym zestawie metod pod specjalna nazwa.

No i prymitywne rozwiązanie z Lispa jest argumentem na prymitywne rozwiązanie z C?

Prymitywne rozwiazania z Lispa sa o niebo wyzej tych z C, a nawet o niebo wyzej tych w C# co padly tutaj.

Jak ktoś chce pisać funkcyjnie, to niech robi to w języku funkcyjnym, a nie w C#.

http://pl.wikipedia.org/wiki/Fiksacja_funkcjonalna

Generalnie to fajnie, ze na moje argumenty przeciw petlom, podajesz przyklad jak sam napisales czegos co petla nie jest i probujesz kontratakowac optymalizacjami :)
No chyba, ze widziales gdzies w tym watku, jak @dlaczegotak uzyl foreach.

Chyba pora konczyc, bo srednio mi sie widzi dyskusja z jednym panem, ktory probuje sie popisac blazenada i z drugim, ktory mowi nie na temat.

1

Podsumowując:

  • operacje LINQ są atomowe
  • każdy kod jest "reużywalny", bo korzysta z kodu który już został napisany
  • wszystko jest podstawami z wyjątkiem for
  • @n0name_l jest nowicjuszem

Dziękuje za ciekawą dyskusję i interesujące wnioski. :) Polecam się na przyszłość.

1
_13th_Dragon napisał(a)

"Wiem, że komentarz podobny do mojego pojawiały się wielokrotnie" - owszem i wszystkie twoje

Jestem co najmniej drugą osobą która tak pisała bo to prawda
Owszem Twoje kody nadal są łatwe ale są bardzo skompresowane... Dobry kod przegląda się scrollując praktycznie bez zatrzymywania i rozumiejąc 70% jego sensu, podczas gdy pozostałe 30% nas nawet nie powinny obchodzić bo to szczegóły implementacji; Twój kod trzeba przeczytać od deski do deski żeby zrozumieć że służy on do wypisana trzech kolejnych cyfr

Wracając do tematu - sam jestem zakochany w Linq; uwielbiam skracać istniejące pętle na 15 linijek do trzech linijek z użyciem lamby linq (bynajmniej nie w stylu _13th_Dragon ;) ) i niezmiernie mnie boli gdy muszę użyć zwyczajnej pętli.
Ale do cholery pętle to podstawa programowania i tutaj zdecydowanie użyłbym zwykłej pętli

Natomiast, n0name_l, gdybyś był moim synem to zebrałbyś porządne manto za stworzenie listy liczb po których miała by się iterować pętla i zrobienie na nich Foreach :P
Przestańcie się popisywać nietypowymi pomysłami na kod; jak chcecie się wyrazić to polecam malarstwo

1

@n0name_l, zazwyczaj się z Tobą zgadzam, ale w tym wątku po prostu piszesz kompletne bzdury.

n0name_l napisał(a):

To jest blad w sztuce, metoda ta powinna byc dostepna dla wszystkiego po czym moge iterowac. Nikt nie pisal, ze ma byc w jakims specjalnym zestawie metod pod specjalna nazwa.

Napisałem, dlaczego nie powinna być dostępna dla każdej kolekcji. Czego konkretnie nie zrozumiałeś?
Ewentualnie poczytaj sobie, co na ten temat do powiedzenia ma np. Eric Lippert.

Jak ktoś chce pisać funkcyjnie, to niech robi to w języku funkcyjnym, a nie w C#.

http://pl.wikipedia.org/wiki/Fiksacja_funkcjonalna

Trzymasz gazety w lodówce?
Używasz wioseł do kierowania samochodem?
Pompujesz koła w rowerze strzykawką?

Bo jeśli nie, to znaczy, że ogranicza Cię fiksacja funkcjonalna.

Generowanie sekwencji liczb tylko po to, aby udać w ten sposób pętlę to aberracja, której miejsce jest w programistycznych WTF, a nie w Newbie.

Generalnie to fajnie, ze na moje argumenty przeciw petlom, podajesz przyklad jak sam napisales czegos co petla nie jest i probujesz kontratakowac optymalizacjami :)
No chyba, ze widziales gdzies w tym watku, jak @dlaczegotak uzyl foreach.

@ne0 użył, a Ty postanowiłeś to "ulepszyć" za pomocą '"ForEach''.

Chyba pora konczyc, bo srednio mi sie widzi dyskusja z jednym panem, ktory probuje sie popisac blazenada i z drugim, ktory mowi nie na temat.

Masz pewno rację, pora żebyś skończył bredzić i zacząć pisać w C# kod w C#. Jedyną osobą, która tu błaznuje jesteś niestety Ty, co mnie naprawdę mocno dziwi.

0

Napisałem, dlaczego nie powinna być dostępna dla każdej kolekcji. Czego konkretnie nie zrozumiałeś?

Nie, napisales, ze nie pasuje do funkcjonalnego podejscia, ktore towarzyszylo przy tworzeniu LINQ poniewaz metoda ta polega na efektach ubocznych. Calkowita racja.
W jezyku imperatywnym nie spodziewam sie natomiast ograniczen ze wzgledu, ze cos polega na efektach ubocznych, czyz nie?
Skoro moge uzywac skladni:
foreach(var elem in dict) {}, czemu nie moge uzyc metody ForEach?
Przeciez C# to nie jezyk funkcyjny, wiec moze ideologozimy na bok odstawimy?

Bo jeśli nie, to znaczy, że ogranicza Cię fiksacja funkcjonalna.

Jesli ktorekolwiek z nich by mi dawaly realne korzysci to bym z pewnoscia uzywal.

Generowanie sekwencji liczb tylko po to, aby udać w ten sposób pętlę to aberracja, której miejsce jest w programistycznych WTF, a nie w Newbie.

Alez ja wcale nie generuje sekwencji liczb, zeby udac z niej petle. Generuje sekwencje liczb aby zrobic jej transformacje na sekwencje ludzi, gdzie imie odpowiada liczbie w sekwencji poczatkowej. To samo co zrobil @ne0. On te liczby wygenerowal za pomoca petli, ja za pomoca czegos co sluzy do generowania liczb.

Gdybym nie musial uzywac tych liczb, to bym wcale sekwencji liczb nie generowal, bo i po co?

użył, a Ty postanowiłeś to "ulepszyć" za pomocą '"ForEach''

Nie, postanowilem skrocic za pomoca ForEach jednoczesnie wskazujac, ze budowanie reprezentacji tekstowej powinno byc odpowiedzialnoscia klasy, a nie funkcji Main. Natomiast tutaj nie ma zadnego ulepszenia, poza skroceniem kodu z 4 linijek do 1 w konwencji .NETowcow. Co jest najbardziej oczywistym rozwiazaniem dla prostych wyrazen.

zacząć pisać w C# kod w C#.

Moj kod nie jest w C# wedlug czego? Kompilator ma sie z nim dobrze.

Anyway... Jak chcecie pisac 10 linijek kodu zamiast 4, ktore robia dokladnie to samo to jest to wasza sprawa.
Natomiast jak mowicie:
#Petla for jest podstawowa konstrukcja programistyczna
#Petla for jest prostsza od wywolania metody
#Zeby skorzystac z mojego kodu trzeba wiedziec co to generyki
#Kod stworzony przy pomocy petli for jest bardziej czytelny czy intuicyjny od tego z wywolaniami metod

To bardzo mi przykro, ale sa to po prostu klamstwa. Nie widze zadnej realnej mozliwosci dlaczego konstrukcja 5 elementowa, ktorego 1 element jest zalezny od drugiego, mialabybyc prostsza od konstrukcji 3 elementowej. Nie widze zadnego powodu dlaczego konstrukcja 3 elementowa mialabybyc mniej czytelna od tej 5.

Podawanie tutaj miejsca, gdzie i ile zajmuje wyjasnienie co to for w porownaniu z enumeratorami jest dosc slabe.
Kolega @dlaczegotak na pewno przed napisaniem hello-worlda wiedzial co to dziedziczenie. Bo jak inaczej?

1

foreach(var elem in dict) {}, czemu nie moge uzyc metody ForEach?

Możesz, tylko nie to żadnej zalety, a zazwyczaj jest mniej czytelne. :)

Anyway... Jak chcecie pisac 10 linijek kodu zamiast 4, ktore robia dokladnie to samo to jest to wasza sprawa.

24 linie.

using System;

class Program
{
    static void Main(string[] args)
    {
        Person[] persons = new Person[10];
        for (int i = 0; i < 10; i++)
            persons[i] = new Person
            {
                FirstName = i.ToString(),
                LastName = "Nazwisko"
            };

        foreach (var p in persons) 
            Console.WriteLine("{0} {1}", p.FirstName, p.LastName);
    }
}

class Person
{
    public string FirstName;
    public string LastName;
}

25 linii.

using System;
using System.Linq;

class Program
{
    static void Main(string[] args)
    {
        var persons = Enumerable.Range(0, 10).Select(i => new Person
        {
            FirstName = i.ToString(),
            LastName = "Nazwisko"
        }).ToList();
        persons.ForEach(Console.WriteLine);
    }
}

class Person
{
    public string FirstName;
    public string LastName;
    public override string ToString()
    {
        return String.Format("{0} {1}", FirstName, LastName);
    }
}

Oczywiście można dyskutować o formatowaniu itd., ale na pewno nie ma 10->4...

Natomiast jak mowicie:
#Petla for jest podstawowa konstrukcja programistyczna
#Petla for jest prostsza od wywolania metody
#Zeby skorzystac z mojego kodu trzeba wiedziec co to generyki
#Kod stworzony przy pomocy petli for jest bardziej czytelny czy intuicyjny od tego z wywolaniami metod

  1. Tak, pętla to podstawa. W którymś z poprzednich postów spytałeś mnie czy spałem na wykładach, spójrz na to czego uczą na "wstępie do programowania" czy podobnych zajęciach. :) Poza tym w większości kursów, tutoriali, książek w podstawach znajduje się for/while. Mogę przytoczyć dziesiątki źródeł gdzie for jest uznawany za podstawę, a Ty jakiekowliek gdzie for to zaawansowany mechanizm?
  2. Tak, wywołanie metody jest prostsze od pętli, ale to nie znaczy że skorzystanie z konkretnej metody jest prostsze. :)
  3. Co rozumiesz przez "skorzystać", bo jak dla mnie skorzystanie = umiejętność zastosowania przedstawionych funkcji w innym przypadku, a to chyba trudno zrobić nie rozumiejąc co oznacza List<T> lub Action<T>, a Ty jeszcze dowaliłeś lambdy.
  4. Zależy od przypadku, zazwyczaj LINQ jest zgrabniejszym rozwiązaniem, ale nie wszędzie. Jest wiele miejsc gdzie zwykła pętla jest równie czytelna (tak jak tutaj), a w niektórych zastosowaniach to for góruje.

To bardzo mi przykro, ale sa to po prostu klamstwa.

Jeżeli coś jest kłamstwem to istnieje "prawda", a większość Twoich punktów nie ma rozwiązania zerojedynkowego.

W 1. to chyba Twoja i tylko Twoja opinia.
W 2 pewnie masz rację.
w 3 zależy od definicji "skorzystać", jeżeli piszesz o ctr+c -> ctr+v -> kompiluj, to nic nie trzeba wiedzieć o kodowaniu. Niezależnie czy for, czy LINq, czy skompilowanie olbrzymiego projektu open source :)
W 4 zależy od przypadku.

Kolega @dlaczegotak na pewno przed napisaniem hello-worlda wiedzial co to dziedziczenie. Bo jak inaczej?

Po prostu nie skorzystałem z dziedziczenia do napisania hello world. :) Teraz wiem co to jest dziedziczenie i powiem Ci, że dalej nie skorzystałbym z niego do napisanaia hello world. :)

0

zazwyczaj jest mniej czytelne. :)

No wlasnie, zazwyczaj. Czy w tym przypadku jest mniej czytelne? Jak juz pisalem dla mnie jest to genialna forma dla prostych wyrazen.

Skrociles kod na potrzeby pokazu poprzez usuniecie klamer, ktore IMO sie powinno stawiac, bo to jest dodatkowa mozliwosc popelnienia bledow w kodzie przy jego modyfikacji. Chyba nie chcemy popelniac bledow?

spójrz na to czego uczą na "wstępie do programowania"

Lispa?

Tak, wywołanie metody jest prostsze od pętli, ale to nie znaczy że skorzystanie z konkretnej metody jest prostsze.

Jesli ktos umie wywolac metode to znaczy, ze umie jej uzyc. Zdaje sobie sprawe zarowno z tego co zwraca, jak i co przyjmuje. Nie musi wiedziec wszystkiego o IEnumerable<T>, natomiast musi wiedziec, ze operuje na sekwencji elementow.

Co rozumiesz przez "skorzystać", bo jak dla mnie skorzystanie = umiejętność zastosowania przedstawionych funkcji w innym przypadku, a to chyba trudno zrobić nie rozumiejąc co oznacza List<t> lub Action<t>, a Ty jeszcze dowaliłeś lambdy.

List<T> uzyl rowniez @ne0 w kodzie, ktory tak bardzo chwalisz, a teraz jest nagle trudnym moim wymyslem? Latwo zrozumiec, naprawde. Nie trzeba wiedziec co to Action<T>, jak to dziala i po co to jest. Trzeba wiedziec, ze metoda przyjmuje metode o jakiejstam sygnaturze, tyle.

W 1. to chyba Twoja i tylko Twoja opinia.

Nie tylko.

W 4 zależy od przypadku.

Metody maja to do siebie, ze tworza abstrakcje (juz pisalem o tym zreszta, tak to tez ze "Wstepu do programowania"), a for tego nie robi. Jesli mam stworzyc zbior elementow -> uzyje Range, jesli mam powtorzyc cos N razy -> uzyje Repeat, widzisz jak bardzo podobne sa wyjasnienia tych metod w jezyku polskim do kodu?

Po prostu nie skorzystałem z dziedziczenia do napisania hello world.

Wiec jak go napisales?

1

Skrociles kod na potrzeby pokazu poprzez usuniecie klamer, ktore IMO sie powinno stawiac, bo to jest dodatkowa mozliwosc popelnienia bledow w kodzie przy jego modyfikacji. Chyba nie chcemy popelniac bledow?

Co kto lubi, ale klamry trudno traktować jako linie kodu.

Lispa?

for :)

Jesliktos umie wywolac metode to znaczy, ze umie jej uzyc.

Nie. Potrafie wywołać metodę static double Xyz( string a, string b), a nie mam pojęcia jak jej użyć. Ponadto jak pytasz czy użycie metody jest łatwiejsze od for, to chyba zależy od metody? Console.ReadLine jest zapewne łatwiejsze w użyciu od for, natomiast Regex.Replace niezbyt. :)

List<T> uzyl rowniez @ne0 w kodzie, ktory tak bardzo chwalisz,

W żadnym momencie nie chwaliłem kodu tego użytkownika.

Nie trzeba wiedziec co to Action<T>, jak to dziala i po co to jest.

Trzeba wiedziec, ze metoda przyjmuje metode o jakiejstam sygnaturze, tyle.

Hahaha, lubię z Tobą dyskutować. :D Nie muszę wiedzieć co to jest Action<T>, ale muszę wiedzieć co to jest Action<T>

Metody maja to do siebie, ze tworza abstrakcje

Tak, ale nie zawsze potrzeba abstrakcji. :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1