По вашей логике, заходишь в linux и сразу его считаешь не рабочим поделием?
Я вот не понимаю этого.
Огромное количество пользователей и про F1 не знают.
Новое — не значит плохое.
Эм, простите, но не соглашусь абсолютно.
Я хочу показать всем, какую показать в каком месте мой класс может быть расширен (за счет protected) — тут я этого сделать не могу.
class UserMeta {
protected function getFields() {
/* какой то код */
return $fields;
}
}
Что-то сделать с интерфейсами со статиками вообще невозможно. Аналога со статиками нет, тут просто спрячется зависимость внутри метода, что не хорошо.
public function setUserMeta(UserMetaInterface $userMeta) {}
Я не могу не думать о целостности данных.
User::init();
/* тут может быть вызов любой функции или любого статика */
$user = User::findById($id);
Всё, тут я уже не могу гарантировать, что findById будет работать так же, как если бы не было кода в месте, указанном комментарием. Если же использовать экземпляры, то я явно увижу, куда экземпляр передается.
На самом деле — статики, это не только невозможность тестирования — это глобальный факап на уровне архитектуры системы. Статик — это упрощение, когда не охота думать о идеологии построения приложения.
В Yii это «упрощение» сделано лишь для того, что бы можно было просто оперировать с теми сущностями, которые в веб-разработке точно являются singleton. Например — приложение. Когда вы в любом месте программы, у вас точно есть одно и только одно приложение. За счёт этого Yii очень сильно выигрывает в простоте при проектировке over 95% приложений для web, где они за счет «упрощения», ввели аспект единого приложения для всего кода.
Проблема статиков в том, что они полностью игнорируют ООП при проектировании. Статики, по сути — это функции объеденные в namespace. Соответственно используя везде статики, мы не можем полагаться на SOLID.
Если при использовании ООП, у многих хоть как то сложилось в голове своя методика, как писать структурированный код, то в данном случае, очень большая вероятность понаписать кода, который очень тяжело будет поддерживать, т.к. ООП — это в первую очередь рамки, которые позволяют другим программистам понимать ваш код.
Он является единственной точкой входа. Так, например если внутри фасада что-то изменится — использование его не изменится.
Как бы, когда вы публикуете интерфейс, то он так и работает. Вы можете подменять реализацию данного интерфейса, но если он реализован, то работать будет так как надо.
К тому же, я пока не понимаю, как набор статических методов воспринимать как интерфейс?
Сам покупал телефон для бабушки от МТС (МТС 268 Brown)
Банально на рынки России другого телефона для бабули нет!
Там и большие кнопки и интерфейс очень простой и понятный.
Сейчас начали продавать Alcatel OT 2000 Black. У него экран и кнопки чуть-чуть побольше.
НЕ ПОКУПАЙТЕ ЕГО СВОИМ БАБУШКАМ!
Его прошивка — это АД для них. Там по умолчанию(и сменить нельзя!) на кнопку вверх установлено включение радио, которое работает без наушников! И если потом нажать сброс, то радио не отключится, что бы его отключить, нужно снова зайти в радио, затем в опции, и там отключить.
К тому же, первый пункт в меню, там опять же это радио!
Скрывать работу с экземпляром за вызовом статических методов очень плохо, по той причине, что это ломает полностью ООП подход. Соответственно мы не можем уже полагаться на SOLID в проекте.
К тому, если попытаться подключить класс, который использует подобную зависимость где-либо вне Фреймворка, он рухнет и что бы восстановить его функциональность, придётся писать статические Mock-объекты.
На самом деле, я не понял, зачем прятаться за такими «фасадами»
class Cache extends Facade {
protected static function getFacadeAccessor() { return 'cache'; }
}
, если всё сводится к
App::container->get("cache")
p.s.
С Фреймворком не работал, знания лишь почерпнул из статьи и комментариев к ней.
Зачем создавать авоматически и придумывать магию, в том месте где она не нужна. Из комментариев людей, которые с Фреймворком работали, я понял что создаётся зависимость, если в хинте указан не интерфейс, а конкретный класс.
Что это за внедрение зависимости такое?
class A {
function __construct(B b=null) [
if (b === null) {
b = new B();
}
}
}
Что бы параметры подтягивать из настроек и переопределять / расширять поведение модулей 3ей стороны
Других usecase'ов не вижу. А пример DI в статье, так вообще смешной, не понятно зачем он там %)
Не только. Меня вообще скругленный углы раздражают.
(У меня даже в квартире есть 1 такой угол, мебель фиг поставишь)
Бесит жутко, только из-за этого пользоваться не смогу браузером.
Впечатляет!
Можно узнать, примерна за какой срок написали? Интересует примерная оценка чистого времени и протяженность, в течении какого срока садились и писали? :)
| И неправильно, как я уже заметил, если мы хотим получить новую вычищенную семантику.
При чем тут семантика и кривая обучаемости?
| В Dart это (как и в CoffeeScript) сокращенная запись для A(x) { this.x = x; } иначе
Т.е. семантика тут вообще «сумашедшая»?
| Он создан для того, чтобы его могли использовать там где сейчас используют JavaScript и при этом иметь определенные удобства, которых JavaScript лишен.
Дублирование в том контексте, который описал я, это использование в одних и тех же условиях для одного и той же задачи. Dart хочет быть заменой JS с более приятным для программиста свойствами.
Я говорю о том, что из множества отзывов могут быть такие вот, ЛОЛиконы.
Но большое количество тех людей, которые отзываются о проблеме, давно зарегистрированы на Амазоне и у них множество отзывов.
К тому же на портале поддержки Sony уже много человек отписались о данной проблеме.
А про проценты, это лишь я предположил, ведь действительно процент негативных отзывов очень высок.
Или я вас не так понял?
Я вот не понимаю этого.
Огромное количество пользователей и про F1 не знают.
Новое — не значит плохое.
Я хочу показать всем, какую показать в каком месте мой класс может быть расширен (за счет protected) — тут я этого сделать не могу.
Что-то сделать с интерфейсами со статиками вообще невозможно. Аналога со статиками нет, тут просто спрячется зависимость внутри метода, что не хорошо.
Я не могу не думать о целостности данных.
Всё, тут я уже не могу гарантировать, что findById будет работать так же, как если бы не было кода в месте, указанном комментарием. Если же использовать экземпляры, то я явно увижу, куда экземпляр передается.
На самом деле — статики, это не только невозможность тестирования — это глобальный факап на уровне архитектуры системы. Статик — это упрощение, когда не охота думать о идеологии построения приложения.
В Yii это «упрощение» сделано лишь для того, что бы можно было просто оперировать с теми сущностями, которые в веб-разработке точно являются singleton. Например — приложение. Когда вы в любом месте программы, у вас точно есть одно и только одно приложение. За счёт этого Yii очень сильно выигрывает в простоте при проектировке over 95% приложений для web, где они за счет «упрощения», ввели аспект единого приложения для всего кода.
Если при использовании ООП, у многих хоть как то сложилось в голове своя методика, как писать структурированный код, то в данном случае, очень большая вероятность понаписать кода, который очень тяжело будет поддерживать, т.к. ООП — это в первую очередь рамки, которые позволяют другим программистам понимать ваш код.
Я имел в виду, что мой вариант(который я написал) лучше чем неявное создание через сигнатуру typehint'a.
Как бы, когда вы публикуете интерфейс, то он так и работает. Вы можете подменять реализацию данного интерфейса, но если он реализован, то работать будет так как надо.
К тому же, я пока не понимаю, как набор статических методов воспринимать как интерфейс?
Банально на рынки России другого телефона для бабули нет!
Там и большие кнопки и интерфейс очень простой и понятный.
Сейчас начали продавать Alcatel OT 2000 Black. У него экран и кнопки чуть-чуть побольше.
НЕ ПОКУПАЙТЕ ЕГО СВОИМ БАБУШКАМ!
Его прошивка — это АД для них. Там по умолчанию(и сменить нельзя!) на кнопку вверх установлено включение радио, которое работает без наушников! И если потом нажать сброс, то радио не отключится, что бы его отключить, нужно снова зайти в радио, затем в опции, и там отключить.
К тому же, первый пункт в меню, там опять же это радио!
p.s.
я уже давно использую лишь плеерами из коробки, а раньше сидел на winamp.
К тому, если попытаться подключить класс, который использует подобную зависимость где-либо вне Фреймворка, он рухнет и что бы восстановить его функциональность, придётся писать статические Mock-объекты.
На самом деле, я не понял, зачем прятаться за такими «фасадами»
, если всё сводится к
p.s.
С Фреймворком не работал, знания лишь почерпнул из статьи и комментариев к ней.
Прочитайте про них в wiki.
Что это за внедрение зависимости такое?
Явное лучше чем неявное(магия).
Других usecase'ов не вижу. А пример DI в статье, так вообще смешной, не понятно зачем он там %)
Фича мегаудобная, без неё сейчас невозможно жить.
(У меня даже в квартире есть 1 такой угол, мебель фиг поставишь)
Бесит жутко, только из-за этого пользоваться не смогу браузером.
Можно узнать, примерна за какой срок написали? Интересует примерная оценка чистого времени и протяженность, в течении какого срока садились и писали? :)
При чем тут семантика и кривая обучаемости?
| В Dart это (как и в CoffeeScript) сокращенная запись для A(x) { this.x = x; } иначе
Т.е. семантика тут вообще «сумашедшая»?
| Он создан для того, чтобы его могли использовать там где сейчас используют JavaScript и при этом иметь определенные удобства, которых JavaScript лишен.
Дублирование в том контексте, который описал я, это использование в одних и тех же условиях для одного и той же задачи. Dart хочет быть заменой JS с более приятным для программиста свойствами.
Но большое количество тех людей, которые отзываются о проблеме, давно зарегистрированы на Амазоне и у них множество отзывов.
К тому же на портале поддержки Sony уже много человек отписались о данной проблеме.
А про проценты, это лишь я предположил, ведь действительно процент негативных отзывов очень высок.
К тому же обнаружил:
corruptedcartridge.com/ps4-sabotaged-news