سولڊ: جاوا ۾ ڪلاس ڊيزائن جا پنج بنيادي اصول

ڪلاس ايپليڪيشنن جا بلڊنگ بلاڪ آهن. بلڊنگ ۾ سرن وانگر. خراب لکيل طبقن آخرڪار مسئلا پيدا ڪري سگھن ٿا. اهو سمجهڻ لاءِ ته ڇا ڪو ڪلاس صحيح طرح لکيو ويو آهي، توهان چيڪ ڪري سگهو ٿا ته اهو ڪيئن "معيار جي معيار" تائين پهچي ٿو. جاوا ۾، اهي نام نهاد SOLID اصول آهن، ۽ اسان انهن بابت ڳالهائڻ وارا آهيون.

جاوا ۾ SOLID اصول

SOLID ھڪڙو مخفف آھي جيڪو OOP ۽ ڪلاس ڊيزائن جي پھرين پنجن اصولن جي وڏن اکرن مان ٺاھيو ويو آھي. اصولن جو اظهار رابرٽ مارٽن پاران 2000 جي شروعات ۾ ڪيو ويو، ۽ پوء مخفف بعد ۾ مائيڪل فيدرز پاران متعارف ڪرايو ويو. هتي SOLID اصول آهن:

1. اڪيلو ذميواري اصول
2. کليل بند اصول
3. Liskov متبادل اصول
4. انٽرفيس الڳ ڪرڻ جو اصول
5. انحصار جي ڦيرڦار جو اصول

اڪيلو ذميواري اصول (SRP)

اهو اصول ٻڌائي ٿو ته ڪنهن به طبقي کي تبديل ڪرڻ لاءِ هڪ کان وڌيڪ سبب نه هجڻ گهرجن. هر اعتراض جي هڪ ذميواري آهي، جيڪا مڪمل طور تي ڪلاس ۾ شامل ڪئي وئي آهي. هڪ طبقي جي سڀني خدمتن جو مقصد هن ذميواري جي حمايت ڪرڻ آهي. جيڪڏهن ضروري هجي ته اهڙيون ڪلاسون تبديل ڪرڻ ۾ هميشه آسان ٿي وينديون، ڇاڪاڻ ته اهو واضح آهي ته ڪلاس ڇا آهي ۽ ان جو ذميوار نه آهي. ٻين لفظن ۾، اسان تبديلي ڪرڻ جي قابل ٿي وينداسين ۽ نتيجن کان نه ڊڄنداسين، يعني ٻين شين تي اثر. اضافي طور تي، اهڙي ڪوڊ کي جانچڻ تمام آسان آهي، ڇاڪاڻ ته توهان جا تجربا ڪارڪردگي جي هڪ ٽڪرا کي ڍڪي رهيا آهن ٻين سڀني کان الڳ ڪرڻ ۾. تصور ڪريو ھڪڙو ماڊل جيڪو عمل ڪري ٿو آرڊر. جيڪڏهن آرڊر صحيح طرح ٺهيل آهي، هي ماڊل ان کي ڊيٽابيس ۾ محفوظ ڪري ٿو ۽ آرڊر جي تصديق ڪرڻ لاءِ هڪ اي ميل موڪلي ٿو:

public class OrderProcessor {

    public void process(Order order){
        if (order.isValid() && save(order)) {
            sendConfirmationEmail(order);
        }
    }

    private boolean save(Order order) {
        MySqlConnection connection = new MySqlConnection("database.url");
        // Save the order in the database

        return true;
    }

    private void sendConfirmationEmail(Order order) {
        String name = order.getCustomerName();
        String email = order.getCustomerEmail();

        // Send an email to the customer
    }
}

