witam mam pytanie zapewne banalne i wiele osob zadrwi ze mnie ale ze dopiero stawiam pierwsze kroki w OOP mam takie pytanie

jezeli mam klase do A i w niej jakies metody i teraz w klasie B chcę uzyc metody z klasy A to czy mozna to zrobic?? i jak to zrobic?? czy tu chodzi o dziedziczenie?? prosilbym moze o jakis prosty przyklad

Można, przez dziedziczenie (klasa B dziedziczy po klasie A), zawarcie instancji klasy A w klasie B albo uczynienie metodę klasy A statyczna:

[PHP] pobierz, plaintext 
<?php
class A {
	public function methodA()
	{
		 print __METHOD__.PHP_EOL;
	}
}
 
class B extends A {
	public function methodB()
	{
		 $this->methodA(); // A::methodA() jest również zwyczajnie dostępna jako metoda klasy B (bo jest publiczna;
	}
}
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
class A {
	public function methodA()
	{
		 print __METHOD__.PHP_EOL;
	}
}
 
class B {
	/*
	 * @var A
	 */
	private $_A;
 
	public function __construct()
	{
		$this->_A = new A();
	}
 
	public function methodB()
	{
		 $this->A->methodA();
	}
}
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
class A {
	public static function methodA()
	{
		 print __METHOD__.PHP_EOL;
	}
}
 
class B {
	public function methodB()
	{
		 A::methodA();
	}
}
?>
[PHP] pobierz, plaintext 

edit:

Oczywiście każde z tych rozwiązań posiada plusy i minusy.. trzeba wybrać odpowiednio do potrzeb.

a mam jeszcze jedno pytanie co powinno sie umieszczac w konstruktorze??

Jeżeli to pytanie do moich przykładów to na pewno w konstruktorze trzeba inicjalizować zmienne przechowujące instancje.

to pytanie ogolnie jak mam klase do rejestracji uzytkownikow to co powinno byc w konstruktorze??

Ja bym to zrobił tak, że napisałbym klasę UsersManager, która mogłaby zawierać metody add, edit, delete etc. i zrzucić te funkcje z klasy User. Konstruktor klasy UsersManager zostawiłbym pusty dopiero do metod przekazywałbym parametry. No ale ja dopiero zaczynam OOP więc moje podejście może być złe

Nie możesz zadawać takich pytań. Sprawa implementacji jest kwestią indywidualną.
Napisz jakiś kod, a na pewno znajdziesz pomoc, żeby poprawic, ulepszyc etc.

edit:
Ktoś wspomniał o managerze.. a ja rejestrację (jako najmniejsza składową np. wpis do bazy) umieściłbym w klasie User odpowiedzialnej za logikę działań na danych poszczególnego użytkownika.

edit:


A ja sama rejestracje widzę już jako logikę strony/serwisu... pewnie dlatego, że za bardzo myślę wg MVC





Po zastanowieniu, mogę stwierdzić, że jakkolwiek to zaimplementujesz najważniejszym jest, żeby działało. Różne sposoby (wzorce) kodowania "wymuszają" na programiście używanie pewnych utartych schematów. Jedyna nadzieja w zatarciu różnic to coraz lepsze poznawanie, a co najważniejsze zrozumienie OOP - wydaje mi się, że na samym końcu tej drogi, wszyscy dochodzą do tych samych wniosków.

W konstruktorze umieszcza się kod tworzący obiekt. Mówiąc po ludzku, po wykonaniu konstruktora obiekt musi być gotowy do przyjmowania poleceń. Czyli jak masz klasę do rejestracji użytkowników, to pewnie łączy się ona z bazą danych. Z tego można wyciągnąć wniosek, że w konstruktorze musisz przygotować połączenie z bazą (przekazać referencję do obiektu będącego interfejsem używanego dbms albo utworzyć nowy uchwyt). Wszystkie atrybuty klasy muszą zostać też przygotowane.

Można też kwestię przygotowania obiektu zrzucić na wywołania jego metod konfiguracyjnych, zamiast używać do tego konstruktora. Taka polityka sprawdza się, gdy nasz obiekt jest zależny od innych obiektów. np.
Zamiast robić tak:

[PHP] pobierz, plaintext 
<?php
class User{
 
function __construct($id, $name, $accessType){}
}
?>
[PHP] pobierz, plaintext 

można

[PHP] pobierz, plaintext 
<?php
class User{
 
function __construct($id){ //jakkeś unikalne id
}
 
function setName($name){}
function setAccessType($accessType){}
 
}
?>
[PHP] pobierz, plaintext 

Wszystko oczywiście zależy od okoliczności : )

Pozdrawiam.

Tylko użycie metod konfiguracyjnych narzuca sposób korzystania z obiektu. Zanim wywołasz jakąkolwiek inną metodę, wpierw musisz wywołać konfiguracyjne. Trzeba się pilnować, żeby o tym nie zapomnieć... Konstruktor zwalnia trochę z myślenia.

Oczywiście. Niektóre obiekty (np. obiekty używane jedynie przez framework) można w ten sposób "podnosić", inne już nie, bo API stałoby się zbyt skomplikowane. Zresztą - nic nie stoi na przeszkodzie w wykorzystaniu obu możliwości jednocześnie : >

Zawsze mozna tez stworzyc cos ala przeciazanie. W zaleznosci od ilosci parametrow podanych przy tworzeniu obiektu wywolujemy inne metody.

nalezalo by tez wspomniec o slowku parent nie pede pisal o co chodzi zapodam tylko przyklad

[PHP] pobierz, plaintext 
<?php
class A {
	public function method()
	{
		 print __METHOD__.PHP_EOL;
	}
}
 
class B extends A {
	public function method()
	{
		 print __METHOD__.PHP_EOL;
		 parent::method();
	}
}
?>
[PHP] pobierz, plaintext