Mam klase administrator ktora tworzy ksiazki w klasie spis ksiazek.
Mam tez klase bibliotekarz ktora szuka ksiazek w spisie ksiazek ale nie moze dodawać ksiazek.
Teraz chciałbym ukryć funkcje dodawania ksiazek, a pozostawic jedynie spis. Mógłbym użyć interfejsu ale wtedy programista mógłby użyć rzutowania i bibliotekarz mógłby dodawać ksiązki...
Czy można to jakoś rozwiązać ? Czy ja dobrze rozumuje czy za bardzo staram się ograniczyć wolność programisty ?
Na przykład w Javie metody oznaczone jako private nie są widoczne nigdzie poza klasą. Nie pomaga nawet rzutowanie.
W cpp też ;)
axb napisał(a)
za bardzo staram się ograniczyć wolność programisty ?
programista powinien tez miec rozum. powinna tez istniec dokumentacja w ktorej sa opisane rozwiazania architektoniczne i przedstawiony przydzial obowiazkow dla poszczegolnych elementow systemu :) i to one powinny dyktowac co komu wolno i jak.
tak dla formalnosci: nawet 'private' nie uchroni nikogo przed zwariowanym programista.. jak sie uprze, to da rade i kropka, zwlaszcza w c++ :)
quetzalcoatl napisał(a)
programista powinien tez miec rozum. powinna tez istniec dokumentacja w ktorej sa opisane rozwiazania architektoniczne i przedstawiony przydzial obowiazkow dla poszczegolnych elementow systemu :) i to one powinny dyktowac co komu wolno i jak.
Całkowicie nie zgadzam się z przedmówcą. System powinien być tak tworzony, aby programista konfigurował działanie klasy/komponentu/modułu, a nie o nim decydował. Jeśli czegoś nie wolno, to zadaniem klasy jest do tego nie dopuścić. Oczywiście, jak ktoś się uprze, to cel osiągnie, ale działanie powinno być takie, by - w warunkach normalnej pracy - nie dopuścić do niepożądanych sytuacji.
@quetzalcoatl, @Szczawik, zapomnieliście o jednej bardzo ważnej rzeczy, która w dość dobry sposób chroni przed wariatami. Programujemy za pomocą interfejsów, a nie klas. Obiekt, moduł, komponent powinien udostępniać dobrze zdefiniowany interfejs i to właśnie on powinien być wykorzystywany. Do dokumentacji dla użytkownika wrzuca się tylko informacje o interfejsie, a szczegóły implementacji pomija się milczeniem.
to nie chroni przed maniakami majacymi reverserskie zaciecie :))
innymi slowy, muhahahha, znasz JAD ' a ? :))
Po prostu wierzę, że moduł jest bezpieczny, jeśli ktoś, mając do niego kod źródłowy, nie jest w stanie z użyciem standardowych metod go wykrzaczyć.
Koziołek napisał(a)
Mógłbym użyć interfejsu ale wtedy programista mógłby użyć rzutowania i bibliotekarz mógłby dodawać ksiązki
Takie rzutowanie nie spowodowałoby, że bibliotekarz mógłby dodawać ksiązki.
Przecież klasa bibliotekarz nie miałaby implementacji metody do dodawania książek.
Poleciałby wyjątek albo przy samym rzutowaniu, albo przy wywołaniu metody.(W Javie chyba to drugie -NoSuchMetodException, jeżeli dobrze pamiętam)
@__krzysiek85, zły autor cytatu :) powinien być axb
@Szczawik, dużo zależy od języka. W Cpp zapewne dało by sie dość szybko wychwycić dziury związane z pamięcią czy z przepływem sterowania. W Javie odpadają metody wywalania związane z pamięcią (poza tradycyjnymi outofmemory). Można by pokombinować z nullpointerami, ale dobry kod też jest na to uodporniony. Można by też poszukać jakiś wycieków w aplikacjach wielowątkowych..