اینٹی پیٹرن کیا ہیں؟ آئیے کچھ مثالیں دیکھتے ہیں (حصہ 2)

اینٹی پیٹرن کیا ہیں؟ آئیے کچھ مثالیں دیکھتے ہیں (حصہ 1) آج ہم سب سے مشہور اینٹی پیٹرن کا اپنا جائزہ جاری رکھیں گے۔ اگر آپ نے پہلا حصہ چھوڑا ہے، تو یہ ہے۔ لہذا، ڈیزائن پیٹرن بہترین عمل ہیں. دوسرے لفظوں میں، وہ مخصوص مسائل کو حل کرنے کے اچھے، وقتی آزمائشی طریقوں کی مثالیں ہیں۔ بدلے میں، مخالف پیٹرن ان کے بالکل برعکس ہیں، اس معنی میں کہ وہ مختلف مسائل (برائی پیٹرن) کو حل کرتے وقت نقصانات یا غلطیوں کے نمونے ہیں۔ آئیے اگلے سافٹ ویئر ڈویلپمنٹ اینٹی پیٹرن کی طرف بڑھتے ہیں۔

8. گولڈن ہتھوڑا

گولڈن ہتھوڑا ایک اینٹی پیٹرن ہے جس کی وضاحت اس اعتماد سے ہوتی ہے کہ ایک خاص حل عالمی طور پر لاگو ہوتا ہے۔ مثالیں:

1. کسی مسئلے کا سامنا کرنے اور کامل حل کے لیے ایک نمونہ تلاش کرنے کے بعد، ایک پروگرامر مخصوص معاملات کے لیے مناسب حل تلاش کرنے کے بجائے، موجودہ اور مستقبل کے تمام پروجیکٹس پر اس پیٹرن کو ہر جگہ چپکانے کی کوشش کرتا ہے۔

2. کچھ ڈویلپرز نے ایک بار ایک مخصوص صورت حال کے لیے کیشے کا اپنا مختلف قسم بنایا تھا (کیونکہ کوئی اور چیز مناسب نہیں تھی)۔ بعد میں، اگلے پروجیکٹ پر جس میں کوئی خاص کیش منطق شامل نہیں تھی، انہوں نے ریڈی میڈ لائبریریوں (مثال کے طور پر، Ehcache) کو استعمال کرنے کے بجائے اپنے مختلف قسم کو دوبارہ استعمال کیا۔ نتیجہ کیڑے اور عدم مطابقتوں کا ایک گروپ تھا، ساتھ ہی ساتھ بہت زیادہ وقت اور تلی ہوئی اعصاب کا ضیاع ہوا۔

   کوئی بھی اس مخالف پیٹرن کے لئے گر سکتا ہے. اگر آپ ابتدائی ہیں، تو ہو سکتا ہے آپ کو ڈیزائن کے نمونوں کے بارے میں علم نہ ہو۔ اس سے آپ تمام مسائل کو ایک ہی طریقے سے حل کرنے کی کوشش کر سکتے ہیں جس میں آپ نے مہارت حاصل کی ہے۔ اگر ہم پیشہ ور افراد کے بارے میں بات کر رہے ہیں، تو ہم اسے پیشہ ورانہ ڈیفارمیشن یا nerdview کہتے ہیں۔ آپ کے اپنے پسندیدہ ڈیزائن پیٹرن ہیں، اور آپ صحیح کو استعمال کرنے کے بجائے، آپ اپنی پسند کا استعمال کرتے ہیں، یہ فرض کرتے ہوئے کہ ماضی میں اچھا فٹ ہونا مستقبل میں اسی نتیجے کی ضمانت دیتا ہے۔

   یہ خرابی بہت افسوسناک نتائج پیدا کر سکتی ہے - ایک خراب، غیر مستحکم، اور عملدرآمد کو برقرار رکھنا مشکل سے لے کر منصوبے کی مکمل ناکامی تک۔ جس طرح تمام بیماریوں کے لیے کوئی ایک گولی نہیں ہے، اسی طرح تمام مواقع کے لیے کوئی ایک ڈیزائن پیٹرن نہیں ہے۔

