Да трололо, если код в продакшене такой же, то при старте запроса, сначала вызовется запрос к вчерашнему файлу, потом стартанет таймер, а потом вызовется запрос к proxy.php.
А по теме — бессмысленный бред.
А если в другом воркере попытаться импортировать скрипт? Не пробовали добавлять случайных хэш к адресу импортированного скрипта/воркера, может какой-то глюк с кэшем?
Классическая агрегация подразумевает под собой, создание класса из уже существующих классов. Мост же агрегирует в себе интерфейсы, а не реализованные классы, это и есть инкапсулирование, реализацию же этих интерфейсов вы подсовываете на этапе создания экземпляра класса. Таким образом на этапе реализации класса, вы ничего не знаете, о том что именно будет агрегировано в него. Чувствуете разницу? Если нет, то я умываю руки.
Кстати как навел меня на мысль мой товарищ, мост вполне можно применять и в ФП.
Есть такой термин — повторное использование. Если у вас всего одна единственная сущность с одной единственной реализацией — будильник, то да вам этот паттерн не нужен.
Паттерн — шаблон решения типовой ситуации, чаще всего лучшая практика его решения, ООП — это инструмент, который может применяться для его решения, вы не поверите, но тот же singleton реализуется вообще без ООП.
Как вы будете разделять свой класс это ваши проблемы, главное что бы выделенные сущности были достаточно общими для вашей проблемы.
Нейминг я вообще не понимаю как относится к тому о чем мы сейчас говорим. habrahabr.ru/blogs/complete_code/138357/#comment_4618644 вот тут я описал примерно зачем и как.
Ну и чтобы было понятнее зачем паттерн — он позволяет гибко комбинировать и заменять части классов при этом реализации этих частей имеют общий интерфейс он же мост.
К примеру есть куча машин, но у каждой есть двигатель, а двигателей тоже как известно много, но все делают одно и тоже — создают, грубо говоря, вращательный момент (возможно очень не точно выразил термин, но вы поняли), поэтому мы можем в класс каждой машины, агрегировать интерфейс двигателя с единственным методом — получить момент, и внутри класса работать именно с этим интерфейсом, а как он реализован заботить никого не должно. А затем при создании экземпляра машины подсовывать нужный двигатель. Вот и все!
Все по моему очень просто. и ничего не противоречит ООП
Я вообще не понял о чем сей пост, и зачем автор решил, что знает зачем паттерн и как его применять лучше, чем создатели паттерна. Не понимание ООП, понимание ООП, частное общее, общее частного, частное от общего, частное от частного, что к чему, черт ногу сломает, хотя бы диаграмм вставили…
Да и вообще зачем давать совет если сами, судя по всему, не понимаете зачем этот паттерн? Используйте чистое ООП и НПИ и не тратьте свое время на как вы сами сказали не обязательное!
И пример с окнами там абсолютно логичен. И как написали выше, отделение абстракции от реализации не чем не противоречит ООП, а лишь грубо говоря является выделением общего интерфейса, для нескольких реализаций класса. И никого не должно волновать, как работает черный ящик.
Я конечно, могу процитировать весь топик, но мы же взрослые люди и умеем скролить.
У меня такое впечатление, что вы просто не знакомы с понятием сборки приложения (например maven, ant), и у вас возникает какие-то трудности в понимании, того что для решения проблемы достаточно добавить в сборку для продакшена этап компиляции css (в данном случае сборщик у вас наверное тот самый функционал). А уж простите править файлы на продакшене — это либо форс мажор, либо отсутствие мозга.
А на кой черт на продакшене использовать не скомпилированный код? Может вы еще и на продакшене в режиме онлайн минифицируете и обфусцируете JS код? Мне почему-то больше кажется, что сложности написаны именно у вас.
А почему про силу мысли и телекинез не упомянули? А то описанные вами интерфейсы управления, все кроме третьего пункта, который мне собственно тоже не нравится, также попахивают плесенью, например у меня была стир. машинка, в которой ровно один валик «механической заводки», причем реально покрывало 100% нужд, жаль автонабора воды нет). А дистанционным управлением я пользовался еще в 90х.
Я надеюсь, что сделают возможным держать на одном мониторе полную версию, а на втором метро в бэкграунде, чтобы можно было бы быстро сворачивать и открывать приложения на втором монике.
А по теме — бессмысленный бред.
Кстати как навел меня на мысль мой товарищ, мост вполне можно применять и в ФП.
Как вы будете разделять свой класс это ваши проблемы, главное что бы выделенные сущности были достаточно общими для вашей проблемы.
Нейминг я вообще не понимаю как относится к тому о чем мы сейчас говорим.
habrahabr.ru/blogs/complete_code/138357/#comment_4618644 вот тут я описал примерно зачем и как.
К примеру есть куча машин, но у каждой есть двигатель, а двигателей тоже как известно много, но все делают одно и тоже — создают, грубо говоря, вращательный момент (возможно очень не точно выразил термин, но вы поняли), поэтому мы можем в класс каждой машины, агрегировать интерфейс двигателя с единственным методом — получить момент, и внутри класса работать именно с этим интерфейсом, а как он реализован заботить никого не должно. А затем при создании экземпляра машины подсовывать нужный двигатель. Вот и все!
Все по моему очень просто. и ничего не противоречит ООП
Да и вообще зачем давать совет если сами, судя по всему, не понимаете зачем этот паттерн? Используйте чистое ООП и НПИ и не тратьте свое время на как вы сами сказали не обязательное!
И пример с окнами там абсолютно логичен. И как написали выше, отделение абстракции от реализации не чем не противоречит ООП, а лишь грубо говоря является выделением общего интерфейса, для нескольких реализаций класса. И никого не должно волновать, как работает черный ящик.
У меня такое впечатление, что вы просто не знакомы с понятием сборки приложения (например maven, ant), и у вас возникает какие-то трудности в понимании, того что для решения проблемы достаточно добавить в сборку для продакшена этап компиляции css (в данном случае сборщик у вас наверное тот самый функционал). А уж простите править файлы на продакшене — это либо форс мажор, либо отсутствие мозга.