DevMan

не существует.
ООП – это не создать приложение. ООП – это понять концепцию и прокачать ее.

создание одного приложения по книжке или другому уроку(ам) никак не поможет в освоении. здесь нужна продолжительная практика.

интерфейс даёт гарантию, что описанные в нем методы реализованны в классе.

покурите тему интерфейсов в целом, и тег ООП на тостере в частности - этот вопрос задавался уже 100писот раз.

ФП – вообще про другое.
MVC – просто подход. спокойно реализуется и без ООП.

ООП – это управление сложностью/декомпозиция.
если вы делаете разовую маленькую задачу, заморачиваться им нет смысла.

public static $var = 25; и есть "значением по умолчанию".

это же классический синглтон.
при чем реализованный через опу.

включите вывод ошибок. у вас как минимум неверное обращение к свойствам (использование $ в имени).

как удобно лично вам, так и правильно. единственного верного подхода не существует - понятия о прекрасном весьма индивидуальны.

в чем вопрос то?
public function createAddress(Address $address)
явно прописывает тип аргумента и ругается когда ему суют не его.
не нравится? уберите/поменяйте тип.

на вскидку:

class ModelB extends ModelA
{
    public function __construct() {
    parent::__construct();
    var_dump($this->a);
    }
}

https://developer.mozilla.org/en-US/docs/Web/JavaS...

тащемта их завезли ещё в пхп5.
в 7.1 прост расширили их действие на константы.

pdo достаточно примитивен, и особо прокачаться на нём не выйдет.

но если вы напишите врапер, который вам будет более удобен, чем сырой pdo, то вперёд.

Никак. Вы создаёте 2 отдельные переменные, поэтому нужны два действия.

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

нет никакой разницы статический метод или нет: если он возвращает объект, то можно чейнить.
самый примитивный пример - ideone.com/Nr4MgL

1. какой смысл заливать код куда-то, если результат его работы удобнее и быстрее смотреть локально?
2. error_reporting(E_ALL) - это здорово, а print_r/var_dump - это быдло-стайл. ибо есть xdebug.
3. удобная среда разработки - интегрированный отладчик, комплит, всевозможные подсказки.
только на этих пунктах можно уже здОрово сократить время написания/отладки кода.

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

как выбрать среду разработки? попробовать разные и выбрать.
фреймворк? попробовать разные и выбрать.
архитектуру? надо знать какие есть вообще и уметь их применять.
залипаю в хабр? это нормально залипать если у тебя не хватает знаний. чем больше знаний и опыта тем меньше необходимость залипать.
всё работает, но не идеально? ограничь свой пыл: идеал трудно достижим и зачастую не нужен.

итого: учиться и практиковать. сорян, но программистом быть непросто, а волшебной пилюли у меня нет.

Вот так не работает, но по синтаксису PHP вроде логично.

ибо

This declaration may include an initialization, but this initialization must be a constant value--that is, it must be able to be evaluated at compile time and must not depend on run-time information in order to be evaluated.

соглашаться или нет - дело ваше. только в реале это ничего не изменит.

Подскажите что делать?

как минимум исправить odj на obj и включить вывод ошибок.

метод должен возвращать указатель на инстанс: в конце метода должно быть return $this;

https://en.wikipedia.org/wiki/Method_chaining#PHP

нет такого костыля, который не сможет придумать пхпешник.
- создайте базовый абстрактный класс, от которого дальше наследуйтесь
- https://ru.wikipedia.org/wiki/Декоратор_(шаблон_пр...
- runkit
- ответ D' Normalization

но все это в данном случае нахер не упало: удобнее редактировать класс (с автокомплитом и прочими ништяками), а не 100500 отдельных функций, размазанных ровным слоем по диску.

вы возвращаете в пустоту:

firstarray = getsomething1()
secondarray = getsomething2()
getsomething3(firstarray, secondarray)

или
getsomething3(getsomething1(), getsomething2())