Используем method decorator в CoffeeScript(Javascript) для удобного и читаемого DRY-кода

[quard]

как вариант, написать класс с методом показа ошибки и использовать mixins

[meettya]

Мммм… Что-то как-то сходу не могу себе представить удобства от такого решения.

Если не сильно затруднит — можно пример, причем именно с асинхронными методами, которые не результат возвращают, а вызывают коллбек?

[quard]

var logMixin  = {
	log : function(message) {
		console.log(message);
	}
};

var Cat = {
	say : function() {
		this.log('мяу'),
	},
	getFood : function() {
		$.get('/food', _.bind(this.say, this));
	}
};

Cat = _.extend(Cat, logMixin);
Cat.getFood();

примерный код. _.extend просто объявляет все методы logMixin внутри Cat

[meettya]

А, ясно, спасибо.

Ну, ИМХО декоратор тут изящнее выглядит, кроме того из них еще и адапторы можно делать, для нижележащих функций.

[Infernal]

Ложка дегтя (куда уж без нее) — сами декораторы таки придется копипастить из модуля в модуль, простого и очевидного способа расшарить их я пока не нашел.

Или я чего-то не понял, или вам надо сделать функцию глобальной:

@ensureArgIsTheAnswer = ()-> ...

[meettya]

Мне религия не позволяет пользоваться глобальными переменными :)
Уж лучше копипаста.

[Infernal]

Чтобы не засорять глобальное пространство, все глобальные функции можно (да и нужно) спрятать в немспейс:

@NS ?= {}
@NS.ensureArgIsTheAnswer = ()-> ...

Если религия не позволяет даже одной глобальной переменной (собственно, неймспейса), ваш выход — AMD-модуль

[meettya]

Ну, неймспейс сам по себе глобальная переменная, к которым религия строга :)

И, нет, AMD-модули это какие-то странные фиговины, которые не работают в node.js без напильника, так что наш выбор — CommonJS-only.

[Infernal]

Эмм… Так если у вас Node вообще не понимаю в чем проблема расшарить что-либо. Выносите декораторы в отдельный модуль и экспортируете.

[meettya]

О, и правда! :)
Временами случаются со мной затупы, спасибо за подсказку.

[mihailt]

coffeescriptcookbook.com/chapters/design_patterns/decorator

[meettya]

Посмотрю на досуге, но во-первых у меня объяснение вышло сильно короче и понятнее, во вторых код там кривоват.

TextProcessor = (@processors) ->

а должно быть

class TextProcessor 
    constructor : (@processors) ->

иначе

Cannot call method 'reduce' of undefined

[nicola]

Почему бы просто не вызвать вашу вспомогательную функцию внутри нескольких методов. Окам :)

[meettya]

Потому что на самом деле продемонстрированный враппинг — верхушка айсберга под названием AOP, самой элегантной схемы организации кода из мне известных. Копайте глубжее :)

[nicola]

Копал :) Насколько я знаю аоп, о котором так много шумели в начале (типа новая парадигма и тд) скромно занял свою нишу на задворках java. и кроме усложнения кодопонимания и теоретических преимуществ впринципе он ничего не дал :), разве для оч специальных случаев. Кстати основные концепции css это аоп, а хорошего css встретишь редко.

[meettya]

Его скромное положение в основном из-за того, что он с горем пополам может быть применен в популярных языках (или делает код нечитабельным, как в perl-е), да плюс требует некоторого прогиба мозгов и лишнего кодописания (я вот хоть и понимаю прототипное наследование, но синтаксис настолько убог, что лучше CS с его псевдоклассами).
По мне так aop и контракты — очень классная идея, очень легко и нативно ложится на CoffeeScript/JS (есть даже пара модулей для такого классического варианта написания контрактов), нормально читается и избавляет код метода от лишнего шума.
ИМХО это как с коллбеками — пока их немного — все ок, но как только начинается перебор, да с развесистой логикой — проще перейти на event-ы. Хотя, каждому свое, собсно тем и хорош (для меня) JS — пластичен настолько, насколько тебе этого нужно.
PS. разве в приведенном примере есть сложности с кодопониманием? Ну, что-то куда-то вынеслось, но так и с миксинами такая же байда, тут уж чем больше нормализации, тем больше join-ов :)