Сервис оформления и оплаты заказа.
Как давно я мечтаю о том, чтобы не стоять в очереди в кассу в магазине и не ждать пока она там карту проведет и пин введешь (что тоже по скорости сравнимо с расплачиванием наличкой).
Зашел в икею — накидал что надо в электронную корзину — и жди доставки.
MasterPass кошельки.
Как меня достала огромная стопка многочисленных скидочных карт и карт лояльности. Как было бы здорово использовать для этого только свою банковскую карту. Одно сэконосленное место в сумке чего стоит.
Дополнительные сервисы, которые сделают процесс покупки ещё более приятным.
Как надоело, что в плане скидок и спецпредложений я ограничен лишь партнерами банка. Точно также лишь мой банк диктует какие у меня возможности и сервисы по уведомлениеям, учету финансов и т.д. Будет здорово, если возможности подобных сервисов вырвуться из их пут.
Интерфейс указывает как использовать класс разработчику, когда мы говорим про реализацию классом интерфейса.
Но ведь разработчик пользуется вовсе не классом, а просто объектом, который поддерживает данный интерфейс. Более того класс там может быть любой и даже может поменяться. Как же можно при этом говорить, что интерфейс указывает разработчику как использовать класс, если он (разработчик) может даже не догадываться о его (классе) существовании.
Я именно поэтому и говорил, что использовать интерфейс для упрощения работы с классом — это не совсем правильное его использование. Эту проблема обычно видна как набор классов с одноименными интерфейсами, которые они поддерживают. Или даже просто классы и их интерфейсы рядом в одной библиотеке. Для упрощения интерфейса доступа есть механизмы фасадов и т.д.
Фактически класс тоже имеет интерфейс — это набор его публичных полей. Чем он плох?
То есть интерфейс указывает не как использовать класс разработчику, а какой функционал должен поддерживать класс, чтобы его мог использовать разработик. То есть именно от потребностей разработчика и идут требования к составу интерфейса, а не от того, что может предоставить класс.
Под разработчиком я понимаю конечность какой то код — который использует интерфейс.
Тяжело мне понять вашу линию мысли, как вы пришли к этому от typehint'инга.
Видимо я просто неправильно понял что такое тайпхинтинг. Никогда не слышал про такой термин.
Не могли бы Вы пояснить что это?
В интерфейсе нет указания того как расширять класс. В абстрактном классе есть — это абстрактные методы.
Ну скажите какая принципиальная разница для класса что именно реализовывать — абстрактный метод или метод интерфейса? Между ними вообще хоть какая то разница есть?
Да, наверное ранее я слишком скомкано объяснил. Но понимание к вам придет со временем — это нормально.
Ко мне то придет конечно, меня беспокоит, что к Вам оно может не прийти.
Интерфейс указывает как использовать данный класс.
Интерфейс не принадлежит классу и ничего не знает о классе. Значит он не может указывать как использовать данный класс.
Или же, если интерфейс в роли typehint методов некоторого класса, говорит как использовать данный класс, в бизнес-логики приложения.
Создание интерфейсов, цель которых упросить работу со сложным внешним интерфейсом класса — вероятно не верное использование интерфейсов.
Абстрактный класс сам по себе является указанием, как расширять систему с помощью его наследников.
И интерфейс тоже является указанием, как расширять с помощью его наследников.
Возможно Вам лишь кажется, что Вы понимаете что к чему.
Абстрактный класс — декларация соглашений на расширение системы.
Через абстрактные классы можно тоже использовать систему без проблем.
Интерфейс — это соглашение по использованию системы.
Интерфейс вполне может быть соглашением на расширение системы.
Абстрактный класс нужен для того, что бы человек, который реализовывал, соблюдал заложенные в него соглашения.
Реализовывают интерфейсы, а не абстрактные классы. И они оба нужны, чтобы соблюдали соглашения, которые они декларируют.
Я надеюсь вы понимаете, что Ваше высказывание не выдерживает критики.
Насколько я понимаю, то, что вы описываете — это просто концепция полиморфизма.
И первый и второй пункт можно реализовать только наследованием безо всяких интерфейсов.
Собственно интерфейсы не наследуют, а реализуют.
И дело просто в том, что есть подход, при котором тот, кто использует некий класс фиксирует интерфейс взаимодействия с ним, а класс реализует данный интерфейс.
То есть интерфейс принадлежит тому, кто его использует. А тот или иной класс может его или поддерживать или нет.
В отличие от простого полиморфизма с помощью наследования, в котором просто используемый класс может вести себя по разному, но именно он диктует протокол взаимодействия с тем, кто его использует.
Собственно абстрактный класс — всего лишь обычный класс, экземпляры которого не имеют смысла сами по себе. И ничего больше.
И для того, чтобы это понимать никакие Солиды вам знать не надо. Элементарные вещи.
Интересная статья. Но я бы все таки еще добавил что нибудь про важность коллектива и условия работы.
Дело в том, что в не зависимости от специфики проекта, руководства и типа компании, бывают команды профессионалов и дилетантов. В первых вы все равно будете быстро расти, во вторых медленно, а может вообще деградировать.
В тоже время профильные крупные компании и частично госсектор в отличие от маленьких и непрофильных компаний еще и обеспечивают хорошие условия работы. Заботятся о соблюдении трудового кодекса, эргономике, общей мотивации, разных бонусов и плюшек, которые делают нашу жизнь приятной и комфортной, позволяя сконцентрироваться на работе.
Жизнь только одна и тратить ее на неудобные кресла, старую техник и работодателей, которые плюют на законодательтво — возможно не лучшая идея — ведь мы тратим на работу большую часть своего продуктивного времени и второго такого времени уже не будет — это и есть жизнь. Сотрудник крупной профильной компании будет удивлен если ему придется самому убирать пролитый на пол или стол кофе. А уж про практику переквалификации в грузчиков и сборщиков мебели я вообще молчу.
Поэтому нужно стремится в компании с хорошими условиями труда в любом случае.
И в конкретные команды к конкретным руководителями для быстрого роста.
Там используется какой то супербыстрый алгоритм выделения памяти fast memory allocation к тому же оптимизированный под строки небольшого назмера. Посмотрите рефлектором.
В дот нете выделение памяти вообще очень быстрая операция — там не нужно искать куда ее выделить благодаря работе дефрагментатора памяти. И вы точно знаете сколько времени это займет — почти ноль времени. В тоже время копирование остается копированием.
Но создание временных элементов в большом количестве быстро приведет к переполнению управляемой кучи.
А в случае больших строк они еще и попадают в конце концов Large Object Heap — в котором нет дефрагментации памяти при сборке мусора и последняя будет происходить скорее всего непрерывно, так как механизм выделения памяти остается прежним.
Поэтому выигрыш не за счет копирования может даже или выделения памяти — а просто за счет менее активной работой с управляемой кучей.
Но вообще то, если строк там тысячи конкатенируются — это актуально. Задача, которая встречается оооочень редко — к тому же решается обычно вообще избавлением от работы со строками.
Для практических задач обычных конкатенаций строк никакие стринг билдеры не нужны — все это детские шалости и экономия на спичках.
Автор рассмотрел недостатки иконок, но практически ничего не сказал про достоинства. Ведь надпись мы читаем каждый раз, а иконку узнаем мгновенно. Я в последнем отпуске (не у нас) приметил, что надписи на асфальте «право», «лево» читаю каждый раз снова.
С другой стороны, иконки требуют обучения.
То есть мы инвестируем в обучение, чтобы в дальнейшем пользователь мог узнавать элементы быстрее.
Когда такие инвестиции окупятся?
Очевидно там, где пользователь будет работать с элементами долго, а не один или несколько раз в жизни.
Например стиральная машина. А вот «окрашено» на лавочке каждый человек увидит лишь раз или два.
Конечно в операционных системах иконки окупятся, потому что пользователь не перестанет ей пользоваться из-за необходимости обучения — такова специфика рынка — лептоп он уже купил.
А для программы с кучей управляющих элементов, как редакторы из статьи — тут уже вопрос. Если инструмент нацелен на профессионалов — то они обучатся, так как обучение окупится, а если на любителей — то скорее ужаснуться иконкам, запутаются и удалят с компьютера.
Был бы вот такой единый реестр иконок — мы могли бы существенно снизить расходы на обучение и иконкам мы бы чаще радовались.
Нет — в один клик нельзя — тут я ошибся. Можно в несколько кликов.
Я всего лишь хотел сказать что технические проблемы конкретного инструментария — это технические проблемы конкретного инструментария.
А концепция не становится хуже в принципе при наличии и отсутствии подобных проблем. Просто их наличие влияет на наш выбор подхода.
Так — есть у вас класс. Вы знаете, что все его зависимости выражены в виде вызовов сервис локаторов.
Начинаете поиск по инстансу сервис локатора, дальше в результате поиска сморите вызовы для своего класса (там с группировкой все ок).
В чем проблема?
Меня все таки не покидает ощущение — что я вас правильно понял. Или я опять ошибся?
Я чего то не понял, зачем Вам получать все зависимости класса, использующего сервис локатор.
Если мы говорим о необходимости найти все зависимости, переданные через сервис локатор, то кликаете правой кнопкой на инстансе сервис локатора (вероятно синглтоне) и нажимаете find usages.
Если нужно точки спользования конкретного сервиса через локатор — то тоже самое над методом CreateInstance локатора (или как он у Вас там называется).
Там группировака сразу будет по местам использования.
Согласен с автом статьи — более того считаю, что синглтон и сервис локатор никакие не антипаттерны и никогда ими не станут — просто в пик их популярности нужно поумерить пыл тех, кто ими злоупотребляет.
У них есть свои области применения, которые пока не имеют четкой теории.
А по поводу цитаты Фаулера и Вашего комментария — это чисто технический вопрос. Вообще не понимаю при чем тут концепция.
Здается мне он был сильно не прав, когда это писал.
Во первых совершенно не обязательно, что риски появления необходимости менять интерфейсы из сервис локатора сколько нибудь значительны.
Во вторых используя развитые инструменты (например VS+Resharper) вы точно также получите в один клик все зависимости списком и можете их скопом изменить.
Если у вас таковых инструментов не имеется — то так и говорите, что из-за таких то технологических проблем использовать сервис локатор пока не можем, а не то, что он в принципе плох или концепция неверна.
компания Microsoft сделала рискованную ставку на создание операционной системы, которая бы одинаково хорошо подошла и для планшетов, и для настольных компьютеров. Эта, казалось бы, весьма разумная стратегия была обречена на провал
Складывается ощущение что уже абсолютно понятно, что стратегия провалилась. Вам не кажется, что об этом пока рано говорить? Тем более, если это шаг в перспективу. По моему статья пронизана эмоциями автора, а не фактами и даже попахивает желтизной.
Есть cloud-save, который умеет сохранять вообще практически в любое хранилище. Список огромный просто.
Картинки например хочется в google picasa хранить а не в google drive.
Ну а вообще молодцы конечно.
У них кстати на локальный компьютер эти файлы скачиваются перед отправкой в облачное хранилище как в других подобных плагинах?
Как давно я мечтаю о том, чтобы не стоять в очереди в кассу в магазине и не ждать пока она там карту проведет и пин введешь (что тоже по скорости сравнимо с расплачиванием наличкой).
Зашел в икею — накидал что надо в электронную корзину — и жди доставки.
MasterPass кошельки.
Как меня достала огромная стопка многочисленных скидочных карт и карт лояльности. Как было бы здорово использовать для этого только свою банковскую карту. Одно сэконосленное место в сумке чего стоит.
Дополнительные сервисы, которые сделают процесс покупки ещё более приятным.
Как надоело, что в плане скидок и спецпредложений я ограничен лишь партнерами банка. Точно также лишь мой банк диктует какие у меня возможности и сервисы по уведомлениеям, учету финансов и т.д. Будет здорово, если возможности подобных сервисов вырвуться из их пут.
Но ведь разработчик пользуется вовсе не классом, а просто объектом, который поддерживает данный интерфейс. Более того класс там может быть любой и даже может поменяться. Как же можно при этом говорить, что интерфейс указывает разработчику как использовать класс, если он (разработчик) может даже не догадываться о его (классе) существовании.
Я именно поэтому и говорил, что использовать интерфейс для упрощения работы с классом — это не совсем правильное его использование. Эту проблема обычно видна как набор классов с одноименными интерфейсами, которые они поддерживают. Или даже просто классы и их интерфейсы рядом в одной библиотеке. Для упрощения интерфейса доступа есть механизмы фасадов и т.д.
Фактически класс тоже имеет интерфейс — это набор его публичных полей. Чем он плох?
То есть интерфейс указывает не как использовать класс разработчику, а какой функционал должен поддерживать класс, чтобы его мог использовать разработик. То есть именно от потребностей разработчика и идут требования к составу интерфейса, а не от того, что может предоставить класс.
Под разработчиком я понимаю конечность какой то код — который использует интерфейс.
Тяжело мне понять вашу линию мысли, как вы пришли к этому от typehint'инга.
Видимо я просто неправильно понял что такое тайпхинтинг. Никогда не слышал про такой термин.
Не могли бы Вы пояснить что это?
В интерфейсе нет указания того как расширять класс. В абстрактном классе есть — это абстрактные методы.
Ну скажите какая принципиальная разница для класса что именно реализовывать — абстрактный метод или метод интерфейса? Между ними вообще хоть какая то разница есть?
Ко мне то придет конечно, меня беспокоит, что к Вам оно может не прийти.
Интерфейс указывает как использовать данный класс.
Интерфейс не принадлежит классу и ничего не знает о классе. Значит он не может указывать как использовать данный класс.
Или же, если интерфейс в роли typehint методов некоторого класса, говорит как использовать данный класс, в бизнес-логики приложения.
Создание интерфейсов, цель которых упросить работу со сложным внешним интерфейсом класса — вероятно не верное использование интерфейсов.
Абстрактный класс сам по себе является указанием, как расширять систему с помощью его наследников.
И интерфейс тоже является указанием, как расширять с помощью его наследников.
Возможно Вам лишь кажется, что Вы понимаете что к чему.
Через абстрактные классы можно тоже использовать систему без проблем.
Интерфейс — это соглашение по использованию системы.
Интерфейс вполне может быть соглашением на расширение системы.
Абстрактный класс нужен для того, что бы человек, который реализовывал, соблюдал заложенные в него соглашения.
Реализовывают интерфейсы, а не абстрактные классы. И они оба нужны, чтобы соблюдали соглашения, которые они декларируют.
Я надеюсь вы понимаете, что Ваше высказывание не выдерживает критики.
И первый и второй пункт можно реализовать только наследованием безо всяких интерфейсов.
Собственно интерфейсы не наследуют, а реализуют.
И дело просто в том, что есть подход, при котором тот, кто использует некий класс фиксирует интерфейс взаимодействия с ним, а класс реализует данный интерфейс.
То есть интерфейс принадлежит тому, кто его использует. А тот или иной класс может его или поддерживать или нет.
В отличие от простого полиморфизма с помощью наследования, в котором просто используемый класс может вести себя по разному, но именно он диктует протокол взаимодействия с тем, кто его использует.
Собственно абстрактный класс — всего лишь обычный класс, экземпляры которого не имеют смысла сами по себе. И ничего больше.
И для того, чтобы это понимать никакие Солиды вам знать не надо. Элементарные вещи.
а базовый класс?
погодите, я запутался :)
Дело в том, что в не зависимости от специфики проекта, руководства и типа компании, бывают команды профессионалов и дилетантов. В первых вы все равно будете быстро расти, во вторых медленно, а может вообще деградировать.
В тоже время профильные крупные компании и частично госсектор в отличие от маленьких и непрофильных компаний еще и обеспечивают хорошие условия работы. Заботятся о соблюдении трудового кодекса, эргономике, общей мотивации, разных бонусов и плюшек, которые делают нашу жизнь приятной и комфортной, позволяя сконцентрироваться на работе.
Жизнь только одна и тратить ее на неудобные кресла, старую техник и работодателей, которые плюют на законодательтво — возможно не лучшая идея — ведь мы тратим на работу большую часть своего продуктивного времени и второго такого времени уже не будет — это и есть жизнь. Сотрудник крупной профильной компании будет удивлен если ему придется самому убирать пролитый на пол или стол кофе. А уж про практику переквалификации в грузчиков и сборщиков мебели я вообще молчу.
Поэтому нужно стремится в компании с хорошими условиями труда в любом случае.
И в конкретные команды к конкретным руководителями для быстрого роста.
То есть гугл раскрыл всего одного пользователя российским госорганам — и то возможно частично?
в США — по статистике, 88% из 8400 запросов
И 6000 пользователей штатовским?
В дот нете выделение памяти вообще очень быстрая операция — там не нужно искать куда ее выделить благодаря работе дефрагментатора памяти. И вы точно знаете сколько времени это займет — почти ноль времени. В тоже время копирование остается копированием.
Но создание временных элементов в большом количестве быстро приведет к переполнению управляемой кучи.
А в случае больших строк они еще и попадают в конце концов Large Object Heap — в котором нет дефрагментации памяти при сборке мусора и последняя будет происходить скорее всего непрерывно, так как механизм выделения памяти остается прежним.
Поэтому выигрыш не за счет копирования может даже или выделения памяти — а просто за счет менее активной работой с управляемой кучей.
Но вообще то, если строк там тысячи конкатенируются — это актуально. Задача, которая встречается оооочень редко — к тому же решается обычно вообще избавлением от работы со строками.
Для практических задач обычных конкатенаций строк никакие стринг билдеры не нужны — все это детские шалости и экономия на спичках.
Автор рассмотрел недостатки иконок, но практически ничего не сказал про достоинства. Ведь надпись мы читаем каждый раз, а иконку узнаем мгновенно. Я в последнем отпуске (не у нас) приметил, что надписи на асфальте «право», «лево» читаю каждый раз снова.
С другой стороны, иконки требуют обучения.
То есть мы инвестируем в обучение, чтобы в дальнейшем пользователь мог узнавать элементы быстрее.
Когда такие инвестиции окупятся?
Очевидно там, где пользователь будет работать с элементами долго, а не один или несколько раз в жизни.
Например стиральная машина. А вот «окрашено» на лавочке каждый человек увидит лишь раз или два.
Конечно в операционных системах иконки окупятся, потому что пользователь не перестанет ей пользоваться из-за необходимости обучения — такова специфика рынка — лептоп он уже купил.
А для программы с кучей управляющих элементов, как редакторы из статьи — тут уже вопрос. Если инструмент нацелен на профессионалов — то они обучатся, так как обучение окупится, а если на любителей — то скорее ужаснуться иконкам, запутаются и удалят с компьютера.
Был бы вот такой единый реестр иконок — мы могли бы существенно снизить расходы на обучение и иконкам мы бы чаще радовались.
Я всего лишь хотел сказать что технические проблемы конкретного инструментария — это технические проблемы конкретного инструментария.
А концепция не становится хуже в принципе при наличии и отсутствии подобных проблем. Просто их наличие влияет на наш выбор подхода.
Начинаете поиск по инстансу сервис локатора, дальше в результате поиска сморите вызовы для своего класса (там с группировкой все ок).
В чем проблема?
Меня все таки не покидает ощущение — что я вас правильно понял. Или я опять ошибся?
Если мы говорим о необходимости найти все зависимости, переданные через сервис локатор, то кликаете правой кнопкой на инстансе сервис локатора (вероятно синглтоне) и нажимаете find usages.
Если нужно точки спользования конкретного сервиса через локатор — то тоже самое над методом CreateInstance локатора (или как он у Вас там называется).
Там группировака сразу будет по местам использования.
Я что то неправильно понял?
У них есть свои области применения, которые пока не имеют четкой теории.
А по поводу цитаты Фаулера и Вашего комментария — это чисто технический вопрос. Вообще не понимаю при чем тут концепция.
Здается мне он был сильно не прав, когда это писал.
Во первых совершенно не обязательно, что риски появления необходимости менять интерфейсы из сервис локатора сколько нибудь значительны.
Во вторых используя развитые инструменты (например VS+Resharper) вы точно также получите в один клик все зависимости списком и можете их скопом изменить.
Если у вас таковых инструментов не имеется — то так и говорите, что из-за таких то технологических проблем использовать сервис локатор пока не можем, а не то, что он в принципе плох или концепция неверна.
компания Microsoft сделала рискованную ставку на создание операционной системы, которая бы одинаково хорошо подошла и для планшетов, и для настольных компьютеров. Эта, казалось бы, весьма разумная стратегия была обречена на провал
Складывается ощущение что уже абсолютно понятно, что стратегия провалилась. Вам не кажется, что об этом пока рано говорить? Тем более, если это шаг в перспективу. По моему статья пронизана эмоциями автора, а не фактами и даже попахивает желтизной.
Картинки например хочется в google picasa хранить а не в google drive.
Ну а вообще молодцы конечно.
У них кстати на локальный компьютер эти файлы скачиваются перед отправкой в облачное хранилище как в других подобных плагинах?