مطلبی رو  اینجا دیدم که به نظر طنز هست و مرتبط به مطلب جاری

In the C++ world we don’t create a class witch contains 5 methods and 2 fields like in Java or C#. We do more. A lot more. Our class are consequent and take a lot of stuff inside because it is interesting to have a project with 10 files of 100 KB rather than 300 files of 3 KB organized with fuzzy concepts. We do OOP better. It’s more compact, it’s real, it just works

بله. توضیح دادم چرا. چون طراحی جدول شما اشتباه هست. اگر عدد وارد می‌کنید، نوع فیلد را int تعیین کنید. مابقی آن به صورت خودکار درست می‌شود (و نیازی به هیچ نکته‌ی خاصی هم ندارد). اگر الزامی به ورود رشته هست، باید بجای 10 بنویسید 010 تا مقایسه‌ها درست شوند (این 0‌های پیش از اعداد باید تعداد کاراکترها را به تعداد کاراکترهای بزرگترین عدد رشته‌ای که دارید برساند؛ اگر بزرگترین عدد شد 1000 باید تمام این‌ها را به 0010 اصلاح کنید). چون این‌ها رشته هستند نه عدد. تمام داده‌ها وارد شده هم باید به همین صورت اصلاح شوند. روش دیگر هم این است که مستقیما SQL بنویسید و (cast(code as int کنید. راه دیگری ندارد. حتی کوئری SQL ایی هم که در بالا نوشتید جواب نمی‌دهد چون cast as int ندارد. بنابراین ساده‌ترین و منطقی‌ترین روش، انتخاب نوع فیلد مناسب هست.

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

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

چرا enum قابلیت refactoring خوبی ندارد؟  با این بسته بندی enum در یک کلاس و بالا بردن درجه‌ی پیچیدگی کد، دقیقا چه ارزش افزوده‌ای را خلق کردید؟ بحث حالت و رفتار باید در کلاس استفاده کننده‌ی از نوع enum مطرح شود یا در کلاسی که یک نوع enum را مجددا بسته بندی کرده؟

با این بسته بندی این مشکلات را ایجاد کرده‌اید:

- یک کد ساده تبدیل به یک کد پیچیده شده‌است.

- عبارات switch با حالت enum-as-class کار نمی‌کند.

- مشکلات serialization و عکس آن‌را سبب خواهید شد.