A po co w kazdy obiekt ma "wiedziec" ze obok niego istnieja inne obiekty?
Żaden obiekt nie wie, że istnieją obok niego inne obiekty w tym konkretnym przypadku. Po prostu każdy wie, że istnieje coś takiego, jak jeden jedyny kontroler usb. Taaak - mogę zrobić klient-serwer i do "serwera" wstawić dwie tablice na krzyż, jak post wyżej sam napisałem - pytanie po co? Żeby rozdąć projekt jeszcze bardziej, skoro można minimalistycznie wstawić po prostu dane w taki zakres leksykalny, w jakim mają być? I związać z klasą obiektów, które zeń korzystają?
Panie zielonka, jakbym wszędzie wszystko rozbijał w taki ultra OO sposób, to bym miał projekt, o którego strukturze bym książkę mógł napisać. Książkę nikomu niepotrzebną swoją drogą, bo łatwiej, chociaż mniej trendy, jest napisać ten jeden moduł od nowa, niż ślęczeć x dni nad dokumentacją projektu i szukać, co po czym ma dziedziczyć, co przeładować, i dlaczego do cholery obsługa urządzenia możliwa do napisania w 150 liniach zajmuje 10KB i wprowadza 10 klas abstrakcyjnych albo pośredniczących!?
Po co inny obiekt ma wiedzieć, że istnieją inne? A boże mój, czasem po prostu ma wiedzieć, bo w modelowanym problemie obiekty wiedzą o sobie nawzajem. I nie będę zawsze tworzył dodatkowej klasy-pojemnika, skoro obiekty same mogą się orientować w tym, że są w stadzie.
Zresztą ja się pytam, co to niby za lepsiejsze rozwiązanie, że mamy klasę "grupa" i wszystkie obiekty wsadzone doń od rozwiązania, że mamy po prostu obiekty, samodzielnie wiedzące o tym, że są jednego typu, więc są razem? Pojęcie klasy samo naturalnie tworzy grupę, nie muszę wprowadzać jakieś dodatkowego gościa, co mi grupuje - bez łaski, bez komplikacji, bez narzutów.
No i na OO świat się nie kończy, a C++ nie jest tylko OO, jest wieloparadygmatowy. Ja mam przedstawić problem w elastycznym języku tak, jak on wygląda, a nie okrajać zagadnienie tak, żeby wpasowało się w język.
uzywanie globalnych zmiennych, metod w OOP zakrawa mi na herezje, swietokradztwo itd.
Aaaa! Ekskomuniką pewnie objęty zostanę - zwłaszcza, że i proceduralne programy mi się pisać zdarzało... oj :| Ale cóź, agnostyk jestem - heretykiem nie raz okrzyknięty zostałem, świetokradztwo niejedno w życiu popełniłem.
Faktycznie, słowa herezja i świętokradztwo dobrze dobrałeś. Z reguły słowa te padają z ust ludzi z ciasnym horyzontem, powiedziałbym fanatyków. A trzymanie się jednego paradygmatu to właśnie ciasnota umysłowa - "poza OO nie zbawienia"? Toż to używanie STLa to herezja - tam wszystko jedzie na szablonach, nigdzie polimorfizmu albo OO nie uświadczysz. Siła biblioteki standardowej C++ i Boosta tkwi w konkretyzacji wzorców, w metaprogramowaniu, a nie OO.
Sa oczywiscie sytuacje gdzie bez zmiennych statycznych nie obedzie sie (np. ten singleton) ale o zmiennych/metodach globalnych radze zapomniec.
Zapomnieć o bibliotece iostream - używa cin, cout, clog, cerr:]
A dodam, że takich globalnych obiektów może być całkiem sporo, od reprezentacji urządzeń właśnie poczynając.
A, to jeszcze jest:
jest globalna funkcja ktora cos tam sobie robi na obiektach (np. wypisz()), wszystkie te obiekty dziedzicza z jakiejs tam abstrakcyjnej klasy. W pewnym momencie chcemy zeby zachowanie tej funkcji dla jednych obiektow bylo takie a dla innych inne. W tym momencie za kazdym razem gdy dochodzi obiekt nowej klasy musimy na nowo grzebac w tej funkcji globalej
A o przeładowaniu funkcji globalnej, albo o szablonach i ich specjalizacjach pan nie słyszał oczywiście. Powiem więcej, właśnie w standardowej bibliotece funkcja "wypisz" jest globalna i wprowadzając własny obiekt wprowadza się przeładowany, globalny operator<<(ostream&, const MojaKlasa&) (najczęściej zaprzyjaźniony; o zgrozo! kolejne łamanie świętych praw OO, tym razem hermetyzacji!!!) Przypowieść twa więc ewidentnie do bani jest :]
Złota myśl na dziś: "nigdy nie przeginać pały" ;P
Złota myśl na jutro: "mikrooptymalizacja w HLLu to zło, ale czasem jest to mniejsze zło"