🚀 go-pugleaf

>    Bo jeśli teraz powiecie, że powinno się to rozwiązywać wewnątrz klasy 
> tworząc listę, czy tabelę ze wskaźnikami na strukturę. A w programie 
> posługiwać się ciągle tym samym obiektem i co najwyżej wywoływać metodę, 
> która podstawi nam dane konkretnego rekordu z takiej listy, czy tabeli to 
> będę mocno rozczarowany. Oznaczało by to przecież, że cała ta obiektówka

trochę mylisz pojęcie klasy i instancji klasy.

okej, w programowaniu obiektowym masz różne KLASY. ale klasa, rozumiana 
przez funkcjonalność modelowanego "bytu" może w programie mieć wiele 
instancji, czyli wystąpień.

to oznacza, że zgodne z duchem obiektowym jest:

Osoba o1;
Osoba o2;
....

(i zauważasz, że tablica czy kolekcja, jako obiekt typu "kontener" załatwia 
Ci problem "nieznanej liczby wystąpień),

a NIE jest intencją programowania obiektowego tworzenie nowej KLASY w każdym 
wystąpieniu obiektu:

Osoba1 o1;
Osoba2 o2;
...

> daje nam tylko lepszą ochronę i izolację pomiędzy różnymi częściami 
> programu, no powiedzmy jeszcze dziedziczenie, ale nic poza tym.

a o wzorcach projektowych Kolega słyszał? tam dopiero poznaje się istotę 
programowania obiektowego. proponuję standardowo zacząć od "Head First: 
Design Patterns".

pozdrawiam uprzejmie,
Wiktor Zychla