شما نباید درستی پارامترهای ورودی توابع را چک کنید

آیا باید درستی پارامترهای ورودی توابع را چک کرد؟ پاسخ ما منفی است! پیشنهاد ما استفاده از decoratorها برای اعتبارسنجی پارامترهاست.

آیا شما پارامترهای ورودی توابع را اعتبارسنجی می‌کنید که به عنوان مثال null نباشد یا محدودیت‌های مساله برای آن برقرار باشد؟ توصیه ما این است که حتی اگر قبلا چنین کاری می‌کردید دیگر انجام ندهید! اجازه دهید که تابع با null pointer یا خطاهای دیگر کرش کند. ممکن است در نگاه اول غیرمنطقی به نظر برسد اما پیشنهاد ما استفاده از decoratorهای اعتبارسنجی است.

decorator یکی از الگوهای طراحی است که به کلاس‌ها اجازه می‌دهد رفتارشان به صورت پویا در زمان اجرا گسترش پیدا کند. یا به عبارتی به اشیا ویژگی‌های جدیدی را در زمان اجرا اضافه می‌کند. اگر یک قاب عکس را در نظر بگیرید، عکس شی اصلی ماست که ویژگی های خاص خود را دارد. برای نمایش دادن و تزیین آن، یک قاب به عکس اضافه می‌شود که این قاب همان decorator به حساب می‌آید.

در صورتی از این الگو استفاده می‌شود که

• مسئولیت‌ها و رفتار اشیا لازم است به صورت پویا تغییر کند.
• پیاده‌سازی اصلی لازم است از مسئولیت‌ها و رفتارها جدا باشد.

هرچند این کار با تعریف چندین زیرکلاس قابل انجام است اما تعریف تعداد زیادی زیرکلاس کار خوبی نیست و فرایند مراقبت و نگهداری را پیچیده می‌کند چرا که برای هر ترکیب احتمالی از رفتار نیاز به یک زیر کلاس خواهد بود. پس در ادامه خواهیم گفت این الگو برای اعتبارسنجی دقیقا همان چیزی است که احتیاج داریم.

کد زیر را در نظر بگیرید:

class Report {    void export(File file) {      if (file == null) {        throw new IllegalArgumentException( "File is NULL; can't export." );      }      if (file.exists()) {        throw new IllegalArgumentException( "File already exists." );      }      // Export the report to the file    }  }

کاملا تدافعی است درسته؟ اگر کدهای اعتبارسنجی را از آن حذف کنیم کد خیلی کوتاه‌تر خواهد شد اما اگر پیام null باشد کرش می‌کند. یا حتی بدتر اگر فایل قبلا وجود داشته باشد بدون هیچ پرتاب خطایی، گزارش overwrite می‌شود. خطرناک است. درسته؟

بله باید خودمان را محافظت کنیم و باید تدافعی باشیم.

اما نه از این راه، نه از طریق غرق کردن کلاس در کدهای اعتبارسنجی که کاری در رابطه با قابلیت اصلی آن انجام نمی‌دهند. به جای آن لازم است که از decoratorها برای اعتبارسنجی استفاده کنیم. حال در این مثال نحوه انجام این‌کار را نشان می‌دهیم. اول لازم است که یک interface تعریف کنیم:

interface Report {    void export(File file);  }

سپس یک کلاس که قابلیت اصلی را پیاده‌سازی می‌کند:

class DefaultReport implements Report {    @Override void export(File file) {      // Export the report to the file    }  }

و در نهایت تعدادی decorator که از ما محافظت می‌کنند:

class NoWriteOverReport implements Report {    private final Report origin;    NoWriteOverReport(Report rep) {      this.origin = rep;    }    @Override void export(File file) {      if (file.exists()) {        throw new IllegalArgumentException( "File already exists." );      }      this.origin.export(file);    }  }

حالا کلاینت این انعطاف‌پذیری را دارد که اشیا پیچیده‌ای از decoratorها را که کار خاصی را انجام می‌دهند با هم ترکیب کند. شی اصلی کار گزارش‌دهی را انجام می‌دهد، در حالیکه decoratorها پارامترها اعتبارسنجی می‌کنند:

Report report = new NoNullReport( new NoWriteOverReport( new DefaultReport() ) );  report.export(file);

اما پیروی از چنین رویکردی چه سودی دارد؟

اولین و مهم‌ترین مزیت آن کوچک شدن اشیا است. همواره نگهداری و مراقبت از اشیا کوچک‌تر ساده‌تر است. مهم‌ نیست که در آینده چند نوع اعتبارسنج پیاده‌سازی می‌کنیم کلاس DefaultReport همواره کوچک خواهد ماند. هر چه اعتبارسنجی بیشتری نیاز باشد decoratorهای بیشتری ساخته خواهد شد و همه آن‌ها کوچک و یکپارچه خواهد بود و این امکان را به ما خواهد داد که چند تا از آن‌ها را در انواع مختلف در کنار هم قرار دهیم.

به علاوه، این رویکرد به کد قابلیت استفاده مجدد می‌دهد، چرا که کلاس‌ها کار کمی انجام می‌دهند و به طور پیش‌فرض از خود دفاع نمی‌کنند. درست است که تدافعی بودن کد خیلی مهم است و برای این منظور ما از decoratorها استفاده می‌کنیم. اما اجرای کد در چنین حالت تدافعی همواره ممکن نیست. گاهی اعتبارسنجی خیلی از لحاظ زمان و حافظه هزینه‌بر خواهد بود و ما ترجیح خواهیم داد که مستقیما با اشیا کار کنیم و از آن‌ها دفاع نکنیم.

نظر شما چیست؟ شما نیز با چنین رویکردی موافق هستید؟

منابع:

https://dzone.com/

http://www.cnblogs.com/