Klasy abstrakcyjne oraz sposob wykonywania metod - JS

Question

Witam,

 

1. Czy dobrym rozwiazaniem jest gdy klasa abstrakcyjna dziedziczy po innej klasie abstrakcyjnej?

 

przykladowo: czlowiek (abstrakcyjna) > zolnierz (abstrakcyjna) > snajper (normalna z mozliwoscia stworzenia obieku w oparciu o nia)

 

2. Dobrym rozwiazaniem jest, gdy AI sterujacy postacia (obiektem) jest umieszczone w jego wlasnej metodzie, z ktorej odpala automaycznie inne metody, ktore po zakonczeniu przetwarzania wykonuja metoda AI itd. w nieskonczonosc.

...

this.ai = function () {

if(...) {this.move}
else if(...) {this.shoot}
else {this.heal}


}

this.move = function(){

// dosth

setTimeout(this.ai(),1000); // pod warunkiem jesli chce dodac odstep czasu 1s

// lub this.ai(); // jesli bez odstepu sekundy.
}

...

 

Answer 1

przykladowo: czlowiek (abstrakcyjna) > zolnierz (abstrakcyjna) > snajper 

Jeśli taka struktura jest Ci potrzebna to dlaczego nie. Masz dzięki temu specyficzne zachowania żołnierza odseparowane od człowieka, a jeśli w Twoim programie żołnierz ma być człowiekiem to jest to jak najbardziej prawidłowe. Tutaj wszystko zależy od potrzeb aplikacji i ewentualnie czy tak skomplikowana struktura jest rzeczywiście konieczna.

Dzięki takiej abstrakcji możesz uogólniać pewne elementy innych rzeczy np. wstawianie snajpera lub sapera na planszę w grze w zasadzie będzie identyczne. Jeśli nie miałbyś odpowiedniej struktury danych tylko pojedyncze klasy Snajper i Saper to musiałbyś zrobić dwie praktycznie identyczne metody klasy Plansza, a różnicą byłby tylko typ przyjmowanego argumentu (JS za bardzo nie znam więc zastosuje notację języka Java):

class Plansza
{
	void wstawSapera(Saper saper) { 
		//cos tam
    }
     void wstawSnajpera(Snajper snajper) { 
		//praktycznie bedzie to samo co dla wstawSapera
	}
}

Powiedzmy, że kiedy masz tylko dwie klasy Snajper i Saper to jakoś to działa i jesteśmy w stanie przegryźć ten zdublowany kod. Tylko co w sytuacji kiedy nagle wymyślmy nowy typ żołnierza np. Medyk lub po prostu jest ich więcej - trzeba będzie dopisać kolejną wersję metody wstawXXX do klasy Plansza - do kitu. Dzięki polimorfizmie i dziedziczeniu można uogólnić wstawianie żołnierza na plansze stosując abstrakcje w postaci ogólnej klasy Żołnierz.

class Plansza
{
	void wstawZolnierza(Zolnierz zolnierz)
	{
		//implementacja
	}
}

Piękna sprawa, dodaje nowy typ żołnierza do projektu a plansza nadal działa tak samo.

Idąc dalej można jeszcze bardziej uogólniać metodę wstaw jeśli będzie to konieczne bo np. ogólnie wstawianie Człowieka na planszę będzie wyglądało tak samo jak Żołnierza, Policjanta, Strażaka, Listonosza:

class Plansza
{
	void wstaw(Czlowiek czlowiek)
	{
		//implementacja
	}
}

Abstrakcyjne klasy w takich hierarchiach są odpowiednikami czegoś bardzo ogólnego czego nie da się jednoznacznie skonkretyzować. Jak ktoś Cię zapyta czy masz zwierze domowe i odpowiesz "tak mam psa" - to czy po tym jest wstanie wyobrazić sobie tego psa? Raczej nie. Więc potem dopytuje Cię o szczegóły tego psa, a Ty odpowiadasz "no ten pies biega, szczeka". Osoba pytająca nadal nie wie jakiego masz tego psa, ale mówisz "to jest owczarek niemiecki długowłosy" - i już wiadomo o co chodzi - da się go konkretnie wyobrazić. Pies jest abstrakcyjnym elementem, którego nie da się jednoznacznie wyobrazić (utworzyć) natomiast owczarek niemiecki długowłosy będzie obiektem konkretnym bo da się go jednoznacznie wyobrazić (utworzyć).