Metody abstrakcyjne vs interface

0

Nie bardzo rozumiem po co tworzyć metody abstrakcyjne zamiast tego rozbić na samą klasę bazową + interface. Mógłby mi ktoś to rozświetlić?

*Tak, przeczytałem już trochę postów na stackoverflow itp. Wiem mniej więcej jaka jest różnica pomiędzy tymi dwoma bytami, ale to jedno pytanie nie daje mi spokoju *

abstract class Player
{
    // some base properties
	// and methods that i want to inherit
    abstract void Play();
} 

class VideoPlayer extends Player
{
    void Play()
    {
      //Some code.
    }
}

class MusicPlayer extends Player
{
    void Play()
    {
      //Some code.
    }
}

// ====================================== // 


interface IPlayable 
{
	void Play();
}

abstract class Player
{
    // some base properties
	// and methods that i want to inherit
} 

class VideoPlayer extends Player implements IPlayable
{
    void Play()
    {
      //Some code.
    }
}

class MusicPlayer extends Player implements IPlayable
{
    void Play()
    {
      //Some code.
    }
}
2

Lekcja na dziś: template method.

3

posiadanie zarowno wspolnej klasy bazowej jak i abstrakcyjnej dla Video i Music playera nie wydaje mi sie dobrym pomyslem. interfejs Player (lub jesli wolisz IPlayer) jak najbardziej moze i powinien byc wspolny, ale jesli chodzi o implementacje to tak srednio, imo lepiej zastosowac kompozycje niz dziedziczenie w tym wypadku.

0

posiadanie zarowno wspolnej klasy bazowej jak i abstrakcyjnej dla Video i Music playera nie wydaje mi sie dobrym pomyslem.
Czy to oznacza, że bazowa klasa abstrakcyjna to ogólnie zły pomysł, czy tylko w tym wypadku?

0

Tylko w tym przypadku

1

nie lubie dziedziczenia bo zazwyczaj wynika z lenistwa (zamiast stworzyc nowa klase, latwiej odziedziczyc to co chcemy i dodac/odjac pare rzeczy, po pewnym czasie konczy sie wielkim burdelem).
w tym konkretnym wypadku nie widze argumentu za dziedziczeniem, lepiej zrobic 2 klasy MoviePlayer i MusicPlayer implementujace Player + jakies dodatkowe klasy ktore maja ich czesc wspolna

1

Nie demonizowałbym, czasem dziedziczenie ma sens, a czasem go nie ma ;) Robienie delegacji na siłę też bywa głupie, bo potem się nagle okazuje że mamy klasę która deleguje 100 wywołań metod a jedną nadpisuje i ewidentnie należało tutaj dziedziczyć.

1
katelx napisał(a):

nie lubie dziedziczenia bo zazwyczaj wynika z lenistwa (zamiast stworzyc nowa klase, latwiej odziedziczyc to co chcemy i dodac/odjac pare rzeczy, po pewnym czasie konczy sie wielkim burdelem).

Ale to burdel w kodzie wynika z lenistwa, a nie dziedziczenie. Dziedziczenie to mechanizm, który ma swoje sensowne zastosowania, a to, że ktoś tego źle używa, to już nie dziedziczenia wina.

0

generalnie dobre pytanie. I generalnie należy preferować kompozycje (interfejsy) od dziedziczenia. Ale jak zostało wcześniej napisane - to zakazy od konkretnego przypadku. Często dziedziczenie jest przydatne, ale nigdy nie powinno być używane tak, jak zresztą już odradza @katelx

0

nie twierdze ze sam mechanizm w sobie jest zly, tak jak nie sa zle np. switche, po prostu czesto sie spotykam z naduzywaniem takich konstrukcji i mysle ze swiat bylby lepszym miejscem gdyby to kompozycja byla rozwazana jako domyslne rozwiazanie a dziedziczenie dopiero po solidnym przemysleniu.
a tak to wychodza pozniej takie kwiatki ze w klasie bazowej jest if na typ tego co zwraca metoda wirtualna ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1