Pytanie o abstract i interface

Witam,

dopiero zaczynam przygode z java, oprocz pisania staram sie rowniez przegladac zrodla roznych programow, ktore gdzies uda mi sie wyszperac. Mam pytanie, poniewaz czesto spotykam sie z taka konstrukcja (przyklad uproszczony, ale oddajacy rzeczywista sytuacje):

public abstract class SomeTools {
  public abstract int someFunc1();
  public abstract double someFunc2();
}
public class ConcreteTools extends SomeTools {
  public int someFunc1() { return 1; }
  public double someFunc2() { return 3.5; }
}

Czy w takim wypadku zamiast klasy abstrakcyjnej SomeTools nie powinnismy uzyc interfejsu? Czy moze takie rozwiazaine ma jakies zalety w stosunku do interfejsu?

W przypadku ktory podales lepiej uzyc interfejs. Klase abstrakcyjna leipej uzyc gdy chcesz dostarczyc chociaz czastkowa implementacje.

IMHO, tworzenie klasy abstrakcyjnej z samymi abstrakcyjnymi metodami jest durnym pomysłem. Chcąc tę klasę wykorzystać musimy ją dziedziczyć, a wówczas nie możemy dziedziczyć żadnej innej.

Tak wlasne napisalem, tylko delikatniej ;-)
Co do samych klas abstrakcyjnych, podejrzymy jak to wyglada w bibliotekach Javy - kolekcje. Mamy interfejst java.util.List, implementuje go java.util.AbstractList (w uproszczeniu, tam jest miedzy tym jeszcze inna klasa, ale nie o to chodzi), definiujac przy okazji podstawowa funkcjonalnosc, jak dodawanie czy zwracanie iteratora. Nie okresla ona jednak w zadnym stopniu jaki powinen byc wykorzystywany wewnetrzny mechoanizm skladowania elementow - czy to tablica dynamicznie zwiekszana, czy to lista laczona? Inne, konkretne poklasy dziedzicza po niej, wlasnie dodaja taka funkcjonanosc - ArrayList, LinkedList. Jesli chcesz dodac wlasna implementacje listy mozesz wykorzystac ulatwienia ktore daje AbstractList, dziedziczac po niej, albo samemu zupelnie od poczatku wszystko zrobic, implementujac List. To jest moim zdaniem bardzo ladny przyklad.

Panowie, powoli. To jest jedno z najpopularniejszych rozwiązań. Wbrew pozorom bardzo dobrze znane i często używane. Adapter abstrakcyjny. Każdy listener w API javy ma taki odpowiednik. Jest to przydatne rozwiązanie jeżeli chcemy napisać coś co będzie implementowało tylko jedną metodę z interfejsu.

W tym przypadku metody też są oznaczone jako abstrakcyjne, więc trzeba je wszystkie zaimplementować. Gdyby były zaimplementowane przy pomocy pustych bloków, wtedy chyba moglibyśmy mówić o mechanizmie jak w listenerach

@Koziołek, adaptery ze standardowej biblioteki, to inna bajka. Ile napisałeś klas abstrakcyjnych ? Ile razy mając alternatywę klasa abstrakcyjna czy interfejs wybrałeś klasę ?

@bogdans, dość często wybieram klasy abstrakcyjne, bo są dość elastyczne. Można zrobić na przykład coś takiego:

abstract class BussinesObjectProccesor{
   public void bussinesMethod(List<BObject> bol){
      for(BObject bo : bol )
        proccess(bo);
   }

   public abstract void proccess(BObject bo);
}

Dużo rzeczy, które pisze ma to do siebie, że zmieniają się niewielkie elementy algorytmu lub algorytmy przetwarzania są podobne. W klasie abstrakcyjnej umieszczam proces główny, a implementacje jego elementów w klasach dziedziczących.

@koziolek
Twoj przyklad nie jest alternatywa dla interfejsu bo ma implementacje, nie o to pytal Bogdans.