Re[2]: Как не стоит писать код
От: Огинский Евгений Украина  
Дата: 01.03.12 21:24
Оценка:
Здравствуйте, Undying, Вы писали:

U>Кстати, вы не видите противоречий между этими двумя приемами упрощения?


Противоречий по-моему нет.

U>Первый прием. Код:


U>
U>// Не отправлено ли уведомление ранее и наступило ли время отправки уведомления.
U>if (!context.Order.Fields.ContainsKey("OrderMailSend") 
U>  && (context.Order.PaymentStatus == PaymentStatus.Paid 
U>      || (context.Order.PaymentStatus == PaymentStatus.InProgress 
U>        && GetPaymentMethod(context).StartsWith("banktransfer")
U>     )
U>   )
U>)
U>{
U>  IEnumerable<string> email = GetEmailAddress(context);
U>  MailNotification.SendOrderConfirmation(email, context.Order);
U>  // Отмечаем что уведомление о заказе отправлено
U>  context.Order.Fields.Add(
U>    new EntityField { Name = "OrderMailSend", Value = true });
U>}
U>


U>Заменен на:


U>
U>if (!OrderMailSent(context) && MailNotificationRequired(context))
U>{
U>  IEnumerable<string> email = GetEmailAddress(context);
U>  MailNotification.SendOrderConfirmation(email, context.Order);
U>  MarkOrderAsSent(context);
U>}
U>


U>Что здесь по сути сделано? Сложные вызовы заменены на короткие псевдонимы.


Не совсем. Здесь сложные вызовы разбиты на логически завершенные операции, которые выполняют одно действие и имеют понятные имена. Если бы мы просто хотели заменить сложные вызовы на короткие псевдонимы, то написали бы так:

if (OrderMailNotSentAndMailNotificationRequired(context))
{
  SendOrderConfirmationAndMarkOrderAsSent(context);
}


U>Второй прием. Код:


U>
U>public int Quantity
U>{
U>  get
U>  {
U>    int quantity;
U>    if(int.TryParse(TxtQuantity.Text, out quantity))
U>      return quantity;
    
U>    return 0;
U>  }
U>}
U>


U>Заменен на:


U>
U>public int Quantity
U> {
U>   get
U>   {
U>     if (!int.Valid(TxtQuantity.Text))
U>       return 0;

U>     return int.Parse(TxtQuantity.Text);
U>   }
U> }
U>


U>Что здесь по сути сделано? Множественное использование короткого псевдонима заменено на множественное использование сложных вызовов.


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