Cytat(MeGusta @ 15.06.2017, 22:36:30 )

extends do każdej z klas?
extends zdecydowanie nie, bo to by było nielogiczne. extends to rozszerzenie/rozbudowanie innej klasy. Ani User ani Account itd nie rozszerzają klasy Database, tylko ją wykorzystują/używają. User mógłby rozszerzać np. Person, gdzie Person miałby atrybuty "name" i "age", a User dodatkowo na przykład "email". Tak jak Samochód może rozszerzać Pojazd, albo Kotek rozszerzać Zwierzaka. Ale ani Samochód ani Kotek nie mogą rozszerzać SposobuPoruszaniaSie; mogą SposobPoruszaniaSie co najwyżej wykorzystywać. Od tego jest to co viking napisał - dependedncy injection.
Cytat(MeGusta @ 15.06.2017, 22:36:30 )

napisałem klasę Database w której są metody od połaczenia, select, update itp.
Mam w aplikacji wiele innych klas takich jak, Site, User, Account itd, nie widzę sensu aby w każdej tworzyć w konstruktorze instancję klasy Database
A właśnie że jest sens

przekazywanie zależności konstruktorem to jedna z technik tego o czym viking napisał - dependency injection.
Generalnie, to klasa Database jest pośrednikiem między innymi klasami a fizycznym źródłem danych. Jeśli User, Site, Account itd. mają być pamiętane, to muszą być świadome źródła danych - czy to będzie Database, czy FileSystem, czy Session, czy cokolwiek. To tak jak Kotek żeby łazić po płocie musi być świadomy swoich kończyn (chociażby na poziomie podświadomości

) No to mu je uświadomimy z poziomu konstruktora. Ale nie uświadomimy tego samego aparatu ruchowego każdemu Zwierzakowi. Dlatego konstruktor będzie brał jako argument jakikolwiek SposobPoruszaniaSie, który KocieLapy będą rozszerzały.
Tylko że ta technika - konstruktorem, tak jakby stawia klasie wymóg istnienia _konkretnej_ zależności. Nic w tym złego. Ale jak pomyślisz "a co jeśli nie zawsze chciałbym wykorzystywać Database do operowania Userami? Albo brać ich nie z Database a z innego źródła?". I tutaj właśnie musiałbyś skorzystać z rozszerzania (zrobić generalny opis źródła danych, który Twoja Database by rozszerzała) albo interfejsu z setterem, który wymuszałby zdefiniowanie źródła danych dla wybranych klas:
interface UstawiaczZrodloDanych
{
public setZrodloDanych();
}
class User implements UstawiaczZrodlaDanych {}
class Account implements UstawiaczZrodlaDanych {}
// ale Site nie musi:
class Site {}
Tak czy inaczej, to wszystko to przekazywanie zależności i to ma sens bo jeśli chcesz żeby klasa brała informacje z bazy, to musi o tym wiedzieć i trzeba jej to za każdym razem powiedzieć.