هي ماڊل ٽن سببن جي ڪري تبديل ٿي سگهي ٿو. پهرين، پروسيسنگ آرڊر لاء منطق تبديل ٿي سگھي ٿي. ٻيو، آرڊر محفوظ ٿيل طريقي سان (ڊيٽابيس جو قسم) تبديل ٿي سگھي ٿو. ٽيون، تصديق جو طريقو تبديل ٿي سگھي ٿو (مثال طور، فرض ڪريو اسان کي اي ميل جي بجاءِ ٽيڪسٽ پيغام موڪلڻ جي ضرورت آھي). واحد ذميواري اصول جو مطلب آهي ته هن مسئلي جا ٽي پهلو اصل ۾ ٽي مختلف ذميواريون آهن. مطلب ته اهي مختلف طبقن يا ماڊلز ۾ هجن. ڪيترن ئي ادارن کي گڏ ڪرڻ جيڪي مختلف وقتن تي تبديل ٿي سگهن ٿا ۽ مختلف سببن جي ڪري هڪ غريب ڊيزائن جو فيصلو سمجهيو ويندو آهي. اهو بهتر آهي ته هڪ ماڊل کي ٽن الڳ الڳ ماڊلز ۾ ورهايو وڃي، جن مان هر هڪ هڪ فنڪشن انجام ڏئي ٿو:

public class MySQLOrderRepository {
    public boolean save(Order order) {
        MySqlConnection connection = new MySqlConnection("database.url");
        // Save the order in the database

        return true;
    }
}

public class ConfirmationEmailSender {
    public void sendConfirmationEmail(Order order) {
        String name = order.getCustomerName();
        String email = order.getCustomerEmail();

        // Send an email to the customer
    }
}

public class OrderProcessor {
    public void process(Order order){

        MySQLOrderRepository repository = new MySQLOrderRepository();
        ConfirmationEmailSender mailSender = new ConfirmationEmailSender();

        if (order.isValid() && repository.save(order)) {
            mailSender.sendConfirmationEmail(order);
        }
    }

}

کليل بند اصول (OCP)

اهو اصول هن ريت بيان ڪيو ويو آهي: سافٽ ويئر ادارن (ڪلاس، ماڊل، فنڪشن، وغيره) کي وڌائڻ لاء کليل هجڻ گهرجي، پر ترميم لاء بند ڪيو وڃي . هن جو مطلب اهو آهي ته اهو ممڪن آهي ته ڪنهن طبقي جي خارجي رويي کي تبديل ڪرڻ کان سواء ڪلاس جي موجوده ڪوڊ ۾ تبديليون. هن اصول جي مطابق، ڪلاس ڊزائين ڪيا ويا آهن ته جيئن مخصوص حالتن کي پورو ڪرڻ لاء هڪ طبقي کي ٽائيڪ ڪرڻ لاء صرف ان کي وڌائڻ ۽ ڪجهه ڪمن کي ختم ڪرڻ جي ضرورت آهي. هن جو مطلب اهو آهي ته سسٽم لچڪدار هجڻ گهرجي، ماخذ ڪوڊ کي تبديل ڪرڻ کان سواء تبديل ٿيندڙ حالتن ۾ ڪم ڪرڻ جي قابل. اسان جي مثال کي جاري رکڻ ۾ شامل آهي آرڊر پروسيسنگ، فرض ڪريو اسان کي ڪجهه عملن کي انجام ڏيڻ جي ضرورت آهي آرڊر تي عمل ٿيڻ کان اڳ ۽ انهي سان گڏ تصديق واري اي ميل موڪلڻ کان پوء. ڪلاس کي تبديل ڪرڻ بدران OrderProcessor، اسان ان کي وڌائينداسين ته جيئن کليل بند ٿيل اصول جي ڀڃڪڙي ڪرڻ کان سواءِ پنهنجو مقصد پورو ڪرڻ لاءِ:

public class OrderProcessorWithPreAndPostProcessing extends OrderProcessor {

    @Override
    public void process(Order order) {
        beforeProcessing();
        super.process(order);
        afterProcessing();
    }

    private void beforeProcessing() {
        // Take some action before processing the order
    }

    private void afterProcessing() {
        // Take some action after processing the order
    }
}

Liskov متبادل اصول (LSP)

