[C++] Klasy w programie - schemat

Dla specjalistów Programowanie
#1

Witam!

Mam pytanie odnośnie struktury pewnego programu. Program ten sprzedaje kredyty (po prostu podmienia jakiś plik) i przy każdej sprzedaży zapisuje dokładną godzinę i wartość sprzedanego kredytu (w sumie do tego są 3 logi i w każdym są podobne informacje).

Aplikacja dzieli się na dwie funkcje - Sprzedawca i SuperVisor. Sprzedawca tylko sprzedaje kredyty (sprowadza się do to wywołania 1 funkcji), a SuperVisor (jest to tryb zabezpieczony hasłem) wyświetla wszystkie logi i ew. je usuwa.

Wszystko było by pięknie, tyle, że do tego dochodzą jeszcze trzy ścieżki (zapisane w plikach tekstowych, w folderze, którego lokalizacja się nigdy nie zmienia).

Są to ścieżki do:

  • :arrow: folderu z kredytami (stąd kopiuje się dany plik)

Ścieżki może modyfikować (i odczytywać) tylko SuperVisor. Żeby wszystko było jasne - oto schemat:

:arrow: http://img33.imageshack.us/img33/5336/schematb.png

W klasie Kredyt ścieżki (są to obiekty typu std::string, wczytujemy do nich ścieżki z pliku tekstowego) i funkcje do ich zmieniania są prywatne ponieważ Sprzedawca tych funkcji wywołać by nie mógł (on ma tylko sprzedawać kredyty - reszta go nie interesuje). Dlatego klasę tą zaprzyjaźniamy z SuperVisor’em.

I teraz pytanie główne: czy klasę Dziennik_zdarzen też zaprzyjaźnić z SuperVisor’em czy może w ogóle jej ścieżkę do logów (i funkcję modyfikującą) zrobić publiczną - bo obiektu typu Dziennik_zdarzen w funkcji Sprzedawca() nie definiujemy, więc nie ma ryzyka, że ktoś niepowołany się do tego dostanie :?:

Z góry wielkie dzięki za pomoc :slight_smile:

PS. Pytanie może i błahe, ale nie chciałbym nabrać złych nawyków w projektowaniu na przyszłość…

#2

Wydaje mi się, że źle zrozumiałeś sens enkapsulacji, polecam lekturę http://www.parashift.com/c+±faq-lite/classes-and-objects.html#faq-7.4 do 7.7 włącznie.

#3

Aha, czyli skoro enkapsulacja zabezpiecza przed pomyłkami (7.7) - tzn. dostępem do “wrażliwej” części klasy - więc wobec tego powinienem przenieść wszystkie funkcje modyfikujące ścieżki do części publicznej, tak :?: Bo one są stabilne, i np. w SuperVisorze wywołujemy je bezpośrednio.

Myślałem, że enkapsulacja oprócz tej ochrony części “wrażliwych” (bo o tym wiedziałem) służy też do ochrony danych i metod, do których nie można czasem uzyskać dostępu z niektórych modułów programu (funkcji “normalnych”, nie-składowych), ale jednak tak nie jest, prawda :?:

#4

Zgadza się. Jeśli chcesz faktycznej ochrony, to proces odpowiedzialny za zarządzanie dostępem musi działać w zaufanym środowisku (inna maszyna lub na prawach innego użytkownika), bo człowiek z debuggerem może dużo.

#5

Sorry, że odkopuję temat z przed miesiąca, ale termin enkapsulacja użyty w tym FAQ nie jest raczej zawsze stosowany prawidłowo.

Oznacza on jakby tylko zamknięcie czegoś w kapsułę, a określanie dostępu do pewnych jej części (składników) to ukrywanie informacji czyli stosowanie odpowiednich etykiet…