9. قبل از وقت اصلاح

قبل از وقت اصلاح ایک اینٹی پیٹرن ہے جس کا نام خود بولتا ہے۔ "پروگرامرز کوڈ میں غیر اہم جگہوں کے بارے میں سوچنے اور فکر کرنے اور انہیں بہتر بنانے کی کوشش کرنے میں بہت زیادہ وقت صرف کرتے ہیں، جو صرف بعد میں ڈیبگنگ اور سپورٹ پر منفی اثر ڈالتا ہے۔ وقت سے پہلے اصلاح تمام برائیوں کی جڑ ہے۔ اس نے کہا، ہمیں باقی 3% پر پوری توجہ دینی چاہیے۔" - ڈونلڈ ناتھ مثال کے طور پر، ڈیٹا بیس میں وقت سے پہلے اشاریہ جات شامل کرنا۔ وہ برا کیوں ہے؟ ٹھیک ہے، یہ اس میں برا ہے، اشاریہ جات بائنری درخت کے طور پر محفوظ کیے جاتے ہیں۔ نتیجے کے طور پر، جب بھی کوئی نئی قدر شامل اور حذف کی جائے گی، درخت کا دوبارہ حساب کیا جائے گا، اور اس میں وسائل اور وقت خرچ ہوتا ہے۔ لہٰذا، اشاریہ جات کو صرف اس صورت میں شامل کیا جانا چاہیے جب فوری ضرورت ہو (اگر آپ کے پاس ڈیٹا کی ایک بڑی مقدار ہے اور سوالات میں بہت زیادہ وقت لگتا ہے) اور صرف سب سے اہم فیلڈز (وہ فیلڈز جن سے اکثر پوچھے جاتے ہیں)۔

10. سپگیٹی کوڈ

Spaghetti کوڈ ایک اینٹی پیٹرن ہے جس کی وضاحت کوڈ کے ذریعے کی جاتی ہے جس کی ساخت خراب، مبہم، اور سمجھنے میں مشکل ہوتی ہے، جس میں ہر قسم کی برانچنگ ہوتی ہے، جیسے ریپنگ استثناء، حالات اور لوپس۔ پہلے، گوٹو آپریٹر اس اینٹی پیٹرن کا اہم اتحادی تھا۔ گوٹو سٹیٹمنٹس واقعی اب استعمال نہیں ہوتے ہیں، جو خوشی سے متعدد متعلقہ مشکلات اور مسائل کو ختم کر دیتے ہیں۔

public boolean someDifficultMethod(List<String> XMLAttrList) {
           ...
   int prefix = stringPool.getPrefixForQName(elementType);
   int elementURI;
   try {
       if (prefix == -1) {
        ...
           if (elementURI != -1) {
               stringPool.setURIForQName(...);
           }
       } else {
        ...
           if (elementURI == -1) {
           ...
           }
       }
   } catch (Exception e) {
       return false;
   }
   if (attrIndex != -1) {
       int index = attrList.getFirstAttr(attrIndex);
       while (index != -1) {
           int attName = attrList.getAttrName(index);
           if (!stringPool.equalNames(...)){
           ...
               if (attPrefix != namespacesPrefix) {
                   if (attPrefix == -1) {
                    ...
                   } else {
                       if (uri == -1) {
                       ...
                       }
                       stringPool.setURIForQName(attName, uri);
                   ...
                   }
                   if (elementDepth >= 0) {
                   ...
                   }
                   elementDepth++;
                   if (elementDepth == fElementTypeStack.length) {
                   ...
                   }
               ...
                   return contentSpecType == fCHILDRENSymbol;
               }
           }
       }
   }
}