هي کليل بند اصول جو هڪ تڪرار آهي جنهن جو اسان اڳ ذڪر ڪيو آهي. ان جي وضاحت هن ريت ڪري سگهجي ٿي: ڪنهن پروگرام جي پراپرٽيز کي تبديل ڪرڻ کان سواءِ شيون ذيلي طبقن جي شين سان تبديل ڪري سگھجن ٿيون. هن جو مطلب آهي ته هڪ بنيادي طبقي کي وڌائڻ سان ٺهيل هڪ طبقي کي ان جي طريقن کي ختم ڪرڻ گهرجي ته جيئن ڪارڪردگي کي ڪلائنٽ جي نقطي نظر کان سمجهوتو نه ڪيو وڃي. اهو آهي، جيڪڏهن هڪ ڊولپر توهان جي ڪلاس کي وڌايو ۽ ان کي ايپليڪيشن ۾ استعمال ڪري ٿو، هن کي ڪنهن به اوور رائڊ ٿيل طريقن جي متوقع رويي کي تبديل نه ڪرڻ گهرجي. ذيلي طبقن کي بنيادي طبقي جي طريقن کي ختم ڪرڻ گهرجي ته جيئن ڪارڪردگي ڪلائنٽ جي نقطي نظر کان ڀڄي نه وڃي. اسان ان کي تفصيل سان هيٺ ڏنل مثال ۾ ڳولي سگهون ٿا. فرض ڪريو اسان وٽ ھڪڙو طبقو آھي جيڪو ھڪڙي آرڊر جي تصديق ڪرڻ ۽ جانچڻ جو ذميوار آھي ته ڇا آرڊر ۾ موجود سڀئي سامان اسٽاڪ ۾ آھن. ھن طبقي ۾ ھڪڙو isValid()طريقو آھي جيڪو موٽائي ٿو صحيح يا غلط :

public class OrderStockValidator {

    public boolean isValid(Order order) {
        for (Item item : order.getItems()) {
            if (!item.isInStock()) {
                return false;
            }
        }

        return true;
    }
}

اهو پڻ فرض ڪريو ته ڪجهه آرڊرن جي تصديق ٿيڻ جي ضرورت آهي مختلف طور تي ٻين، مثال طور ڪجهه آرڊر لاءِ اسان کي اهو جانچڻ جي ضرورت آهي ته ڇا آرڊر ۾ موجود سڀئي سامان اسٽاڪ ۾ آهن ۽ ڇا سڀئي سامان ڀريل آهن. هن کي ڪرڻ لاء، اسان OrderStockValidatorڪلاس ٺاهي ڪلاس کي وڌايو OrderStockAndPackValidator:

public class OrderStockAndPackValidator extends OrderStockValidator {

    @Override
    public boolean isValid(Order order) {
        for (Item item : order.getItems()) {
            if ( !item.isInStock() || !item.isPacked() ){
                throw new IllegalStateException(
                     String.format("Order %d is not valid!", order.getId())
                );
            }
        }

        return true;
    }
}

پر هتي اسان Liskov متبادل اصول جي ڀڃڪڙي ڪئي آهي، ڇاڪاڻ ته غلط موٽڻ جي بدران جيڪڏهن آرڊر جي تصديق ۾ ناڪام ٿئي ٿي، اسان جو طريقو هڪ IllegalStateException. ڪلائنٽ هن ڪوڊ کي استعمال ڪندي هن جي توقع نه ڪندا آهن: اهي يا ته سچ يا غلط جي واپسي جي قيمت جي توقع ڪن ٿا . اهو رن ٽائيم غلطين جي ڪري سگھي ٿو.

انٽرفيس سيگريگيشن پرنسپل (ISP)

