Является ли модификация встроенных прототипов JavaScript антипаттерном?

Question

Я понимаю из эта почта, что это антишаблон для изменения Objectпрототип на JavaScript.Однако мне было любопытно, считается ли модификация других «встроенных» прототипов антипаттерном.

Например:скажем, мы хотели добавить setPixel(x,y,color) функционировать, чтобы CanvasRenderingContext2D - абстрагироваться от обязанности получать данные изображения из контекста, устанавливать для пикселя определенный цвет и возвращать данные изображения обратно.

CanvasRenderingContext2D.prototype.setPixel = function(x, y, color){
    var imgdata = this.createImageData(1,1);
    imgdata.data[0] = color.r;
    imgdata.data[1] = color.g;
    imgdata.data[2] = color.b;
    imgdata.data[3] = color.a;
    this.putImageData(imgdata,x,y);
};

Я не тестировал этот код, но вы поняли.Противоречит ли что-то подобное «лучшим практикам»?

Answer 1

Как правило, если вы добавляете прототип к одному из базовых объектов в JavaScript, у вас должна быть веская причина, и на самом деле нет никакой причины изменять объект, поскольку вы не знаете, как предсказать, каким будет конечный результат. эта модификация.

Я обычно добавляю, например, BeginsWith, Trim и некоторые другие функции в String, поскольку это вспомогательные функции, точно так же, как имеет смысл добавлять некоторые функции в Array, которые существуют для Firefox, но не для IE (например, функция фильтра).

Итак, добавление в Canvas — это нормально, но что, если кто-то использует вашу библиотеку и excanvas.Вызовет ли это проблему?

Вы можете либо изучить это, либо задокументировать, что это не работает для excanvas, и если у вас есть небольшой тест, чтобы показать это, включите его, чтобы, если позже выйдет новая версия и ваша проблема исчезнет, ​​люди смогут подтвердите это.

ОБНОВЛЯТЬ:Вы захотите сделать это:

if (!CanvasRenderingContext2D.setPixel) {
...
}

Таким образом, если кто-то включил файл с таким именем, вы не перезапишете его, но вам нужно будет обращаться с ним корректно.

Answer 2

Я бы не стал этого делать, поскольку это затрудняет отслеживание того, что и где реализовано.Это также создает риск того, что два человека будут игнорировать одно и то же поведение.

Answer 3

Точно нет;если метод таким образом связан с объектом, то это элегантное решение.

Answer 4

Все эти «анти-шаблоны» предложения не следует принимать слепо.Что бы они ни говорили, иногда лучший ответ — стиснуть зубы и пойти против условностей, чтобы все заработало.Это, конечно, во многом зависит от вашего сценария.

Мне вспоминается ситуация, когда дни были потрачены на реорганизацию кода, чтобы сделать соответствующее исправление «правильным способом», тогда как простой GO TO работал бы отлично, и его реализация заняла бы всего пару минут.В итоге создалась куча ошибок, потому что был изменен код, который не нужно было менять.Я поклонник утверждений GO TO?Конечно нет!Но если его использование предотвратит головные боли на месяцы, тогда нет никаких сомнений.

Answer 5

Я не вижу в этом никакой проблемы, пока функциональность или именование не переопределяют то, что уже есть.Я знаю некоторых, которые изменяют string прототип для Trim функции.

http://www.somacon.com/p355.php

Что забавно, в C# теперь есть так называемый метод расширения, который фактически делает то же самое.

Answer 6

Не как таковой, но у создателей библиотек Ajax могут возникнуть проблемы, если они не смогут полагаться на встроенные типы и их свойства.Таким образом, вы можете сломать код, основанный на определенном поведении.