Witam,

Mam klase A która dziedziczy bo klasie B. Dziedziczy dlatego, że potrzebuje wywołać metode z klasy B w klasie A. Czyli muszę includowac pierwsze plik z klasa B a pózniej A.

Teraz mam inny przypadek, że w klasie A nie potrzebuje metod z klasy B ale i tak A dziedziczy wiec musze includowac plik z klasa B a nie jest mi ona w tym momencie potrzebna.

Da sie to jakoś ominać?

to jeszcze zależy czy potrzebujesz pól z klasy nadrzędnej,
jeśli nie - to osieroć klasę A, niech nie dziedziczy po B.

W jednym przypadku potrzebuje w drugim nie.
Jak sie osieraca klase? (nie chodzi o wymazanie extends)

No miałem na myśli wymazanie extends,
ale skoro w jakimś tam przypadku potrzebujesz
to chyba nie ma sensu osieracać na klasy.
Na dziedziczenie patrzy się całościowo, więc to że gdzieś tam nie używasz
metod rodzica nie znaczy że musisz zaraz przekształcać
całą klasę

W sumie moge usunąć extends. W klasie A includowac plik z klasa B, stworzyc obiekt klasy B wywolac metode... ale czy to bedzie poprawnie?

Jak tak to po co w ogole dziedziczyć?

Tak ale musze includowac plik z klasa B a po co jak jej w ogole nie używam w danym momencie?

Musisz zrozumieć, że dziedziczenie stosuje się po to aby kod miał różne poziomy abstrakcji - tak aby można było programować dla interfejsu a nie dla instancji. Stosowanie dziedziczenia po to aby "zaoszczędzić" sobie pisania jest kompletnie niezgodne z regułami OOP. Nie możesz mieć klasy która raz coś dziedziczy a raz nie.

Co do Twojego pytania nr 2 - tak jak najbardziej poprawne jest tworzenie instancji klasy a w klasie b czy tam odwrotnie. Nie ma w tym nic złego. To czy zastosujesz dziedziczenie czy kompozycję zależy tylko i wyłącznie o logicznych powiązań między klasami.

Np. Jeśli masz klasę Silnik i Samochód - to co prawda będziesz w klasie samochód potrzebował metod klasy silnik, ale nie znaczy to, że Samochód będzie dziedziczył po silniku. Tu zachodzi raczej relacja Samochód ma Silnik.

Właśnie, że będzie dziedziczył silnik,
dany silnik może być wykorzystany w różnych modelach samochodu,
tak samo możesz mieć np klasę Label
i dziedziczącą po niej klasę Link, która ze swojej strony dodaje jedynie
kolor podkreślenie i link

No wlasnie, silnik moze byc wykorzystywany, czyli powinien wchodzic w sklad samochodu (klasy), a nie ze mamy po nim dziedziczyc. Przeciez samochod sklada sie tez z kol, to co, mamy tez dzieczyc po klasie kola? Przeciez mozna dziedziczyc bezposrednio tylko z jednej klasy.
No chyba zebys sie uparl i pojechal po interfejsach, ktorych dana klasa moze implementowac kilka.

Jest dokładnie tak jak mówi nospor i nie tylko dlatego że jest tu szefem

Trzeba rozróżnić dziedziczenie od składania obiektu z innych obiektów. W tym przykładzie samochód nie jest silnikiem -> wyobraź sobie taką konstrukcję.

[PHP] pobierz, plaintext 
<?php
if (objSamochod instanceof Silnik)
{
 //jakaś akcja
}
?>
[PHP] pobierz, plaintext 

Gwarantuje Ci, że po powrocie do takiego kodu za 3 miesiące będziesz się zastanawiał o co chodzi. Pewnie że zachodzi pokusa dziedziczenia po silniku - bo zmniejsza to ilość kodu, którą trzeba napisać. Niestety niesie to ze sobą wiele zagrożeń takich jak brak logiki czy trudność konserwacji. Co jeśli np. okaże się, że każdy samochód ma inny silnik? Zrobisz w klasie silnik mnóstwo switchy? Obiektami zawsze należy starać się odzwierciedlać rzeczywiste relacje jakie zachodzą w życiu czyli w tym przypadku "samochód MA Silnik" a nie "samochód JEST silnikiem".

wlasnie ze nie bedzie dziedziczyl, w klasie samochod masz caly zestaw obiektow, np kolo, silnik, skryzniaBiegow itd + ekstra dodajesz te wlasciwosci ktorych nie maja czesci osobno, np Vmax, przyspieszenie, wage itp

Zawsze można zastosować kompozycję. Skoro nie chcesz dziedziczyć, wywołuj instancję klasy B w klasie A i operuj na niej w metodach.
Tak jak ktoś napisał wcześniej, na dziedziczenie patrzy się całościowo. Ma ono uzbrajać klasę w dodatkowe metody, rozszerzać o dodatkową funkcjonalność, w taki sposób, by było to jak najbardziej opłacalne.