اهو اصول هيٺ ڏنل بيان سان منسوب ڪيو ويو آهي: ڪلائنٽ کي مجبور نه ڪيو وڃي ته انهن طريقن کي لاڳو ڪرڻ لاء جيڪي اهي استعمال نه ڪندا . انٽرفيس سيگريگيشن اصول جو مطلب آهي ته انٽرفيس جيڪي ڏاڍا ”ٿلها“ هوندا آهن انهن کي ننڍڙن، وڌيڪ مخصوص وارن ۾ ورهايو وڃي، ته جيئن ننڍڙا انٽرفيس استعمال ڪندڙ ڪلائنٽ صرف انهن طريقن جي باري ۾ ڄاڻن جيڪي انهن جي ڪم لاءِ گهربل آهن. نتيجي طور، جڏهن هڪ انٽرفيس جو طريقو تبديل ٿئي ٿو، ڪنهن به گراهڪ جيڪي اهو طريقو استعمال نٿا ڪن انهن کي تبديل نه ڪرڻ گهرجي. هن مثال تي غور ڪريو: ايڪس، هڪ ڊولپر، هڪ "رپورٽ" انٽرفيس ٺاهيو آهي ۽ ٻه طريقا شامل ڪيا آهن: generateExcel()۽ generatedPdf(). هاڻي هڪ گراهڪ هن انٽرفيس کي استعمال ڪرڻ چاهي ٿو، پر صرف پي ڊي ايف فارميٽ ۾ رپورٽون استعمال ڪرڻ جو ارادو رکي ٿو، نه ايڪسل ۾. ڇا هي ڪارڪردگي هن ڪلائنٽ کي مطمئن ڪندو؟ نه. ڪلائنٽ کي ٻه طريقا لاڳو ڪرڻا پوندا، جن مان هڪ ته گهڻو ڪري گهربل نه آهي ۽ موجود آهي صرف Alex جي مهرباني، جنهن سافٽ ويئر ڊزائين ڪيو. ڪلائنٽ يا ته هڪ مختلف انٽرفيس استعمال ڪندو يا ايڪسل رپورٽن جي طريقي سان ڪجھ به نه ڪندو. پوء حل ڇا آهي؟ اهو موجوده انٽرفيس کي ٻن ننڍن ۾ ورهائڻ آهي. ھڪڙو PDF رپورٽن لاءِ، ٻيو Excel رپورٽن لاءِ. هي اجازت ڏئي ٿو گراهڪن کي صرف ڪارڪردگي استعمال ڪرڻ جي ضرورت آهي.

انحصار جي ڦيرڦار جو اصول (DIP)

جاوا ۾، هي SOLID اصول هن ريت بيان ڪيو ويو آهي: سسٽم جي اندر انحصار خلاصن جي بنياد تي ٺهيل آهن . اعلي سطحي ماڊلز هيٺين سطح جي ماڊلز تي منحصر نه آهن. خلاصو تفصيل تي منحصر نه هجڻ گهرجي. تفصيلات تي دارومدار رکڻ گهرجي. سافٽ ويئر کي ڊزائين ڪرڻ جي ضرورت آهي ته جيئن مختلف ماڊلز پاڻ ۾ شامل آهن ۽ تجزيه ذريعي هڪ ٻئي سان ڳنڍيل آهن. هن اصول جي هڪ کلاسک درخواست بهار فريم ورڪ آهي. بهار جي فريم ورڪ ۾، سڀئي ماڊلز الڳ الڳ اجزاء طور لاڳو ڪيا ويا آهن جيڪي گڏجي ڪم ڪري سگهن ٿيون. اهي ايترو خودمختيار آهن ته اهي بهار جي فريم ورڪ کان سواءِ پروگرام ماڊلز ۾ آساني سان استعمال ڪري سگھجن ٿيون. اهو حاصل ڪيو ويو آهي بند ۽ کليل اصولن جي انحصار جي مهرباني. سڀئي ماڊلز صرف خلاصي تائين رسائي فراهم ڪن ٿا، جيڪو ٻئي ماڊل ۾ استعمال ڪري سگهجي ٿو. اچو ته هڪ مثال استعمال ڪندي ان کي واضح ڪرڻ جي ڪوشش ڪريون. واحد ذميواري اصول جي ڳالهائيندي، اسان OrderProcessorطبقي کي سمجهيو. اچو ته هن ڪلاس جي ڪوڊ تي هڪ ٻيو نظر وجهون:

