CoffeeScript #15
قسمتهای اصلاح نشده
در ادامهی مطالب قسمت قبل، به برخی دیگر از معایب طراحی در جاوااسکریپت که در CoffeeScript نیز اصلاح نشدهاند میپردازیم.استفاده از parseInt
تابع ()parseInt در جاوااسکریپت، در صورتیکه یک مقدار رشتهای را به آن ارسال کنید و پایهی مناسب آن را تعیین نکنید، نتایج غیره منتظرهای (unexpected) را باز میگرداند . برای مثال:
# Returns 8, not 10! parseInt('010') is 8
# Use base 10 for the correct result parseInt('010', 10) is 10
Strict mode
Strict mode یکی از قابلیتهای ECMAScript 5 است که به شما اجازه میدهد تا یک برنامه یا تابع جاوااسکریپت را در محیطی محدود اجرا کنید. این محدودیت موجب نمایش بیشتر خطاها و هشدارها نسبت به حالت نرمال میشود و به توسعه دهندگان این امکان را میدهد تا از نوشتن کدهای غیر قابل بهینه سازی برای اشتباهات رایج جلوگیری کنند.
به عبارت دیگر Strict mode باعث کاهش اشکالات، افزایش امنیت، بهبود عملکرد و حذف برخی از سختیهای استفاده از ویژگیهای زبان میشود.
در حال حاضر Strict mode، در مرورگرهای زیر پشتیبانی میشود:
- Chrome >= 13.0
- Safari >= 5.0
- Opera >= 12.0
- Firefox >= 4.0
- IE >= 10.0
با این حال، Strict mode به طور کامل با مرورگرهای قدیمی سازگار است.
تغییرات Strict mode
- خطا در پروپرتیها و نام آرگومانهای تابع تکراری
- خطا در عدم استفادهی صحیح از delete
- خطا در زمان دسترسی به arguments.caller و arguments.callee (به دلایل عملکرد)
- استفاده از عمگر with سبب بروز خطای نحوی میشود
- متغیرهای خاص مانند undefined که قابل نوشتن نیستند
- معرفی کلمات کلیدی رزرو شده مانند implements, interface, let, package, private, protected, public, static و yield.
با این حال، برخی از رفتارهای زمان اجرای Strict mode نیز تغییر کرده است:
- متغییرهای سراسری به صورت صریح و روشن هستند (کلمه کلیدی var نیاز است). مقدار سراسری this نیز به صورت undefined است.
- eval نمیتواند متغیر جدیدی را در حوزهی محلی خود تعریف کند.
- بدنهی هر تابع باید قبل از استفاده تعریف شده باشد (قبلا گفتم که در جاوااسکریپت شما میتوانید قبل از تعریف تابع آن را فراخوانی کنید).
- آرگومانها تغییر ناپذیر هستند.
CoffeeScript در حال حاضر بسیاری از الزامات Strict mode را پیاده سازی کردهاست مانند: همیشه از کلمه کلیدی var برای تعریف متغیر استفاده میکند؛ اما فعال کردن Strict mode در برنامههای CoffeeScript نیز بسیار مفید خواهد بود. در واقع CoffeeScript بر روی انطباق برنامهها با Strict mode در زمان کامپایل را، در برنامههای آینده خود دارد.
استفاده از Strict mode
برای فعال کردن بررسی محدودیت، کد و توابع خود را با این رشته شروع کنید:-> "use strict" # ... your code ...
do -> "use strict" console.log(arguments.callee)
Strict mode دسترسی به arguments.callee و arguments.caller، که تاثیر بدی را بر روی عملکرد کد شما دارند، حذف میکند و استفادهی از آنها سبب بروز خطا میشود.
در مثال زیر در حالت strict mode سبب بروز خطای TypeError میشود، اما در حالت نرمال به خوبی اجرا شده و یک متغیر سراسری را ایجاد میکند.
do -> "use strict" class @Spine
do -> "use strict" class window.Spine
شما میتوانید در زمان توسعه برنامه جاوااسکریپت خود Strict mode را فعال کنید و در زمان انتشار، بدون Strict mode برنامهی خود را منتشر کنید.
JavaScript Lint
JavaScript Lint یک ابزار بررسی کیفیت کدهای جاوااسکریپت است و اجرای برنامهی شما از طریق این راه عالی باعث بهبود کیفیت و بهترین شیوهی کد نویسی میشود. این پروژه براساس ابزار JSLint است. شما میتوانید چک لیست سایت JSLint را که شامل موضوعاتی است که باید آنها در نظر داشته باشید، مانند متغیرهای سراسری، فراموش کردن نوشتن سمی کالن، کیفیت ضعیف عمل مقایسه را نام برد.
خبر خوب این است که CoffeeScript تمام موارد گفته شدهی در چک لیست را انجام میدهد. بنابراین کد تولیدی CoffeeScript با JavaScript Lint کاملا سازگار است. در واقع ابزار coffee از lint ،option پشتیبانی میکند.
coffee --lint index.coffee index.coffee: 0 error(s), 0 warning(s)
listOfActualTags از بانک اطلاعاتی دریافت شده؛ بر اساس مواردی که موجود بوده.
به این ترتیب چون این تگها به سیستم ردیابی EF وارد میشوند و همچنین post1.Tags.Clear در ابتدای کار فراخوانی شده، استفاده از متد (post1.Tags.Add(item سبب ثبت مورد تکراری نخواهد شد.
کلا EF هر آیتمی رو که Id آنرا از طریق دریافت اطلاعات از بانک اطلاعاتی در سیستم ردیابی خودش داشته باشه، جدید و تکراری ثبت نمیکنه. برای نمونه در حالت new Tag استفاده شده، این موارد جدید ثبت میشوند چون Id از قبل ثبت شدهای ندارند.
برای توضیحات بیشتر مراجعه کنید به مطلب نحوه استفاده از کلیدهای خارجی در EF. (حتی میشود یک شیء را بدون واکشی از دیتابیس به سیستم ردیابی وارد کرد؛ البته اگر Id آنرا داشته باشید)
EF Code First #7
یکی دیگر از تکنیکهای Refactoring بسیار متداول، «حذف کدهای تکراری» است. کدهای تکراری هم عموما حاصل بیحوصلگی یا تنبلی هستند و برنامه نویس نیاز دارد در زمانی کوتاه، حجم قابل توجهی کد تولید کند؛ که نتیجهاش مثلا به صورت زیر خواهد شد:
using System;
namespace Refactoring.Day4.RemoveDuplication.Before
{
public class PersonalRecord
{
public DateTime DateArchived { get; private set; }
public bool Archived { get; private set; }
public void ArchiveRecord()
{
Archived = true;
DateArchived = DateTime.Now;
}
public void CloseRecord()
{
Archived = true;
DateArchived = DateTime.Now;
}
}
}
Refactoring ما هم در اینجا عموما به انتقال کدهای تکراری به یک متد مشترک خلاصه میشود:
using System;
namespace Refactoring.Day4.RemoveDuplication.After
{
public class PersonalRecord
{
public DateTime DateArchived { get; private set; }
public bool Archived { get; private set; }
public void ArchiveRecord()
{
switchToArchived();
}
public void CloseRecord()
{
switchToArchived();
}
private void switchToArchived()
{
Archived = true;
DateArchived = DateTime.Now;
}
}
}
اهمیت حذف کدهای تکراری:
- اگر باگی در این کدهای تکراری یافت شود، همه را در سراسر برنامه باید اصلاح کنید (زیرا هم اکنون همانند یک ویروس به سراسر برنامه سرایت کردهاست) و احتمال فراموشی یک قسمت هم ممکن است وجود داشته باشد.
- اگر نیاز به بهبود یا تغییری در این قسمتهای تکراری وجود داشت، باز هم کار برنامه نویس به شدت زیاد خواهد بود.
ابزارهای کمکی:
واقعیت این است که در قطعه کد کوتاه فوق، یافتن قسمتهای تکراری بسیار ساده بوده و با یک نگاه قابل تشخیص است؛ اما در برنامههای بزرگ خیر. به همین منظور تعداد قابل توجهی برنامهی کمکی جهت تشخیص کدهای تکراری پروژهها تابحال تولید شدهاند؛ مانند CopyPasteKiller، Clone detective و غیره.
علاوه بر اینها نگارش بعدی ویژوال استودیو (نگارش 11) حاوی ابزار Code Clone Detection توکاری است (+) و همچنین یک لیست قابل توجه دیگر را در این زمینه در این پرسش و پاسخ میتوانید بیابید: (+)
ECMAScript 5
در حالیکه ECMAScript 5 قابلیتهای فوق العادهای را برای کنترل کردن خصوصیات موجود در اشیاء، در اختیار شما قرار میدهد، اما هیچ راه کاری را برای خصوصیاتی که موجود نیستند، ندارد. شما میتوانید برای خواص موجود، از رونویسی (تنظیم writable برابر false) و یا حذف شدن (تنظیم configurable برابر false) جلوگیری کنید. شما میتوانید از اختصاص خصوصیات جدید به اشیاء با استفاده از ()Object.preventExtensions و یا تنظیم تمام خصوصیات به صورت فقط خواندنی و یا غیرقابل حذف ()Object.freeze جلوگیری کنید.
اگر شما نمیخواهید تمام خصوصیات را فقط خواندنی کنید میتوانید از ()Object.seal استفاده کنید. اینها مانع از اضافه کردن خصوصیات و یا حذف کردن خصوصیات موجود میشوند. اگر به یک شیء مهر و موم شده (sealed)، زمانی که از strict mode استفاده میکنید، یک خصوصیت جدید اضافه کنید باعث ایجاد خطا میشود:
"use strict"; var person = { name: "Vahid Mohammad Taheri" }; Object.seal(person); person.age = 27; // Error!
نجات با Proxyها
پروکسیها، دارای سابقه طولانی و پیچیده ای در ECMAScript 6 است. طرح اولیه آن توسط Firefox و Chrome قبل از تصمیم TC-39 به تغییر پروکسیها، اجرا شده است. این تغییرات، برای بهتر و روانتر شدن پروکسیها از طرح اولیه پروکسیها انجام گرفت.
بزرگترین تغییر صورت گرفته، معرفی شیء هدف که میخواست با پروکسی در تعامل باشد، بود. به جای تعریف دام برای نوعهای مختلفی از عملیات، با ایجاد پروکسی، مستقیما برای عملیاتی از قبل تعیین شده بر روی اشیاء هدف، این کار را انجام میدهیم.
این کار از طریق یک سری از روشهایی که به مخفی کردن عملیات در ECMAScript مطابقت دارند، انجام میشود. به عنوان مثال زمانیکه بر روی یک ویژگی از یک شیء، عمل خواندن انجام میشود، عملیات [[Get]]
در موتور جاوااسکریپت انجام میگیرد. نحوهی رفتار [[Get]]
را نمیتوان تغییر داد؛ با این حال، با استفاده از پروکسیها میتوان دامی برای زمان فراخوانی [[Get]]
قرار داد و عملیات خاص مورد نظر خود را اعمال کرد. به مثال زیر توجه کنید:
var proxy = new Proxy({ name: "Vahid" }, { get: function(target, property) { if (property in target) { return target[property]; } else { return 13; } } }); console.log(proxy.time); // 13 console.log(proxy.name); // "Vahid" console.log(proxy.title); // 13
[[Get]]
به دام افتاده و تابع تعریف شدهی ما اجرا میشود (باقی عملیات به صورت عادی اجرا میشوند). دامی که برای شیء مورد نظر تعریف کردهایم دو پارامتر دریافت میکند (اول شی هدف، دوم ویژگی مورد نظر). با استفاده از کد نوشته شده در آن ابتدا بررسی میشود که شیء مورد نظر دارای ویژگی ارسال شده است یا خیر؟ در صورتی که وجود داشته باشد، مقدار آن بازگشت داده میشود و در غیر اینصورت به صورت ثابت مقدار 13 برگشت داده میشود.برای ایجاد اشیاء دفاعی لازم است چگونگی رهگیری عملیات
[[Get]]
را درک کنید و هدف از این کار صدور خطا در زمان دستیابی به ویژگی ای از شیءایی که وجود ندارد است.function createDefensiveObject(target) { return new Proxy(target, { get: function(target, property) { if (property in target) { return target[property]; } else { throw new ReferenceError("Property \"" + property + "\" does not exist."); } } }); }
تابع
()createDefensiveObject
یک شیء را به عنوان هدف میپذیرد و یک شیء دفاعی برای آن ایجاد میکند. پروکسی یک دام به نام get دارد؛ برای زمانی که عمل خواندن انجام میشود. اگر ویژگی خوانده شده در شیء وجود داشت، مقدار آن برگشت داده میشود و از سوی دیگر، وقتی ویژگی خوانده شده در شیء وجود نداشته باشد، سبب بروز خطا میشود. به مثال زیر توجه کنید:var person = { name: "Vahid" }; var defensivePerson = createDefensiveObject(person); console.log(defensivePerson.name); // "Vahid" console.log(defensivePerson.age); // Error!
اشیاء دفاعی باعث میشوند تا بر روی ویژگیهایی که در شیء وجود دارند، بتوان عمل خواندن را انجام داد و در ویژگیهایی که موجود نیستند در هنگام خواندن، باعث صدور پیام خطا میشوند. با این حال هنوز هم شما میتوانید ویژگیهای جدید را بدون خطا اضافه کنید:
var person = { name: "Vahid" }; var defensivePerson = createDefensiveObject(person); console.log(defensivePerson.name); // "Vahid" defensivePerson.age = 13; console.log(defensivePerson.age); // 13
روشهای تشخیص ویژگیهای استاندارد هنوز هم به طور معمول و بدون خطا کار میکنند.
var person = { name: "Vahid" }; var defensivePerson = createDefensiveObject(person); console.log("name" in defensivePerson); // true console.log(defensivePerson.hasOwnProperty("name")); // true console.log("age" in defensivePerson); // false console.log(defensivePerson.hasOwnProperty("age")); // false
var person = { name: "Vahid" }; Object.preventExtensions(person); var defensivePerson = createDefensiveObject(person); defensivePerson.age = 27; // Error! console.log(defensivePerson.age); // Error!
defensivePerson
برای هر دو حالت خواندن و نوشتن ویژگیهایی که وجود ندارند، خطا صادر میکند.شاید مفیدترین زمان برای استفاده از اشیاء دفاعی، در هنگام تعریف یک سازنده باشد و شما میتوانید این کار را به عنوان یک قرارداد در نوشتن اشیاء حفظ کنید.
برای مثال:
function Person(name) { this.name = name; return createDefensiveObject(this); } var person = new Person("Vahid"); console.log(person.age); // Error!
()createDefensiveObject
درون سازنده، میتوانید اطمینان کامل داشته باشید که همهی نمونههای ساخته شدهی از شیء Person، دارای حالت دفاعی میباشند.زمان ریلیز نسخه .net core
C# 7 - Throw Expressions