یہ خوفناک لگتا ہے، ہے نا؟ بدقسمتی سے، یہ سب سے عام اینٹی پیٹرن ہے :( ایسا کوڈ لکھنے والا بھی مستقبل میں اسے نہیں سمجھ سکے گا۔ کوڈ کو دیکھنے والے دوسرے ڈویلپر سوچیں گے، "ٹھیک ہے، اگر یہ کام کرتا ہے، تو ٹھیک ہے — اس کو ہاتھ نہ لگانا بہتر ہے۔ اکثر طریقہ ابتدائی طور پر آسان اور انتہائی شفاف ہوتا ہے، لیکن جیسے جیسے نئے تقاضے شامل کیے جاتے ہیں، اس طریقہ کو بتدریج زیادہ سے زیادہ مشروط بیانات کے ساتھ جوڑ دیا جاتا ہے، اور اسے اس طرح ایک شیطانیت میں بدل دیا جاتا ہے۔ ظاہر ہوتا ہے، آپ کو اسے مکمل طور پر یا کم از کم سب سے زیادہ مبہم حصوں کو ری فیکٹر کرنے کی ضرورت ہے۔ عام طور پر، جب کسی پروجیکٹ کو شیڈول کرتے ہیں، ری فیکٹرنگ کے لیے وقت مختص کیا جاتا ہے، مثال کے طور پر، سپرنٹ ٹائم کا 30% ری فیکٹرنگ اور ٹیسٹ کے لیے ہوتا ہے۔ یقیناً، یہ فرض کرتا ہے۔ کہ وہاں کوئی جلدی نہیں ہوتی ہے (لیکن ایسا کب ہوتا ہے)۔ آپ کو اسپگیٹی کوڈ اور اس کی ریفیکٹرنگ کی ایک اچھی مثال یہاں مل سکتی ہے ۔

11. جادوئی نمبر

میجک نمبرز ایک اینٹی پیٹرن ہے جس میں کسی پروگرام میں ان کے مقصد یا معنی کی وضاحت کے بغیر تمام قسم کے مستقل استعمال کیے جاتے ہیں۔ یعنی عام طور پر ان کا نام ناقص رکھا جاتا ہے یا انتہائی صورتوں میں، تبصرے کیا ہیں یا کیوں ہوتے ہیں اس کی وضاحت کرنے والا کوئی تبصرہ نہیں ہے۔ سپتیٹی کوڈ کی طرح، یہ سب سے عام اینٹی پیٹرن میں سے ایک ہے۔ کوئی ایسا شخص جس نے کوڈ نہیں لکھا ہو سکتا ہے کہ اسے جادوئی نمبروں یا ان کے کام کرنے کے طریقے کے بارے میں کوئی اشارہ ہو یا نہ ہو (اور وقت کے ساتھ، مصنف خود ان کی وضاحت نہیں کر سکے گا)۔ نتیجے کے طور پر، کسی نمبر کو تبدیل کرنے یا ہٹانے سے کوڈ جادوئی طور پر ایک ساتھ کام کرنا بند کر دیتا ہے۔ مثال کے طور پر، 36 اور 73 ۔ اس اینٹی پیٹرن کا مقابلہ کرنے کے لیے، میں کوڈ کا جائزہ لینے کی تجویز کرتا ہوں۔ آپ کے کوڈ کو ڈویلپرز کے ذریعہ دیکھنے کی ضرورت ہے جو کوڈ کے متعلقہ حصوں میں شامل نہیں ہیں۔ ان کی آنکھیں تروتازہ ہوں گی اور وہ سوال کریں گے کہ یہ کیا ہے اور تم نے ایسا کیوں کیا؟ اور یقینا، آپ کو وضاحتی نام استعمال کرنے یا تبصرے چھوڑنے کی ضرورت ہے۔

12. کاپی اور پیسٹ پروگرامنگ

کاپی اور پیسٹ پروگرامنگ ایک اینٹی پیٹرن ہے جس میں کسی اور کے کوڈ کو بغیر سوچے سمجھے کاپی اور پیسٹ کیا جاتا ہے، جس کے نتیجے میں ممکنہ طور پر غیر متوقع ضمنی اثرات ہوتے ہیں۔ مثال کے طور پر، ریاضی کے حسابات یا پیچیدہ الگورتھم کے ساتھ کاپی اور پیسٹ کرنے کے طریقے جنہیں ہم پوری طرح سے نہیں سمجھتے۔ یہ ہمارے مخصوص کیس کے لیے کام کر سکتا ہے، لیکن کچھ دیگر حالات میں یہ مصیبت کا باعث بن سکتا ہے۔ فرض کریں کہ مجھے ایک صف میں زیادہ سے زیادہ تعداد کا تعین کرنے کے لیے ایک طریقہ درکار ہے۔ انٹرنیٹ کے گرد چکر لگاتے ہوئے، مجھے یہ حل ملا:

public static int max(int[] array) {
   int max = 0;
   for(int i = 0; i < array.length; i++) {
       if (Math.abs(array[i]) > max){
           max = array[i];
       }
   }
   return max;
}

ہمیں 3، 6، 1، 4، اور 2 نمبروں کے ساتھ ایک صف ملتی ہے، اور طریقہ 6 واپس کرتا ہے۔ بہت اچھا، آئیے اسے رکھیں! لیکن بعد میں ہمیں 2.5، -7، 2، اور 3 پر مشتمل ایک صف ملتی ہے، اور پھر ہمارا نتیجہ -7 ہوتا ہے۔ اور یہ نتیجہ اچھا نہیں ہے۔ یہاں مسئلہ یہ ہے کہ Math.abs() مطلق قدر واپس کرتا ہے۔ اس سے لاعلمی تباہی کا باعث بنتی ہے، لیکن صرف بعض حالات میں۔ حل کی گہرائی سے سمجھ کے بغیر، بہت سے ایسے معاملات ہیں جن کی آپ تصدیق نہیں کر پائیں گے۔ کاپی شدہ کوڈ ایپلی کیشن کے اندرونی ڈھانچے سے بھی آگے جا سکتا ہے، دونوں انداز سے اور زیادہ بنیادی، تعمیراتی سطح پر۔ اس طرح کے کوڈ کو پڑھنا اور برقرار رکھنا زیادہ مشکل ہوگا۔ اور یقیناً، ہمیں یہ نہیں بھولنا چاہیے کہ کسی اور کے کوڈ کو سیدھا نقل کرنا ایک خاص قسم کی سرقہ ہے۔ ان صورتوں میں جب ایک پروگرامر پوری طرح سے یہ نہیں سمجھ پاتا کہ وہ کیا کر رہا ہے اور وہ کسی اور کے کام کرنے والے حل کو لینے کا فیصلہ کرتا ہے، تو یہ نہ صرف استقامت کی کمی کو ظاہر کرتا ہے، بلکہ یہ حرکتیں ٹیم، پروجیکٹ، کے لیے نقصان دہ ہیں۔ اور بعض اوقات پوری کمپنی (لہذا احتیاط سے کاپی اور پیسٹ کریں)۔

13. پہیے کو دوبارہ ایجاد کرنا

پہیے کو دوبارہ ایجاد کرنا ایک اینٹی پیٹرن ہے، جسے بعض اوقات مربع پہیے کو دوبارہ ایجاد کرنا بھی کہا جاتا ہے ۔ خلاصہ یہ ہے کہ یہ سانچہ اوپر سمجھے گئے کاپی اور پیسٹ اینٹی پیٹرن کے برعکس ہے۔ اس اینٹی پیٹرن میں، ڈویلپر اس مسئلے کے لیے اپنا حل خود نافذ کرتا ہے جس کے حل پہلے سے موجود ہیں۔ بعض اوقات یہ موجودہ حل پروگرامر کی ایجاد سے بہتر ہوتے ہیں۔ اکثر، یہ صرف کھوئے ہوئے وقت اور کم پیداواری صلاحیت کی طرف جاتا ہے: پروگرامر کو کوئی حل نہیں مل سکتا ہے یا ایسا حل ڈھونڈ سکتا ہے جو بہترین سے دور ہو۔ اس نے کہا، ہم ایک آزاد حل پیدا کرنے کے امکان کو مسترد نہیں کر سکتے، کیونکہ ایسا کرنا کاپی اور پیسٹ پروگرامنگ کا براہ راست راستہ ہے۔ پروگرامر کو ان مخصوص پروگرامنگ کاموں سے رہنمائی حاصل کرنی چاہیے جو انہیں قابلیت کے ساتھ حل کرنے کے لیے پیدا ہوتے ہیں، چاہے وہ تیار حل استعمال کر کے یا حسب ضرورت حل تیار کر کے۔ اکثر، اس مخالف پیٹرن کو استعمال کرنے کی وجہ صرف جلد بازی ہے۔ نتیجہ تیار شدہ حلوں کا (تلاش) ایک اتلی تجزیہ ہے۔ مربع پہیے کو دوبارہ ایجاد کرنا ایک ایسا معاملہ ہے جہاں زیر غور اینٹی پیٹرن کا منفی نتیجہ نکلتا ہے۔ یعنی، پروجیکٹ کو اپنی مرضی کے مطابق حل کی ضرورت ہے، اور ڈویلپر اسے تخلیق کرتا ہے، لیکن بری طرح۔ ایک ہی وقت میں، ایک اچھا آپشن پہلے سے موجود ہے اور دوسرے اسے کامیابی سے استعمال کر رہے ہیں۔ نیچے کی لکیر: وقت کی ایک بڑی رقم ضائع ہو گئی ہے۔ سب سے پہلے، ہم ایسی چیز بناتے ہیں جو کام نہیں کرتی ہے۔ پھر ہم اسے دوبارہ بنانے کی کوشش کرتے ہیں، اور آخر کار ہم اسے کسی ایسی چیز سے بدل دیتے ہیں جو پہلے سے موجود تھی۔ ایک مثال آپ کی اپنی مرضی کے مطابق کیشے کو نافذ کرنا ہے جب بہت سارے نفاذ پہلے سے موجود ہیں۔ اس سے کوئی فرق نہیں پڑتا ہے کہ آپ بحیثیت پروگرامر کتنے ہی باصلاحیت ہیں، آپ کو یاد رکھنا چاہیے کہ مربع پہیے کو دوبارہ ایجاد کرنا کم از کم وقت کا ضیاع ہے۔ اور، جیسا کہ آپ جانتے ہیں، وقت سب سے قیمتی وسیلہ ہے۔

14. یو یو مسئلہ

yo -yo مسئلہ ایک اینٹی پیٹرن ہے جس میں ایپلی کیشن کا ڈھانچہ ضرورت سے زیادہ ٹکڑے ہونے کی وجہ سے حد سے زیادہ پیچیدہ ہے (مثال کے طور پر، ضرورت سے زیادہ ذیلی تقسیم شدہ وراثت کا سلسلہ)۔ "یو یو مسئلہ" اس وقت پیدا ہوتا ہے جب آپ کو کسی ایسے پروگرام کو سمجھنے کی ضرورت ہوتی ہے جس کا وراثت کا درجہ بندی طویل اور پیچیدہ ہے، جس سے گہری نیسٹڈ میتھڈ کالز بنتی ہیں۔ نتیجے کے طور پر، پروگرامرز کو پروگرام کے رویے کا معائنہ کرنے کے لیے بہت سی مختلف کلاسوں اور طریقوں کے درمیان تشریف لے جانے کی ضرورت ہوتی ہے۔ اس اینٹی پیٹرن کا نام کھلونا کے نام سے آیا ہے۔ مثال کے طور پر، آئیے درج ذیل وراثت کے سلسلے کو دیکھیں: ہمارے پاس ٹیکنالوجی انٹرفیس ہے:

public interface Technology {
   void turnOn();
}

ٹرانسپورٹ انٹرفیس اسے وراثت میں ملا ہے:

public interface Transport extends Technology {
   boolean fillUp();
}

اور پھر ہمارے پاس ایک اور انٹرفیس ہے، GroundTransport:

public interface GroundTransportation extends Transport {
   void startMove();
   void brake();
}

اور وہاں سے، ہم ایک تجریدی کار کلاس حاصل کرتے ہیں:

public abstract class Car implements GroundTransportation {
   @Override
   public boolean fillUp() {
       /* some implementation */
       return true;
   }
   @Override
   public void turnOn() {
       /* some implementation */
   }
   public boolean openTheDoor() {
       /* some implementation */
       return true;
   }
   public abstract void fixCar();
}

اگلا خلاصہ ووکس ویگن کلاس ہے:

public abstract class Volkswagen extends Car {
   @Override
   public void startMove() {
       /* some implementation */
   }
   @Override
   public void brake() {
       /* some implementation */
   }
}

اور آخر میں، ایک مخصوص ماڈل:

public class VolkswagenAmarok extends Volkswagen {
   @Override
   public void fixCar(){
       /* some implementation */
   }
}

یہ سلسلہ ہمیں سوالات کے جوابات تلاش کرنے پر مجبور کرتا ہے جیسے:

1. کتنے طریقے ہیں VolkswagenAmarok؟

2. زیادہ سے زیادہ خلاصہ حاصل کرنے کے لیے سوالیہ نشان کے بجائے کس قسم کو داخل کیا جانا چاہیے:

   ? someObj = new VolkswagenAmarok();
          someObj.brake();

اس طرح کے سوالات کا فوری جواب دینا مشکل ہے — اس کے لیے ہمیں ایک نظر ڈالنے اور چھان بین کرنے کی ضرورت ہے، اور الجھن میں پڑنا آسان ہے۔ اور کیا ہوگا اگر درجہ بندی ہر طرح کے اوورلوڈز اور اوور رائیڈز کے ساتھ بہت بڑی، لمبی اور زیادہ پیچیدہ ہو؟ ہمارے پاس جو ڈھانچہ ہوگا وہ ضرورت سے زیادہ ٹکڑے ہونے کی وجہ سے دھندلا ہو جائے گا۔ بہترین حل یہ ہوگا کہ غیر ضروری تقسیم کو کم کیا جائے۔ ہمارے معاملے میں، ہم ٹیکنالوجی → کار → VolkswagenAmarok کو چھوڑ دیں گے۔

15. حادثاتی پیچیدگی

غیر ضروری پیچیدگی ایک اینٹی پیٹرن ہے جس میں حل کے لیے غیر ضروری پیچیدگیوں کو متعارف کرایا جاتا ہے۔ "کوئی بھی احمق کوڈ لکھ سکتا ہے جسے کمپیوٹر سمجھ سکتا ہے۔ اچھے پروگرامر کوڈ لکھتے ہیں جسے انسان سمجھ سکتے ہیں۔" - مارٹن فولر تو پیچیدگی کیا ہے؟ اس کی تعریف اس مشکل کی ڈگری کے طور پر کی جا سکتی ہے جس کے ساتھ پروگرام میں ہر آپریشن کیا جاتا ہے۔ ایک اصول کے طور پر، پیچیدگی دو اقسام میں تقسیم کیا جا سکتا ہے. پہلی قسم کی پیچیدگی ایک نظام کے افعال کی تعداد ہے۔ اسے صرف ایک طریقے سے کم کیا جا سکتا ہے — کچھ فنکشن کو ہٹا کر۔ موجودہ طریقوں پر نظر رکھنے کی ضرورت ہے۔ ایک طریقہ کو ہٹا دیا جانا چاہئے اگر یہ اب استعمال نہیں کیا جاتا ہے یا اب بھی استعمال کیا جاتا ہے لیکن کوئی قدر لائے بغیر۔ مزید یہ کہ، آپ کو اس بات کا اندازہ لگانے کی ضرورت ہے کہ درخواست میں موجود تمام طریقے کیسے استعمال کیے جاتے ہیں، یہ سمجھنے کے لیے کہ سرمایہ کاری کہاں فائدہ مند ہوگی (بہت سارے کوڈ دوبارہ استعمال کریں) اور آپ کس چیز کو نہیں کہہ سکتے ہیں۔ پیچیدگی کی دوسری قسم غیر ضروری پیچیدگی ہے۔ یہ صرف ایک پیشہ ورانہ نقطہ نظر کے ذریعے علاج کیا جا سکتا ہے. کچھ "ٹھنڈا" کرنے کے بجائے (نوجوان ڈویلپرز صرف اس بیماری کا شکار نہیں ہیں)، آپ کو یہ سوچنے کی ضرورت ہے کہ اسے جتنا آسان ہو سکے کیسے کیا جائے، کیونکہ بہترین حل ہمیشہ آسان ہوتا ہے۔ مثال کے طور پر، فرض کریں کہ ہمارے پاس کچھ اداروں کی تفصیل کے ساتھ چھوٹی متعلقہ جدولیں ہیں، جیسے کہ صارف: تو، ہمارے پاس صارف کی شناخت، اس زبان کی شناخت ہے جس میں وضاحت کی گئی ہے، اور خود وضاحت۔ اسی طرح، ہمارے پاس کاروں، فائلوں، منصوبوں اور صارفین کی میزوں کے لیے معاون وضاحتی ہیں۔ پھر ایسی جدولوں میں نئی ​​قدریں ڈالنا کیسا لگے گا؟

public void createDescriptionForElement(ServiceType type, Long languageId, Long serviceId, String description)throws Exception {
   switch (type){
       case CAR:
           jdbcTemplate.update(CREATE_RELATION_WITH_CAR, languageId, serviceId, description);
       case USER:
           jdbcTemplate.update(CREATE_RELATION_WITH_USER, languageId, serviceId, description);
       case FILE:
           jdbcTemplate.update(CREATE_RELATION_WITH_FILE, languageId, serviceId, description);
       case PLAN:
           jdbcTemplate.update(CREATE_RELATION_WITH_PLAN, languageId, serviceId, description);
       case CUSTOMER:
           jdbcTemplate.update(CREATE_RELATION_WITH_CUSTOMER, languageId, serviceId, description);
       default:
           throw new Exception();
   }
}

اور اسی کے مطابق، ہمارے پاس یہ اینوم ہے:

public enum ServiceType {
   CAR(),
   USER(),
   FILE(),
   PLAN(),
   CUSTOMER()
}

سب کچھ آسان اور اچھا لگتا ہے... لیکن دوسرے طریقوں کا کیا ہوگا؟ درحقیقت، ان سب کے پاس switchبیانات کا ایک گروپ اور تقریباً ایک جیسے ڈیٹا بیس سوالات کا ایک گروپ بھی ہوگا، جو بدلے میں ہماری کلاس کو بہت پیچیدہ اور پھولے گا۔ یہ سب کیسے آسان بنایا جا سکتا ہے؟ آئیے اپنے اینوم کو تھوڑا سا اپ گریڈ کریں:

@Getter
@AllArgsConstructor
public enum ServiceType {
   CAR("cars_descriptions", "car_id"),
   USER("users_descriptions", "user_id"),
   FILE("files_descriptions", "file_id"),
   PLAN("plans_descriptions", "plan_id"),
   CUSTOMER("customers_descriptions", "customer_id");
   private String tableName;
   private String columnName;
}

اب ہر قسم کے ٹیبل کے اصل فیلڈز کے نام ہیں۔ نتیجے کے طور پر، وضاحت بنانے کا طریقہ بن جاتا ہے:

private static final String CREATE_RELATION_WITH_SERVICE = "INSERT INTO %s(language_id, %s, description) VALUES (?, ?, ?)";
public void createDescriptionForElement(ServiceType type, Long languageId, Long serviceId, String description) {
   jdbcTemplate.update(String.format(CREATE_RELATION_WITH_SERVICE, type.getTableName(), type.getColumnName()), languageId, serviceId, description);
   }

آسان، سادہ اور کمپیکٹ، کیا آپ نہیں سوچتے؟ ایک اچھے ڈویلپر کا اشارہ یہ بھی نہیں ہے کہ وہ کتنی بار پیٹرن استعمال کرتا ہے، بلکہ وہ کتنی بار اینٹی پیٹرن سے گریز کرتا ہے۔ جہالت بدترین دشمن ہے، کیونکہ آپ کو اپنے دشمنوں کو نظر سے پہچاننا چاہیے۔ ٹھیک ہے، میرے پاس آج کے لیے اتنا ہی ہے۔ آپ کا شکریہ، سب! :)