hack504

parent::foo()

Да, носят чисто декларативный характер. Но в проектировании и при разработке в команде разработчиков очень сильно нужОн. Например, у нас есть некая сущность Тариф, от которой порождены конкретные реализации (Акционный, лимитный, безлимитный, специальный - не суть ) - их может что-то объединять/разделять. Поэтому, когда я пишу некий класс который как-то взаимодействует с Тарифом с определенным признаком, то я явно могу указать это создав специальный Интерфейс и запросить именно экземпляр класса конкретно этого интерфейса, а не родительского класса:

public function __construct(IDiscountByDay $Tariff){}

Далее уже сделать имплементацию этого интерфейса на всех наследниках класса Tariff где нужно, и не парится, что через какое-то время другой разработчик создаст новую реализацию тарифа и с твоего кода посыпятся баги

Если нужно работать в рамках одного экземпляра класса то можно попробовать так

class A{
  public $val = 10;
  public function method1(){
    $m2 = new B($this);
    return $m2->method2();
  }
}

class B {
  public function __construct($obj) {$this->obj = $obj;}
  public function method2(){
    return $this->obj->val + 1;
  }
}

$a = new A();
echo $a->method1();

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

Нигде. В парадигме ООП и снежинка и варежка и сцена - описывают только свое поведение методами и свойствами. Введите ещё одну абстракцию - мир(или физика), которая содержит все эти объекты и описывает поведение их взаимодействия.
Сцена детектит столкновение снежинкой и варяжкой - передает миру, а тот в свою очередь удаляет снежинку, запускает анимацию варяжке, запускает в сцене радостный звуковой щелчок.
Таким образом, если в дальнейшем реализовывать дополнение "Грачи прилетели", то легко реализуется логика столкновения варяжки и помета => помёт остается, варяжка замирает, в сцене грустный звук "ооу"