А в чем проблема получить программисту API достаточно информации для обработки исключений?
Или проблемы нет, и Ваше утверждение просто ставит под сомнение содержание статьи?
Вас интересовал курс современных фреймворков — я описал свое мнение. Прямых утверждений касательно ваших взглядов в моем комментарии нет, к чему негатив?
Кодогенерация как и в первых версия была, так и во вторых есть. Если вас интересует тема скаффолдинга в ZF2, увы, статья не про это.
А Ваш продукт на симфони 1.4 будет все же уступать аналогичному на sf2, как и продукт на zf1 будет уступать продукту на zf2 по причинам описанных мною выше.
Суть статьи — показать пример разработки готового модуля, а не написать полноценный блог.
Как опытный разработчик, вы должны понимать, что с ростом функциональности системы и объема кода она (система) становиться неуправляемой. При должной структуризации кода этот момент откладывается (почти) на неопределенное время, вполне возможно до конца актуальности самой системы.
Простой блог как в статье, на чистом PHP, где код написан в хардкорном стиле «здесь и сейчас» можно вложится в несколько экранов, но сопровождение кода в гораздо сложных проектах будет излишне дорого для бизнеса.
Курс современных фреймворков состоит в понижении сопряжения компонентов, из чего следует минимизация сложности, снижение количества ошибок, уже далее простота разработки и сопровождения ПО.
Поэтому ответ на ваш (может быть риторический) вопрос: да, надо. Но прежде всего нужно помнить: для каждой задачи должен быть осознанно применен свой инструмент.
С англ у меня пока не сложилось, но русский перевод мне не понравился вообще, например в самом начале книги: «Действия, в которых ум проявляет свои способности в отношении своих простых идей, суть главным образом следующие три: 1) Соединение нескольких простых идей в одну сложную; так образовались все сложные идеи». Может дальше лучше, но я попробую читать в англ варианте.
Мне казалось что бурление зависит не столько от возраста, сколько от характера. Согласен, с возрастом что-то остывает, но быть усидчивым (выполнять работу от а до я) и молодым — вполне независимые вещи.
Вот и я о том же, сервисы (слой сервисов) тут ни при чем. Т.е. ServiceContainer хранит на самом деле не сервисы, а произвольные пользовательские объекты? Если да, то в чем тогда отличие от DIC? DIC тоже хранит пользовательские объекты, и автоматом по перому требованию инициализирует зависимости.
Начал читать второй ваш абзац, и понимать разницу между DI и Service locator. Dependecy Injection — это паттерн, при котором необходимые зависимости содержаться как свойства зависимого класса, а Service locator — при котором зависимый класс является ServiceLocatorAware и получает зависимости у контейнера напрамую.
Есть вопрос. Даже два.
1. В статье, как пример реализации паттерна Service locator, написан ServiceContainer, он хранит все пользовательские объекты. Так почему же он называется ServiceContainer? В нем не храняться классы-сервисы, которые как раз и вводят слой сервисов. Он просто используется для разруливания зависимостей под капотом.
2. DIC — это реализация паттерна Service locator?
Не обобщайте. Всегда хватает школьников и не очень, которые любят срать, да. Мне все-равно кто у кого что заимствует, главное — чтобы мне было удобно. Apple что-то копирует, Samsung что-то копирует — объединяют усилия, скоро получиться эталонная ОС — это хорошо.
А фанбоев трогать не надо, они сами между собой пусть сраться, мы же давайте обсудим сильные и слабые стороны того, что было сделано.
Все очень спорно, конечно же.
Я могу согласится, что некоторые иконки и вправду убогие, но общая стилистика сохранилась, и что самое важное — удобство и комфорт работы (имхо) не пострадает.
Вот сравните хоум скрин iOS 7 и WP8.
У WP8 фишка в плитках, есть несколько цветовых вариантов, но чаще всего по 2-4 плитки одного цвета. У iOS — пестро, ярко, много цветов, но все иконки «индивидуальны». Если («размыть» |посмотреть сдалека) оба домашних экрана, то узнавание и расположения элементов будет у iOS значительно лучше. Так и наш мозг воспринимает это. Иконки узнаваемы, их легче найти, повышается скорость работы, нет раздражения от неодобства.
Вот (почти) все сравнивают с конкурентными ОС, кто у кого что скопировал. Ну скопировали notification bar у Андроида, да. Но это удобно, а главное же — сделать систему удобной! И при всем этом придумывать что-то свое.
Согласен, что реализация FluentInterface на АОП — не самая лучшая затея хотя бы с точки зрения логичности: наличие конструкции implements SomeInterface предполагает то, что класс будет содержать код реализующий интерфейс, чего при этом подходе нет.
Ну, вполне возможен вариант работы с 30к объектами в пределах одной сессии скрипта + инициализации каждого (объекта) десяткой сеттеров.
С другой стороны, может такие приложения не на PHP нужно писать (1), а также даже этот оверхед будет очень мал по сравнению с логикой работы приложения, которое оперирует таким количеством объектов (2).
А можете подробнее рассказать про ваше последнее предложение? Как получить отчет о всех классах, которые используют этот интерфейс? Куда нажать и где найти «иерархия»?
Хочу поставить, посмотреть Phalcon, мне очень нравяться его интерфейсы. Но не вижу особого смысла в нем. Производительность по сравнению с популярными фреймворками на синтетических тестах, конечно, воодушевляющия, но часто скорость выполнения PHP далеко не узкое место в приложении, чаще всего — это БД.
А есть тесты, сравнивающие чистый Phalcon с, например, ZF + APC?
Хм, интересно. А пусть мы написали 4 теста. 1 из них провалился, который выявил ошибку в _sin(). Мы ее поправили. Ошибок в _sin() больше нет. Поэтому нет необходимости писать 135 тестов.
Разве не так?
Есть мнение, что вы это делаете не правильно:
williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/
Или проблемы нет, и Ваше утверждение просто ставит под сомнение содержание статьи?
Кодогенерация как и в первых версия была, так и во вторых есть. Если вас интересует тема скаффолдинга в ZF2, увы, статья не про это.
А Ваш продукт на симфони 1.4 будет все же уступать аналогичному на sf2, как и продукт на zf1 будет уступать продукту на zf2 по причинам описанных мною выше.
Как опытный разработчик, вы должны понимать, что с ростом функциональности системы и объема кода она (система) становиться неуправляемой. При должной структуризации кода этот момент откладывается (почти) на неопределенное время, вполне возможно до конца актуальности самой системы.
Простой блог как в статье, на чистом PHP, где код написан в хардкорном стиле «здесь и сейчас» можно вложится в несколько экранов, но сопровождение кода в гораздо сложных проектах будет излишне дорого для бизнеса.
Курс современных фреймворков состоит в понижении сопряжения компонентов, из чего следует минимизация сложности, снижение количества ошибок, уже далее простота разработки и сопровождения ПО.
Поэтому ответ на ваш (может быть риторический) вопрос: да, надо. Но прежде всего нужно помнить: для каждой задачи должен быть осознанно применен свой инструмент.
Начал читать второй ваш абзац, и понимать разницу между DI и Service locator. Dependecy Injection — это паттерн, при котором необходимые зависимости содержаться как свойства зависимого класса, а Service locator — при котором зависимый класс является ServiceLocatorAware и получает зависимости у контейнера напрамую.
Все верно?
1. В статье, как пример реализации паттерна Service locator, написан ServiceContainer, он хранит все пользовательские объекты. Так почему же он называется ServiceContainer? В нем не храняться классы-сервисы, которые как раз и вводят слой сервисов. Он просто используется для разруливания зависимостей под капотом.
2. DIC — это реализация паттерна Service locator?
А фанбоев трогать не надо, они сами между собой пусть сраться, мы же давайте обсудим сильные и слабые стороны того, что было сделано.
п.с. я в лагере nokia на симбиан если че
Я могу согласится, что некоторые иконки и вправду убогие, но общая стилистика сохранилась, и что самое важное — удобство и комфорт работы (имхо) не пострадает.
Вот сравните хоум скрин iOS 7 и WP8.
У WP8 фишка в плитках, есть несколько цветовых вариантов, но чаще всего по 2-4 плитки одного цвета. У iOS — пестро, ярко, много цветов, но все иконки «индивидуальны». Если («размыть» |посмотреть сдалека) оба домашних экрана, то узнавание и расположения элементов будет у iOS значительно лучше. Так и наш мозг воспринимает это. Иконки узнаваемы, их легче найти, повышается скорость работы, нет раздражения от неодобства.
Вот (почти) все сравнивают с конкурентными ОС, кто у кого что скопировал. Ну скопировали notification bar у Андроида, да. Но это удобно, а главное же — сделать систему удобной! И при всем этом придумывать что-то свое.
С другой стороны, может такие приложения не на PHP нужно писать (1), а также даже этот оверхед будет очень мал по сравнению с логикой работы приложения, которое оперирует таким количеством объектов (2).
А есть тесты, сравнивающие чистый Phalcon с, например, ZF + APC?
Разве не так?