Всем привет!
Перевод статьи подготовлен для студентов курса «Web-разработчик на Python». Интересно развиваться в данном направлении? Запишитесь на День Открытых Дверей курса и пообщайтесь вживую с преподавателем: онлайн-трансляция 23 июля в 20:00 по мск.!
Когда вы упражнялись в программировании на языке Python, вы, должно быть сталкивались с таким понятием, как декораторы. Они являются одним из самых элегантных и часто используемых инструментов в современных библиотеках и фреймворках. Декораторы — хороший способ инкапсулировать множество деталей реализации, оставляя на поверхности простой интерфейс.
Парадигма CQRS в том или ином виде предполагает, что вызовы Query не будут менять состояние приложения. То есть многократные вызовы одной и той же query, в рамках одного запроса, будут иметь один и тот же результат.
Пусть все интерфейсы, использующиеся в рамках запроса будут иметь тип IQuery или IAsyncQuery:
public interface IQuery<TIn, TOut>
{
TOut Query(TIn input);
}
public interface IAsyncQuery<TIn, TOut>: IQuery<TIn, Task<TOut>
{
}
Рано или поздно перед разработчиками встаёт задача удаления ненужных данных. И чем сложнее сервис, тем больше нюансов необходимо учесть. В данной статье я расскажу, как мы реализовали «удаление» в базе данных с сотней связей.
Читать полностью »
Декораторы — это невероятно круто. Они позволяют описывать мета информацию прямо в объявлении класса, группируя все в одном месте и избегая дублирования. Ужасно удобно. Однажды попробовав, вы уже никогда не согласитесь писать по-старому.
Однако, несмотря на всю полезность, декораторы в TypeScript (заявлены также на стандарт) не так просты, как хотелось бы. Работа с ними требует навыков джедая, так как необходимо разбираться в объектной модели JavaScript (ну, вы поняли, о чем я), API несколько запутанный и, к тому же, еще не стабильный. В этой статье я немного расскажу об устройстве декораторов и покажу несколько конкретных приемов, как поставить эту темную силу на благо front-end разработки.
Помимо TypeScript, декораторы доступны в Babel. В этой статье рассматривается только реализация в TypeScript.
Привет, читатель. Поскольку, судя по всему, мы уже живем в будущем, то недавно я плотно засел за изучение новых фич ES6, ES7 и новых идей, предлагаемых React и Redux. И написал для своих коллег статью, в которой изложил сублимацию этих своих изысканий. Статья неожиданно получилась довольно объемной, и я решил опубликовать её. Заранее извиняюсь за некоторую непоследовательнсть изложения и отсылки к проприетарному коду из наших проектов — но думаю, что это всё же может помочь некоторым из вас лучше понять то, куда движется мир JavaScript и почему не стоит игнорировать происходящее в нём.
Я расскажу про свои мысли о компонентых моделях, классах, декораторах, миксинах, реактивности, чистой функциональности, иммутабельных структурах данных и ключевой идее React. Сразу скажу — я не являюсь пользователем React, и все изложенное это результат чтения его документации и технических статей, объясняющих его архитектуру. То есть, некоторое идеализированное преставление, которое безусловно лишь упрощенная модель того, как оно всё на самом деле обстоит.
Многие из нас, наверное, уже устали от этой шумихи вокруг последних стандартов ECMAScript. ES6, ES7 ECMAScript Harmony… Кажется, что у каждого свое мнение на счет того, как правильно называть JavaScript. Но даже несмотря на весь этот хайп, то что сейчас происходит с JavaScript — это самое замечательное, что происходило с ним за последние лет 5 минимум. Язык живет, развивается, комьюнити постоянно предлагает новые возможности и синтаксические конструкции. Одной из таких новых конструкций, безусловно заслуживающих внимания, являются декораторы. Занявшись поисками материалов по этой теме, я понял, что в русскоязычном интернете практически ничего нет о декораторах. В то же время Addy Osmani еще в июле 2015 представил прекрасную статью Exploring ES2016 Decorators на Medium. В связи с этим, я хотел бы представить вашему вниманию перевод этой статьи на русский язык и разместить его здесь.
Читать полностью »
Когда я только начинал изучать Python, большое впечатление на меня произвели route-декораторы в известном фреймворке flask. Конечно, я догадывался, как они могли быть реализованы, но как всегда желание писать (а не читать) превзошло необходимость взглянуть на исходный код flask, и мне пришлось выдумать то, что могло бы выглядеть так же лапидарно, как вышеупомянутые декораторы из flask'а. Упражнение на тему замыканий, декораторов и области видимости в Python могло бы выглядеть так:
def do_something(p):
return p
@implements(do_something, lambda: not p % 2)
def do_mod2_something(p):
return p / 2
@implements(do_something, lambda: not p % 3)
def do_mod3_something(p):
return p / 3
do_something(10) # returns 5
do_something(9) # returns 3
do_something(11) # returns 11
Как реализовать декоратор @implements? Может ли подобная реализация использоваться где-то в реальных проектах — вопрос, который мы редко принимаем во внимание, выдумывая себе упражнения для понимания того, как работают те или иные программы. Мне показалось, что это выглядит как некое замещение (override) функций, имеющих место в других языках программирования.
Читать полностью »