Witam
Co wg was jest bardziej zgodne z OOP
1 przykład:
class Game
{
KillPlayer(Player* playerAttacker, Player* playerKilled);
};
czy
2 przykład:
class Player
{
Kill(Player* player);
};
Jest to przykładowy kod gry gdzie gracz może zabić gracza
pierwszy przykład z jednej strony wydaje się być bardziej strukturalny, bo większy nacisk kładzie na czynność
drugi przykład wydaje się być bardziej obiektowy, jednak obiekt Player ma jakby trochę "zbyt dużą wiedzę",
Każdy klasę definiuje inaczej. Możesz spotkać program, który robi dokładnie to samo co twój ale klasy ma inne i co? Twój nie jest obiektowo orientowy? A może ten od tego kolesia? Tworzysz klasę a potem definiujesz OBIEKT twojego TYPU (klasy). Czyli moim zdaniem twoje klasy są jak najbardziej zgodne, co z tego, że znalazłeś inny sposób zapisania?
@Autor tematu:
@Dr Zielu:
Autor tematu ma uzasadnione obawy, Zielu. To nie tak, że jeśli tylko w projekcie używasz klas, to znaczy, że od razu korzystasz z dobrodziejstw (czy tzw. "ducha") programowania OO. Można używać klas i pisać tak naprawdę w totalnie nieobiektowy sposób!
Np. jeśli prawie wszystkie funkcje wrzucisz w klasę Game i będziesz miał pełno rzeczy typu:
// potraktujcie to jako pseudokod, nie wgryzajmy się w używanie &, * itd.
void Game::draw(Entity entity) {
// operowanie na polach entity: entity.x, entity.y, entity.polygons itp.
}
void Game::makePlayerLookAt(Player player, Entity target) {
// operowanie na player i target
}
To nie będzie to napisane w prawdziwie obiektowy, właściwy sposób.
To nie kwestia stylu. Raczej: zasad dość powszechnie używanych za właściwe.
Powyższy przykład powinien raczej zostać napisany tak:
void Entity::draw() {
// operowanie na this
}
void Player::lookAt(Entity target) {
// operowanie na this i target
}
Wspomniane zasady dotyczą m.in eliminowania tzw. "brzydkich zapachów" (pisze o tym np. Kent Beck).
Jednym z brzydkich zapasów jest "zazdrość o kod". Mamy z nim do czynienia, gdy metoda f() obiektu A intensywnie korzysta z danych obiektu B, np. przekazanego jako parametr. Taka sytuacja sugeruje, że metoda f() tak naprawdę powinna być składową obiektu B -- skoro tak bardzo potrzebuje jego danych. Dlatego w moim przykładzie przeniosłem draw() z klasy Game do Entity.
Kolejny z brzydkich zapachów to "duża klasa". Klasy powinny mieć wyważony rozmiar. Niedawno podsłyszałem w pracy, jak kumpel złapał się za głowę, bo ktoś commitował kilka klas mających ponad 300 linii kodu -- co w jego odczuciu było stanowczo zbyt wielkimi klockami.
W moim przykładzie, a także w przykładzie autora tematu, taką wielką klasą śmierdzi mi Game -- i to na kilometr. Może szybko stać się klasą, która robi wszystko. I po cholerę nam wtedy klasy, jeśli sporą część kodu mamy tak naprawdę w jednej z nich? Wrzucamy tam wszystko z lenistwa: nie chce nam się myśleć, gdzie tak naprawdę powinna się znaleźć nasza metoda, no ale od czego mamy wielki, uniwersalny wór na funkcje...
Jak mam odpowiedzieć autorowi?
Cóż, gdyby funkcja nazywała się lookAt(), to na pewno powinna być w klasie Player. W przypadku zabijania, które "wykonuje" jeden obiekt, ale które tak naprawdę bardziej wpływa na drugi obiekt (cel), sytuacja może być odrobinkę bardziej kontrowersyjna. Może by tak zaimplementować funkcję i sprawdzić, na jakich danych najczęściej operuje? Obu obiektów porówno? Jakie jeszcze metody wywołuje?
Generalnie, najlepiej by było, żeby metoda operowała na danych i metodach swojej własnej klasy. Ściślej: swojego własnego obiektu.
Jakbym miał zgadywać na pałę, bez wiedzy odnośnie implementacji i bez szerszego kontekstu, to raczej sugerowałbym sygnaturę "Player:kill(Player target)". Nie nazywałbym parametru po prostu "player", bo w C++ od tego mamy typ, natomiast chcemy przekazać, że to parametr jest zabijany.
Sytuacja w grze może być jednak inna. Niestety, mam za małe doświadczenie w pisaniu gier żeby zgadywać na rozsądnym poziomie. W momencie zabicia kogoś możemy chcieć uaktualnić planszę z punktami, lub nawet sprawdzić, czy w tym momencie gra się nie skończyła (np. w trybie Insta Death / "do złotej fragi").
Jasne-nie jasne.
Te zasady wydają się proste. Nie pisz zbyt dużych funkcji. Nie pisz zbyt dużych klas. Nie pisz kodu w jednej klasie, który korzysta intensywnie z danych innej klasy.
A jednak, ludzie tak piszą. Ludzie (stosunkowo) początkujący piszą tak wszystko i to nie dziwi, ale nawet doświadczeni programiści popełniają te błedy. Zaprojektowanie architektury aplikacji NIE jest łatwą rzeczą.
Nie wiem jakie masz doświadczenie i na jakim poziomie wtajemniczenia jesteś, ale ja już noobem od pewnego czasu nie jestem, a i tak odnajduję te brzydkie (i inne problemy) zapachy w moim kodzie. Muszę aktywnie przeglądać mój kod i refaktoryzować, by podnieść jego jakość. PODEJRZEWAM, że -- jeśli nie jesteś jakimś guru -- sam popełniasz sporo z tych "prostych" błędów. Czasami może o tym nie wiesz. Np. funkcja na 15 linii też może być za duża. Nawet funkcję na 5 linii czasem warto podzielić.
Autor prosił o radę i najwyraźniej nie potrafił zastosować do jego sytuacji tych "jasnych" zasad -- być może ich nie znał lub nie umiał zastosować. Co jest absolutnie normalne nawet u wielu stosunkowo doświadczonych programistów. Zasugerowanie autorowi odniesienia się do tych zasad uważam za cenniejsze niż zasugerowanie, że "każdy podział będzie dobry, bo jeden dzieli tak, a drugi tak", bo -- jak sam zauważyłeś -- to ostatnie nie jest prawdą. Są lepsze podziały i gorsze.
@bswierczynski: tak powinna wyglądać odpowiedź, dzięki
Swoje doświadczenie w programowaniu już mam, ale tego typu problemy, który np przedstawiłem w tym temacie są bardzo męczące, niby kod jest poprawny, ale zawsze staram się coś zrobić perfekcyjnie, a to co przytoczyłem wyżej to jeden właśnie z kilku takich co nie dają mi spokoju
a to co napisał zielu to poczułem się jakby syn uczył ojca
http://en.wikipedia.org/wiki/Solid_(object-oriented_design) - a konkretnie Single Responsibility Principle.
I tyle w temacie.
Albo można jeszcze dorzucić te zapachy kodu: http://en.wikipedia.org/wiki/Code_smell
Bardzo podobne dylematy miałem topiców parę niżej dotyczącej szachów.
Czy figura szachowa, powinna znać położenie innych figur (do generacji możliwych posunięć i zbić ?)
Z punktu widzenia obiektowego, nie do końca. W każdym razie brzydko to zaczęło wyglądać.
Z praktycznego natomiast, obejście tego stało się bardzo kłopotliwe. Stanęło na tym, że figura zna tylko swoje trajektorie, na podstawie bieżącego położenia.
Natomiast warstwa wyższa (stan_gry), która przechowuje wszystkie figury, zdecyduje jakie możliwe są przebiegi na podstawie zwróconych wektorów przez figurę (do zatwierdzenia ruchu, bądź tworzenia drzewa gry).
Mógłbym to wszystko zawrzeć w jednej klasie - nie miałbym tyle problemów, ale stała by się klasą dużą i odpowiedzialną za wszystko, co stałoby się nieczytelne.