5 عادت مفید توسعه دهندگان نرم افزار-عادت اول

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

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

مقدمه ای بر یک مفهوم کلیدی:وضعیت (State) یا رفتار (Behavior) ؟

ساخت نرم افزاری که خوانایی خوبی داشته باشه الزاما با تعریف اشیایی آغاز میشن که دارای وضعیت و رفتار باشند.وضعیت ، به داده ای از شی ء اطلاق میشه که در فراخوانی متدهای شی ء ، ثابت میمونه و تغییری نمیکنه و حاوی مقادیری از شی ء هست که باید در این فراخوانیها حفظ بشن.بعنوان مثال در جاوا ، یک شی ء میتونه وضعیت رو موقتا در متغییرهای نمونه ای از اون شی ء که شاخته شده ذخیره کنه و یا یکباره همه اونها رو در محلی ثابت ذخیره کنه که میتونه یک بانک اطلاعاتی و یا وب سرویس باشه.هر شی ء عموما دارای متدهایی هست که مدیریت متغییرها و داده های وضعیت رو بعهده دارند.(State-Changing Methods)

رفتار ، به توانایی نمونه ساخته شده از شی ء برای پاسخگویی به نیازها و یا پرسشهایی بر اساس مقادیر داده های وضعیت اطلاق میشه.متدهای رفتار ، این پاسخها رو بدون دستکاری داده های وضعیت ارائه می کنند و غالبا بخشی از لایه Business Logic یک کاربرد یا برنامه هستند.

بگذارید یک مثال ساده بزنم: رابط ICustomerAccount زیر ، متدهایی رو برای مدیریت حساب بانکی شخص تعریف می کنه که امکان افتتاح یک حساب جدید ، بارگذاری وضعیت حساب یک شخص ، تعیین فعال و یا غیر فعال بودن اون حساب و … رو فراهم می کنه:

public interface ICustomerAccount {
  //State-changing methods
  public void createNewActiveAccount()
                   throws CustomerAccountsSystemOutageException;
  public void loadAccountStatus()
                   throws CustomerAccountsSystemOutageException;
  //Behavior methods
  public boolean isRequestedUsernameValid();
  public boolean isRequestedPasswordValid();
  public boolean isActiveForPurchasing();
  public String getPostLogonMessage();
}

و اما عادات مهم:
عادت اول: متد سازنده (Constructor) باید حداقل کار ممکن رو انجام بده و نه بیشتر! بعبارت دیگر سعی کنید متد سازنده ، تنها متغییرهای اصلی و پایه رو با آرگومانهاش پر کنه و یک نمونه از شی ء رو بسازه.همانطور که در کد زیر می بینید متد سازنده بسیار ساده نوشته شده و تنها متغییرهاشو با آرگومانهای سازنده پر می کنه:

public class CustomerAccount implements ICustomerAccount{
  //Instance variables.
  private String username;
  private String password;
  protected String accountStatus;

  //Constructor that performs minimal work.
  public CustomerAccount(String username, String password) {
    this.password = password;
    this.username = username;
  }
}

همانطور که میدونید وظیقه تابع سازنده ، ایجاد یک نمونه از شیء پایه و مقدارگذاری اولیه اون هست و معمولا نام متد سازنده همنام با نام شیء هست و ازاونجاییکه این نام با نام شی ء یکی هست ، نمیتونه نمادی از کاری باشه که شیء انجام میده و بنابر این بهتره که حداقل کار ممکن رو در سازنده تعریف کنیم , و بگذاریم متدهای کنترلی وضعیت و رفتار راحت باشن!

String username = "robertmiller";
String password = "java.net";
ICustomerAccount ca = new CustomerAccount(username, password);
if(ca.isRequestedUsernameValid() && ca.isRequestedPasswordValid()) {
   ...
   ca.createNewActiveAccount();
   ...
}

بعبارت دیگه ، کدهایی که سازندشون بیشتر از آنچه گفته شد رو در بر بگیرن ، خوانایی خوبی ندارن و درک کد برای سایر اعضای تیمتون مشکل خواهد بود.حالا سازنده رو بازنویسی می کنیم.سازنده زیر یک سازنده دیگه رو صدا میزنه که داده هایی رو از وب سرویس و یا بانک اطلاعاتی بارگذاری بکنه:

//Constructor that performs too much work!
public CustomerAccount(String username, String password)
                  throws CustomerAccountsSystemOutageException {

  this.password = password;
  this.username = username;
  this.loadAccountStatus();//unnecessary work.
}
//Remote call to the database or web service.
public void loadAccountStatus()
                  throws CustomerAccountsSystemOutageException {
  ...
}

در کد بالا ، برنامه نویسی که از شی ء استفاده میکنه ، ممکنه ندونه که متد سازنده ، خودش ، هم داره یک فراخوانی دور انجام میده و داده ها رو از بانک اطلاعاتی میخونه بنابر این ممکنه اشتباه بکنه و در برنامش اینکار رو انجام بده و در نتیجه عملیات فراخوانی تابع ، دوبار انجام میشه.یکبار توسط تابع سازنده و بار دوم توسط برنامه نویس استفاده کننده از شی ء:

String username = "robertmiller";
String password = "java.net";
try {
  //makes a remote call
  ICustomerAccount ca = new CustomerAccount(username, password);
  //makes a second remote call
  ca.loadAccountStatus();
} catch (CustomerAccountsSystemOutageException e) {
  ...
}

و یا اینکه برنامه نویس استفاده کننده از شی ء ممکنه ، این سازنده رو مجددا جهت Validation استفاده بکنه و هربار که اینکار رو انجام میده ، تابع فراخوانی دور که در سازنده تعریف کردید ، بیهوده اجرا میشه. در نمونه زیر ، توابع isRequestedUsernameValid و isRequestedPasswordValid توسط برنامه نویس استفاده شدن که باعث میشن که دوبار عملیات فراخوانی دور در سازنده ، بیهوده ، اجرا بشه:

String username = "robertmiller";
String password = "java.net";
try {
  //makes unnecessary remote call
  ICustomerAccount ca = new CustomerAccount(username, password);
  if(ca.isRequestedUsernameValid() && ca.isRequestedPasswordValid()) {
    ...
    ca.createNewActiveAccount();
    ...
  }
} catch (CustomerAccountsSystemOutageException e){
  ...
}

ادامه در پست بعدی….