class class1{	
		function f_1__c_1(){
;
			}
		function f_2__c_1(){
		 $obj_2 = 	new class2();
		}
	}
		
	 class class2{
		function f_1__c_2(){
;
		}
	}

1) оператору new, вообще не чего делать в функициях... Советую почитать Clean Code Development.

2) Для вызова метода других классов требуется инстанции других объектов.

Например :

class class2
{
    private $instanceClasse1;
   
    public function __construct(class1 $object)
    {
        $this->instanceClasse1 =  $object;
    }
   
    function f_1__c_2()
    {
        return $this->instanceClasse1->f_1__c_1();
    }
}

_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

class class1{	

1) оператору new, вообще не чего делать в функициях... Советую почитать Clean Code Development.

а как тогда быть например с порождающими паттеранми например? я просто понять не могу.... порождение и есть по сути результат действия new. Что то не пойму никак

class class1{	
		function f_1__c_1(){
;
			}
		function f_2__c_1(){
		 $obj_2 = 	new class2();
		}
	}
		
	 class class2{
		function f_1__c_2(){
;
		}
	}

А статикой сделать метод класса 2?

class class2 extends class1 {}

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Порождени с оператором new делается или в factrory или в грязном контроллере, хотя любые серьёзные библиотеки имеющие DependencyInjectionContainer имеют возможность конфигурировать параметры .
Проблема в том, что при написание библиотек всегда требуется возможность их тестирования. Как только начинаешь заниматься тестированием, то понимаешь, что тебе нужна возможность заменять участки кода в твоей программе и тестировать отдельно тестировать функционал f_2__c_1() да так, что бы не зависить на прямую от класса class2 который ты вызываешь при помощи new... По этому class2 надо передовать по возможности как параметр, Это тебе даст возможность заменить инснацию этого класса не меняя кода самого класса.

Как то так...


_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

Ну композицию вроде не трогали
В любом случае, компосиция лучше чем наследовоательность, опять же благодаря тому, что при тестирование не обязательно тестировать парент класс... и сам парент класс можно заменить прямо в runtime.


_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

почему лучше?

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

1) парент класс заменяется в любой момент прямо во время протикания самой программы.
2) парент класс тестируется без участвия наследников.


_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

https://github.com/Codeception/AspectMock

Мокает всё, включая нативные php функции.

Но лучше ориентироваться на то, чтобы бизнес-логика не зависила от слоя приложения/фреймворка и обложить её абстракциями от источника данных (бд/фс/озу/api). Если это постоянно держать в голове, код сам собой нормально спроектируется.

Если есть возможность перенести бизнес логику внутрь другого приложения/фреймворка не изменяя её код и написав расходники ввиде контроллеров/репозиториев всё заработает в новом окружении, тогда всё в порядке.

Пытаться использовать dependency injection везде в своем коде - избыточно и не имеет смысла. Внедрять зависимости в бизнес-логику - это правильно. Юнит-тестами покрывать нужно именно её.

В контроллерах и в остальном коде уровня приложения можно свободно использовать оператор new и не думать о lose coupling, поскольку этот код уже тесно связан с приложением/фреймворком и делать в него внедрение зависимостей бессмысленно. Такой код не принято покрывать юнит-тестами, он очень простой и может постоянно меняться, например когда мигрируем на новую мажорную версию приложения/фреймворка. И это верно, было бы глупо при каждой такой миграции переписывать юнит-тесты. Для этого пишут уже функциональные тесты.