public class OrderProcessor {
    public void process(Order order){

        MySQLOrderRepository repository = new MySQLOrderRepository();
        ConfirmationEmailSender mailSender = new ConfirmationEmailSender();

        if (order.isValid() && repository.save(order)) {
            mailSender.sendConfirmationEmail(order);
        }
    }

}

هن مثال ۾، اسان جو OrderProcessorطبقو ٻن مخصوص طبقن تي منحصر آهي: MySQLOrderRepository۽ ConfirmationEmailSender. اسان انهن ڪلاسن جو ڪوڊ پڻ پيش ڪنداسين:

public class MySQLOrderRepository {
    public boolean save(Order order) {
        MySqlConnection connection = new MySqlConnection("database.url");
        // Save the order in the database

        return true;
    }
}

public class ConfirmationEmailSender {
    public void sendConfirmationEmail(Order order) {
        String name = order.getCustomerName();
        String email = order.getCustomerEmail();

        // Send an email to the customer
    }
}

اهي طبقا ان کان پري آهن جن کي اسان خلاصيون سڏينداسين. ۽ انحصار جي ڦيرڦار جي اصول جي نقطي نظر کان، اهو بهتر ٿيندو ته ڪجهه تجريد ٺاهڻ سان شروع ڪيو وڃي جيڪي اسان مستقبل ۾ ڪم ڪري سگهون ٿا، بلڪه مخصوص عملن جي بجاءِ. اچو ته ٻه انٽرفيس ٺاهيون: MailSender۽ OrderRepository). اهي اسان جا خلاصا هوندا:

public interface MailSender {
    void sendConfirmationEmail(Order order);
}

public interface OrderRepository {
    boolean save(Order order);
}

هاڻي اسان انهن انٽرفيس کي ڪلاسن ۾ لاڳو ڪريون ٿا جيڪي اڳ ۾ ئي هن لاءِ تيار ڪيون ويون آهن:

public class ConfirmationEmailSender implements MailSender {

    @Override
    public void sendConfirmationEmail(Order order) {
        String name = order.getCustomerName();
        String email = order.getCustomerEmail();

        // Send an email to the customer
    }

}

public class MySQLOrderRepository implements OrderRepository {

    @Override
    public boolean save(Order order) {
        MySqlConnection connection = new MySqlConnection("database.url");
        // Save the order in the database

        return true;
    }
}

اسان تياري وارو ڪم ان ڪري ڪيو ته جيئن اسان جي OrderProcessorطبقي جو دارومدار ڪنڪريٽ تفصيلن تي نه، پر تجريد تي هجي. اسان ان کي تبديل ڪنداسين اسان جي انحصار کي شامل ڪندي ڪلاس تعمير ڪندڙ:

public class OrderProcessor {

    private MailSender mailSender;
    private OrderRepository repository;

    public OrderProcessor(MailSender mailSender, OrderRepository repository) {
        this.mailSender = mailSender;
        this.repository = repository;
    }

    public void process(Order order){
        if (order.isValid() && repository.save(order)) {
            mailSender.sendConfirmationEmail(order);
        }
    }
}

هاڻي اسان جو طبقو خلاصن تي منحصر آهي، نه مخصوص عملن تي. اسان آساني سان ان جي رويي کي تبديل ڪري سگھون ٿا مطلوب انحصار شامل ڪندي وقت تي هڪ OrderProcessorاعتراض پيدا ڪيو ويو آهي. اسان جاوا ۾ SOLID ڊيزائن جي اصولن کي جانچيو آهي. توھان وڌيڪ سکندا OOP بابت عام طور تي ۽ جاوا پروگرامنگ جي بنياديات - ڪجھ به بورنگ نه آھي ۽ سوين ڪلاڪن جي مشق - ڪوڊ گيم ڪورس ۾. ڪجھ ڪمن کي حل ڪرڻ جو وقت :)