Егор

у тебя будет функционал который будет использовать объект данного класса, например

function renderPage(PageInterface $Page){
....
}

таким образом ты говоришь что объект Page должен реализовывать интерфейс PageInterface и в соответственно его методы будут востребованы в работе renderPage. Это увеличит понятность кода, и стабильность в работе.

Google - два парня Сергей Брин и Ларри Пейдж
Facebook - начал Марк Цукерберг
Instagram - два парня, один делал приложение для iPhone, другой делал сайт, потом заработали расширились
MsDOS - первую версию сделал один человек, потом Баллмер у него купил за 50 000 $ и права перешли Microsoft
Nginx - начал Игорь Сысоев
Компьютер Apple I - дело рук Стива Возняка
Linux - начал Линус Торвальдс
Git - начал Линус торвальдс
Redis - Salvatore Sanfilippo ( antirez )
Minecraft - начал Маркус Перссон ( также известный как notch )
Dropbox - начал Дрю Хьюстон
Shadertoy - создан Iñigo Quilez ( также известен как iq )
C++ - начал Бьёрн Страуструп
Python - Гвидо ван Россум
PHP - Расмус Лердорф

SimplaCMS - начал один человек
DLE CMS - начал один человек
TYPO3 CMS - начал один человек

P.S. ответ редактировался и дополнялся

www.php.net/manual/ru/language.oop5.typehinting.php

Вот так это делает symfony, думаю, что есть смысл прислушаться:

// This check prevents access to debug front controllers that are deployed by accident to production servers.
// Feel free to remove this, extend it, or make something more sophisticated.
if (isset($_SERVER['HTTP_CLIENT_IP'])
    || isset($_SERVER['HTTP_X_FORWARDED_FOR'])
    || !(in_array(@$_SERVER['REMOTE_ADDR'], array('127.0.0.1', 'fe80::1', '::1')) || php_sapi_name() === 'cli-server')
) {
    header('HTTP/1.0 403 Forbidden');
    exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}

в дополнение к ответу Sayber ⏰, есть только два разумных выбора: ActiveRecord vs Data Mapper. Все остальное - без разницы, Laravel 5 (ниже не смотрите), Symfony... с архитектурной точки зрения все едино, различия только в стандартной комплектации. У симфони это доктрина, которая исповедует несколько другие подходы.

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

Мне нравится вот такая штука, очень простая
https://github.com/typicode/json-server

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

Почему аннотации это плохо? Потому что аннотаций в PHP нет (во всяком случае пока). А то что есть - это кастыль основанный на phpdoc.

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

Есть еще одно НО. Скажем я когда-то был категорически против использования аннотаций в сущностях доктрины. Представьте себе типичный проект на symfony. У нас есть какое-то поле и мы должны написать туда минимум аннотацию для доктрины и аннотацию для валидатора. Если мы пишем апишку то появляются всякие сериализаторы и прочая чушь, документация к API и тд. Ну и собственно сам phpdoc. В итоге на одно поле сущности выходят минимум 5 строк в phpdoc с аннотациями.

Но выход из этой ситуации очевиден: перестать использовать сущности доктрины вне сервисного слоя (в контроллерах, формах и прочей чуши), валидировать только DTO, добиться того что бы модель в принципе не могла войти в невалидное состояние. И тогда остаются только аннотации для доктрины, с чем я смириться могу поскольку я ленивая ж. Валидировать же реквест или форму довольно просто.

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

https://docs.angularjs.org/guide/directive

Если мы заполним за вас, то соблаговолите разукрасить:



Updated
Черт... не думал что вы это сделаете ну... теперь не отвертеться...

.directive('', ['', function(){

что тут происходит. Первые пустые кавычки - имя директивы. Записывается в camel case, используется с нижним подчеркиванием (так уж повелось с DOM).

.directive('someDirective', fn);
// <some-directive></some-directive>

дальше, у нас есть массив, в котором одни пустые кавычки и функция. Это такой вот кастыль (по другому не выйдет сказать) что бы описать зависимости директивы. Можно заменить массив просто на функцию, но если вы будете прописывать зависимости от сервисов (например от $q) при минификации все сломается. Дело в том, что если мы явно не указали проперти $inject у функции, которую передаем, то angular будет пытаться подобрать зависимости по названиям аргументов. И тут проблемы - при минификации имена аргументов меняются и... все плохо. Потому либо явно прописываем $inject либо используем array notation, при котором сначала идут оригинальные названия сервисов, а последним элементом массива - функция, в которое это все будет инджектиться. Ну и справедливости ради - есть ng-annotate который все это автоматизирует.

По поводу пропертей, основы - link - это та функция, которая связывает конкретный DOM элемент и директиву. По сути именно тут должно происходить работа с DOM. Еще из часто используемых свойств является controller, там собственно.... контроллер, который содержит именно логику работы директивы. Контроллер может шарится между зависимыми директивами (зависимости описываются через require и описывают положение относительно других директив в DOM).

А вот compile - самое пожалуй редкоиспользуемое свойство, так как это очень специфичные задачи нужны что бы задействовать всю мощь этой штуки (обычно что-то связанное с оптимизациями).

Собственно по тому как и что писать в директивах много написано.