public enum CustomerType 
{ 
     Person = 0, 
     Company = 1 
} 
public class Customer 
{ 
    public CustomerType Type { get; set; } 
}

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

switch (customer.Type) 
{ 
      case CustomerType.Person: 
         // calculate discount, or send message or edit customer or anything else 
          break; 
      case CustomerType.Company: 
          // calculate discount, or send message or edit customer or anything else 
          break; 
      default: 
          throw new ArgumentOutOfRangeException(); 
 }

برای انجام فعالیت‌های مختلفی مانند محاسبه تخفیف، ارسال پیام و یا ویرایش مشتری، نیاز خواهد بود این گذاره تکرار شود که خود این موضوع بوی بد duplicate code است و به الگوی shotgun surgery نیز ختم خواهد شد. 

حال فرض کنید نیاز است مشتریان حقوقی، خود به دو نوع مشتری حقوقی بخش خصوصی و مشتری حقوقی بخش دولتی تقسیم شوند. در پیاده سازی ذکر شده باید به CustomerType یک آیتم افزوده شود و در تمامی switch‌ها نیز در صورت نیاز شرط مربوط به آن اضافه شود.  

برای حل این نوع از کد بد بو، معمولا یک کلاس پدر را به نام مشتری ایجاد کرده و کلاس‌های مختص هر یک از انواع مشتری را از آن به ارث می‌برند (Replace type code with subclass):

یا می‌توان طراحی را کمی متفاوت‌تر و به صورت زیر انجام داد:

دلیل مشابه دیگر ایجاد این الگوی بد کد استفاده از type code به عنوان وضعیت یک تایپ است. که در این صورت می‌توان بجای type code از state object استفاده کرد (Replace type code with strategy). به این مورد در مباحث مربوط به refactoring به طور مفصل پرداخته شده است.

جمع بندی 

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