System Design Full Course - SOLID Design Principles | Complete Guide with Code Examples

حان جی, so آج ہم start ھر نے جا رہے ہیں اپنی LLD کے play list کے ایک بلکل new lecture کو جس کا نام ہے solid design principles اب یہ principles کیا ہوتے ہیں کیسے اپلای کرتے ہیں اس سے پہلے ہم ایک ایک اوڑا سا overview لے لے کہ ابھی تک ہم نے کیا کر لیا ہے تو ابھی تکنا ہم نے ooops ke pillars کو دیکھلیا ہم نے دیکھا abstraction in encapsulation in heritance polymorphism یہ سب کیا ہوتے ہیں ہم نے دیکھلیا ہم classes کیسے کریٹ کرتے ہیں objects کیسے کریٹ کرتے ہیں اُن class is me ہم data hide کیسے کرتے ہیں data security کیسے maintain ڈین کرتے ہیں Wright پڑ جب آپے کی Real World Project کی بات کرتے ہیں تو اس میں 1000 ڈ of classes بن دیا اب آپ imagine کرو اتنی ساری classes کو manage کرنا کتنا مشکل ہوتا ہوں گا تو ایسے کون سے principle سے ہیں کون سے rule ہے جو ہم اگر follow کریں تو ہم اتنی ساری classes کو بھی 1 ڈ ایک ساتh manage کر پائیں گے کیا اگر وہاں ہم نے گندہ کود لکھا وہاں ہم نے mess کر دیا ان class is کے ساتh تو ہماری ساتh کیا آپ کو بات ہے بہت دیسا Straz bugs introduce جائیں گے ایک Real World application جب bugs introduce ہوتے ہیں تو صرف ٹیکنی لیوڈ پے اس کا نکسان نہیں ہوتا Monetary level پی بھی اس کا نکسان ہوتے تو ہم اس طرح کود لکھنا ہوتے جو کلینا رہو دوسرے کو ایزیلی سمجھا جاہ اور ایک ارکی ٹیکٹر کو منٹین کرکے تو یہی آجہم اس پورے کے پوری لیکچر میں بڑھنے والے اس کو سمجھنے والے چلو پہلے ایک Real World پروبلم کی بات کرتے ہیں اور پھر اس کو کود کے تریگے سمجھیں گے سپوست کروے گھر ہے جس میں بہت ساری وائرینگ جاری ہے ایک جگہ سے ٹیک گیا ہے اب اس میں ایلیکٹرکل وائرینگ ایلیکٹرکی وائرینگ سو سکتے ہیں اور اس میں لیکسے پائپس بھی ہو سکتے ہیں اور وہ سب ایکی ترفس سے ایکی جگہ سے جارے اور بلکلک مصببنگے ایک آپ سپوست کرو اس میں سے کسی بھی وائرینگر کچھ فولٹ آتا ہے تو یہ پتا لگانا کی فولٹ کی سوائرینگے ہوا ہے اس اس پرپر وائرینگے ریپلے سکرنا کی طرح کی طرح کی طرح کی طرح کی طرح آپ کو very much چل تو سپسے پہلے ہم بات کرتے پروبلامس کی کی کیا کیا کیا پروبلامس ہوتی ہے ایک ریالوالد پروجیکٹ میں اگر ام دیدین پرنسپس کو فولوں نہیں کرتے ہیں بейسکلے اگر فولوں بھی کرتے ہیں اگر ام سہی سے فولوں نہیں کرتے تو دیکھو سپسے پہلے نہ منتین ایلیکٹی کا Işو ہوتے ہیں بейسکلے کیا مطلب ہے کہ آپ کو اپنا کوڑ منتین کرنا چیے بیسکلے آپ کی اپلکیشن منتینے بلو اس کا کیا اگر آپ کی اپلکیشن میں ہم کوئی نیا فیچر انٹگریٹ کریں تو ایزیل انٹگریٹ ہو جہا زادا کورد چینجز نہ کرنے پڑے اگر اس میں نیا بغس نہ انٹروڑیوز جہا سیچر کو انٹگریٹ کرنے کرنے کے لئے تو یہ منتین ایلیکٹی کے پروبلاماتی ہے سیکن پروبلام جو آتی ہے وہ آتی ہے اس کے ریدیڈی بلیٹی کے تو اس کی کیا پروبلام ہے دیکھو یہ وہ بتا هاتھ ہے کہ לט سے آپ کی اپلکیشن میں کچھ نیں اینجینیٹز جودے ہے جو اس میں قورد کرنا چاہتے ہیں اب آپ کی اپلکیشن تھی مرکہ تک نیقریتے ایتنی تائدلی قبل لکیوئے نا کہ کسی بنے اینجینیٹز کو وہ قورد to anngi میں بہت مہنت لگے گی وہ اس کا ریدی بلیٹی انڈیکز بہت ہی وہ اس کو understood ڈے لیے ہی بہت time veist کرنا پڑے گا so یہ проблемا تی a readability تو ہم نے دیکھا منتینی بلیٹے ایک проблем ہو سکتی a readability ایک проблем ہو سکتی ہے اور ایک اپلیگیشن میں جہت سب سے زادا کامن проблем سے وہ ہے کہ ہم بہت سارے بغس انٹڈیوز کر دے دے ہیں اور ان بغس کو ریزالف کر لے ہمیں بہت زادا time debugging میں لگا نہ پڑھتے ہیں تو یہ کچھ پروبلم سے جو ایک اپلیگیشن میں ہم فیس کرتے ہیں اپنے پروبلمز کو ہی سالف کرنے کے لئے کسی محان انسان نے کچھ ایسے پرنسپلز بنائے کچھ ایسے دیزائین پرنسپلز بنائے کہ اگر آپ ان کو ایک ایک کر کے فالو کرلو اپنے کوڈ میں تو یہ پروبلم کا بھی آئے گی نہیں آپ کا کوڈ ایک دم کلینا رہے ہوگا آپ کا ارکی ٹیکٹر ایک دمینے جب لوگا تو سب سے پہلے آپ کو ایجانے کے ذورت نہیں ہے کہ وہ محان انسان کونے but credit دینا چیے لوگوں ہزار میں انہوں نے یہ کمبیڈر سائنتیس تھے انہوں نے پیپر پبلش کیا دہ جن میں انہوں نے اس دیزائین پرنسپلز کی بات کی دی تھی کہ تو وہ دیزائین پرنسپلز کیا ہے پہلے ہم اس کو سامجھ لے تھے اور ایک ایک کر کے سارے پر اپنسپلز کو کریں گے اور اسے پر ایک دمینے کے ساتھ سامجیں گے آپ کو ساری چیزے ایک دم کرستلیار ہو جائے گی اس لیکچر کے بعد اور یہ ایک دم اندفت رہے گا چلو start کرتے ہیں دیکھوں سپ سے پہلے تو ہمیں دیزائین پرنسپل کو کا جو ایک رونی میں وہ ہے سالید دیکھیں اس لہمیں نے سالید دیزائین پرنسپل بھولتے ہیں یہ ایک رونی میں کیا مطلب ہے سالید گا دیکھوں ایک کر کے سامجھتے ہیں سپ سے پہلے یہ جو اس ہے اس کا مطلب ہوتا ہے سنگل رسپونسی بلیٹی پرنسپل اس کو ہم SRP بھولتے ہیں اس کے لابا جو مرپس O, L, I اور D ان سب کو ایک بر انٹڈوڑیس کر لے دیکھیں فتافٹ سے O کا مطلب ہوتا ہے ہمارا OPENCLOS پرنسپل اس کو ہم OSP بھولتے ہیں OCP اگلہ ہمارا ہوتا ہے LISCOV SUBSTITUTION TRINCEPTEL اس کو ہم بولتے ہیں LSP اگلہ ہمارا ہوتا ہے INTERFACE SEGREATION TRINCEPTEL اس کو ہم بولتے ہیں I, S, P اور DAST ہمارا ہوتا ہے DEFENDENCY IN VERSION TRINCEPTEL DEFENDENCY IN VERSION PRINCEPTEL اور اس کو ہم بولتے ہیں DEF DIP DIP تو یہ پاچھ принципلس ہیں جو ملا کر کے SOLIDESIGN PRINCEPTEL کہلا تھی یہ принципلس فولو کرنے کے بعد جس کہ ہم نے ابھی اپنے بات کی کہ آپ کو کوئی پروبلم نہیں آئے گئی اپنے کوڑ علیکنے میں آپ کا کوڑ علیکنے کلینا رہے گا تو اگئے کر کے IN DESIGN PRINCEPTEL کے مابت کرتے اور انہیں سمچھتے ہیں چاہلو تو سپ سے پہلے آجاتے ہیں S' جو کی کیا تھا S' RESPONSIBILITY PRINCEPTEL ٹھیک ہے تو S' RESPONSIBILITY اس کی بات کر لےتے ہیں تو پہلے میں اس کی DEFINATION نوں گا اور فیر ہم سمجھیں کی ہوتا کیا کہا ہے تو یہ ہے سکی DEFINATION S' RESPONSIBILITY PRINCEPTEL کہتا ہے اکلاص SHOULD HAVE ONLY ONE RESON ONLY ONE RESON یا فر اٹھ شڈوڑاولی WAN DING کیا مطلب ہے اس کا تکو SIMPALS اگر شبھ دوں میں سمجھیں تو ایک CLASS ٹھیک ہے وہ اس طرح لکی ہونی چاہئے کہ وہ صرف ایک ایک ایک ایک CLASS کی ایک RESPONSIBILITY ہونی چاہئے یعنی کی اس CLASS کو چینج کرنے گیلی ایک ہی RESON ہونی چاہئے ہمارے پاس لبس کا کہنے گا ہم بس اتنا کہنہ چاہتے ہیں کہ ایک CLASS ملٹیپل RESPONSIBILITY ہندل نہ کریں وہ ایک ایک CLASS ایک SIMPAL اس کا اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگر اگред تو یہ تو basic and single responsibility principle which is called as basic and single responsibility principle Now, let us take a look at the example of this that we can follow and why we should follow this Okay Let's go So, we have studied the UML Diagrams Now, what do we do? Through the UML Diagrams we will make class diagrams and we will understand the example and then we will see the code after that So, first of all, imagine that you have a product class Okay Which product is this? Any of the e-commerce websites that you get will get You can get it from Amazon, Flipkart, Mintra, etc The e-commerce website has a product that is the same product class And there are two things from the product Product's price and product's name Simple And nothing else Obviously, we are doing the entire UML journey We are doing the excess modifier plus minus hash and it is the return time But now, you understand what we are going to say So, we have made a product class which is a product that has its own name and its price Okay Now, we are working We make a shopping cart Now, every product is a cart-made user Okay So, we should make a cart So, we make a shopping cart with a class So, these are the shopping cart classes which are basically the UML diagram that we represent Now, what is the relationship between cart and product? I am saying that the shopping cart is a relationship of the hash Right?

I have made a mistake As we discussed in the last lecture We should have opened the product So, the hash is a relationship Basically, the shopping cart has a product And not only the hash product But the shopping cart has many products You can use a multiple product in a cart And what we write to show in the UML diagram We write this as 1.dot star This means that in this shopping cart We can keep the multiple products inside the shopping cart Okay? Just remember this Let's just jump back What we were saying That we have a product class which has a price and name And we have a shopping cart class which has a list of many products Okay? So, we keep the list of those products in our own place Now, what we do is What are the methods of this shopping cart that we write? So, let's say, a shopping cart method will calculate total price Okay?

So, what will we do? Basically, we will list all the products All the prices will be summed up And we will calculate total price Okay? What else can we do? Let's say, we print the invoice So, the items of all the cart will print the invoice of the total bill So, we keep the name Print invoice function So, this invoice is also print Let's imagine that in the shopping cart There is another method which is saved to db So, the items you have in the cart They also store them in the database Okay?

So, we save to db and make a method This is also in the shopping cart Okay? So, if you look carefully So, the class of the shopping cart is breaking the single responsibility principle Because we said the single responsibility principle should have only one responsibility But look, all the responsibilities are taken together This is also calculating the total price This is also printing the invoice and also processing it in db So, this is handling multiple responsibilities together So, what is the problem with this? This will be the problem that if we have to change the logic of store in the database then we have to change it in this class If we have to change the invoice printing logic then we have to change it in this class And again, same if we have to calculate the total price then we have to change it in this class So, there are multiple reasons that we have to change it in this class This is called when srp or single responsibility principle is breaking Okay? Now, we don't want to break We want to follow it Okay?

Because we want to follow all the principles and we want to follow it So, how can we follow it? So, to follow it we will use the composition very much So, the composition we read in the last lecture we will use the composition very much So, let's look at one by one and see how we can follow it Okay? So, now we are looking at what we were looking at we were looking at that that shopping cart is being handled with multiple things in one class So, let's do one thing let's break it down in multiple classes Okay? Now, we will do one thing We have one shopping cart let's put it in the middle let's put it here we don't have a shopping cart okay?

And we will make multiple functions So, we have a product first of all, we will make multiple classes first of all, we have a class called shopping cart which was also the first one Okay? We have also taken it We have also taken it We have taken many functions we have taken many functions What function was in the shopping cart in the database it was storing it in the database it was printing the invoice and it was calculating the total price I am saying in these three things I think that shopping cart should be one function which is to calculate the total price so, calculate sorry calculate total price This will be in this shopping cart Apart from this, shopping cart should not be the invoice printing logic nor the database the persistence logic for this we will make two different classes so, let's make one class here Okay? In this class, let's say shopping cart invoice printer is a very big name but obviously, a big name is better because the name is always discrepancy or confusing so, we have made a cart invoice printer and we have made another class made a cart and we have made another class made a cart cart DB storage you can also name it but we have made a class for database storage okay? So, now, what do we do in these classes?

We do that method which we had taken from here so, we should print invoice method and we should do DB storage in database, store things so, save to DB Now, what will we do on this? These two classes will work on shopping cart that is, these two classes should have a reference of shopping cart so, they have a relationship with shopping cart and the one-to-many relationship is with the same product they have a one-to-one relationship so, one invoice printer is a reference of shopping cart same with DB storage is a reference of shopping cart so, how do we denote this? Basically, if you look at the history of this you can write here here, that we have made a reference from here, we can write here here, we can store a reference of shopping cart okay? So, what we have done now we have done a shopping cart in multiple classes now, look at the history of this single responsibility principle because the shopping cart is handling a single responsibility to write the total price same invoice printer and DB storage in database now, no class multiple responsibilities are handled and the structure of the entire structure is increased Now, think about the history of this class same, but, sorry, the invoice printing logic is changed only in this class so, we have separated all the things and followed single responsibility principle the same thing we have done in this class you can see the code in the UML diagram you can understand better so, let's see the code on the screen, single responsibility principle the same code we have seen we have made a product class with name and price and we have made its constructor now, look what we have done we have made a product class in a shopping cart we have made a vector in a list of products now, we have made the method of this shopping cart so, now, we are looking at the single responsibility principle so, first of all, I have made a getter setter which is a product added in this vector and the first getter which is a product will get so, we always need to keep this practice after that, we have discussed a total price we have made a method which we do through the loop and we do the price which we have every product has its price the second function is print invoice print invoice print invoice print how to print it?

just write the total which is the final value and the last function is save to database which is a bit of a story it depends on the database how to connect it and all that we are not handling it all we are simply printing if you look carefully all the things we have discussed we are doing the sRP and if you look carefully what we have done in the main function we have made a shopping cart we have created a laptop 50% of the amount print invoice save to database when we call it but, the single responsibility will be our break first, the invoice is print and the shopping cart is stored in database it is very big now we see the code when we followed the single responsibility principle we followed the single responsibility principle and this is the sRP we followed the code which we followed we will see it once we have created a product class we have created the shopping cart and we have created all the functions we have created the function and we have created thegeters and then we have created all the classes which are called as Shopping cart and we have created a shopping cart and this is the work of the printer to print the invoice we have taken a reference and the object of the cart and as we discussed this is the function and the print invoice is not the same we have also taken a reference and we have created a method and we have created a method which is not the same we have created two different classes and the main function is the same and this is the fact that all the classes are different and all the responsibilities this is the code we have already discussed the first thing which is very confusing in sRP when we say there should be a responsibility principle and a class and we have to handle one class like this example we have to handle one class but this is not the case the single responsibility principle is a single method which means that all the methods are the only functions like we have taken a total price in the shopping cart so we are calculating the total price now we are calculating the total price and we need to calculate the other methods using some helper function and we are calculating the total price but we need to do one thing for the same database we have just saved to db but we need multiple functions but we will do one thing which is the database storage this is the entire single responsibility principle I hope you will be clear let's jump on the solid design principle which is the name of the name Open Close Principle so those stands for Open Close Principle let's start so let's look at the definition this is the definition of open closed principle a class should be open for extension but close for modification what does it mean? it means to change the code basically in the old class whatever is written in the method and the extension means to add a new feature so open closed principle says that for adding a new feature we should not change the code of the old classes we should not touch the code so you will have to change the concept in old code but this open closed principle tells you that for creating a new feature you should not write a new method in the old class basically write a new method in the class of the new method it is a very strict rule I think it is a very concrete level you can follow the idealistic level every place you have to try to follow open closed principle which is better we will talk about it in the class but first we will talk about the principles so open closed principle is that a class should be open for extension and close for modification now how can this happen? if we want to integrate a new feature and we are saying that we should not change the code so how will this be possible so first we will see the problem then we will see how this will be possible so let's go to the old example okay in this example first we have a product this product this product with this we have a name and price and then we have a card which has a single method which is calculate price total price okay we have two classes one was a persistent in DB and one was to print a invoice so let's say the same in the same class as the printer the same in the same printer the same in the same printer print invoice and as we have a persistent class or a DB storage class you can say DB storage what was the reason for this? save to DB and in between we have a card has one to many so in between we have dropped the picture so let's see what is the open closed principle and how we can follow the rules let's say I want to integrate the feature in this code and we are storing data in this code and in between the same data and in a file we have to store the same data so how can I do it?

I will say it is very simple DB storage class I can write two methods I will say it is a method I will do save to Mongo and save to file and in this I will write in the code and in the file I have created open closed principle because I have created a new feature to integrate I have changed the code to change the code to create open closed principle and in this case I will integrate the new feature and in this case we have abstractions inheritance and polymorphism so if you read the three of the three of the three we will get these three and use open closed principle very easily let's see let's get it now now we have to follow open closed principle basically what we have to do we have this class database storage this is not a single new feature we have to integrate we do a work we have this db storage class this is a hard class basically a concrete class directly the method can be called first of all we create an abstract class and the other features they create concrete classes let me tell you first we do a persistence or a persistence spelling mistake if we first do a class by doing a persistence and this is our interface or abstract class which we denote if you remember the uml diagram let's take a overview you know this is called interface basically nothing a contract an application in class let's understand this is very important let's suppose there is a client who is a client? there is no software user and this is our class this is a concrete class it defines all the methods between we create an interface between basically we create an interface we create an contract which tells the client what this class does or tells how it does if you remember we used to do an abstraction we used to do an abstraction in C++ because C++ is available but when you talk about Java we used to do an interface through you in C++ we used to do an abstract class what we do in the interface or abstract class we create all the methods we define them let's tell you the interface that will inherit can be done without knowing how it will work between a client you understood why we create an abstract class when we use polymorphism if we create an abstract class and A-Lit and a concrete class A1, A2, A3 which will inherit if the abstract class will function M1, M1, M1, M1 and M1 and M1 and all these will be defined because all these will be defined and all these will be defined and all these will be defined when we create an object we create an object let's say A equal to new we can store it in C++ A1, A2, A3, A2 and all these will be defined again we define the parent class the reference of the parent class we define the method once we did this if we did A1 then M1 a1 and if we did A2 then this method اور سیمگر 8ری کیا ہوگa تو امر Method 8ری کیا ہوگa یہ ایک تھوڑا تھا Overview تھا شیدہ پھی لوگ سمچھتے ہیںگے اسی کو پورا گا پورا اینہریٹنس اور پولی مورفیزہ ملا کے ایوز کرتے ہیں اسی کو ہم Interfaces بھولتے ہیں اور Method Overriding ایوز کرتے ہیں بسیگلی Interfaces بہت زاہتے ہیں Method Overriding ایوز کرتے ہیں لیکن یہ سارا کا سارا آپ کو فیچھے پروائیڈ کرساکے ہیں چکے ہیں تو چلو واپس چلتے ہیں اپنے پروبلم کی طرف ہم نے کیا کہا تھا ہم نے یہی کہا تھا کیا ہم نے کام کرتے ہیں ہم یہ جو دیوی پرسیستنس کی class تھی اسے ایک اپسٹرٹ class بنا لیتے ہیں کیا ہم ارہا کیا چل رہا تھا یہ جو ہم نے class بنائیتے ہیں یہ ایک Concrete class تھی کیا یہ سارے کے سارے Method کو دیکھلیر کرتی ہے اور ہم یہ تو بہل غلتتے ہیں کیا ہم سارے کے سارے Method اس میں دفعینگر دیکھیں کیا کہ Open Close Principle کو بریک کر رہا تھا تو ہم نے ایک اپسٹرٹ class بنا لیتے ہیں DB پرسیستنس اور ہم نے کیا کیا جتنی بھی ہمارے پرسیست کرنے کے طریقے ہیں جو ہمارے فیچر سیپ ایک ہے سیپ تو سیکوال DB جو پہلے سے بنا ہوا تھا Right اب یہ ہم نے ایک الق class بنا لیتے ہیں ایسے ہی ایک ہمارے پاس اب آگیا نیا فیچر سیپ تو Mongo DB لیتے ہیں تو اس کی ہم نے ایک الق class بنا لیتے ہیں ایسے ہی ہمارے پاس آگیا سیپ تو فائل اور اس کی ہم نے سیمس دبارہ سے ایک الق class بنا لیتے ہیں اور ہم نے کہا یہ جو تینوں class یہ اسے انہیرٹ کرتی ہیں تو یہ انہیرٹنز ہوگیا دیکھا ایرو بناتے انہیرٹنز کے لئے تو یہ تینوں class انہیرٹ کرتی ہیں مطلب تینوں کی تینوں پرسستنز لوگک کو انہیرٹ کرتی ہیں تو اگر پرسستنز DB پرسستنز میں ایک فنگشن ہے سیپ جو کی سف دکلیر ہے تو ان تینوں میں بھی ایک فنگشن ہوگا سیپ جسے یہ دفائن کریں گے اس میں بھی فنگشن ہوگا سیپ جسے یہ دفائن کریں گے اور وہی جسے بھی ہم نے نیچہ بات کی تھی سیپ تو database لب کے سف الغوگہ پر سیپ ایکی مستے سیپ تو یہ مستے چیس کردکتے ہیں اب یہ مستے کچھ ان لگ کارٹ کارٹ تو یہ یہ کارٹ اور کارٹ کارٹ کارٹ بھی اس کے پرسستنز کیاці ہے کہ یہ ہم نے دی بھی стوڑش کے پاسے کہ ہیزا ریلیششپ تھا کیاці ہے تو ہم نے یہ بنا لیا یعنی کی اب سب کچھ باکی چیسے مرای بس ہم نے کیا کیا ہم نے انٹڈیوز کر دیا ایک نئے اپسٹیکشنز کو which is db persistence اب جو کارٹ ہے وہ db persistence سے بات کرتے ہیں یعنی کی sorry ڈولٹا ہم چیے db persistence جو ہے وہ جو کارٹ کے méthad کو call کرتے ہیں وہ اس کو انٹڈیوڈ کرنے کے اب الق الق القت دی کے ہے اس کو méthad override کرنے کے اب الق القت دی کے ہے اب اگر آپ کو data wismestor کرنا ہمارپا سالقلاص ہے اگر آپ کو mongodi mestor کر nalak class اور file mestor کرنا تو Allah class ہے تو یہاں پہم نے open-close principle کو solve کر دیا اگر کیا سے اب جب بھی ایک نیا فیچر آیا جسے mongodi بھی کہایا ہم نے کلکلاص بنیں اس کلکلاص کو چھیڈائی نہیں نہیں اس کلکلاص کو چھیڈائی جو پہلے سے بنیوی دی صرف تو file کا ہے ہم نے کلکلاص بنیں پورانی پورانی کلاص اس کو کسی کو بھی ہم نے نہیں چھیڈائی اب لیٹ سے کلکو ایک نیا persistence آجاتے گی ہمیں mongodi mestor کل میں تو کری رہے ہیں ایک کسانڈر دی بھی ہے اس میں بھی ہمیں store کرنا ہے اگر آپ کے لیڈی گیا تو ہم دوبارا بہی کریں گے جو بھی تک ہم کرتے آرے تھے اب تو بہتی دی ہے ہم کیا کریں گے ایک نئی کلاص بنیں گے اور اس اسے انہریٹ کروالیں گے اس پیرینٹ کلاص سے اور سارا کا سارا safe کا cored یا لکھ دیں گے تو پورانی کلکوں میں چھیڈائی نہیں پڑھ رہا کیوں کیوں کی بس ہم نے ایک لیول میں abstraction introduce کر دیا اور اب ایس abstraction میں ایکی method ہے safe اب جب بھی آپ کارٹ جب بھی اس کو بیسکل ہم جب بھی safe اب ایک کرنے تو جو بھی ہم نے new operator پیسلیک کیا ہوگا جب بھی ہم نے اس کو بجیک بن آیا ہوگا DB percistence کا یہ تو اپسٹٹ کلاص اس کا تو بجیک بن نہیں سکتا تو اپسی بن آوی DB percistence Let's say got a name DB equal to new تو اس new کیا گیا اب جو بھی لکھ ہوگے safe to sequel DB لکھ ہوگے safe to mongo DB safe to file جو بھی safe to خزانٹر ہندرہ ایک ہوگے depending upon that اس کا safe function تو یہی تھا open close principle جس کو ہم نے follow ڈا چلو اب چلتے code کی طرف تو یہ رہ code اپسی screen دیکھتے سپ سے پیل تو ہم نے دیکھو بھی product class بن آیا جو پیلے بن آیا تھا اس کے بات اس کا name تھا Price تھا اور اس کا constructor پھر ہمارے پاہتے Shopping Cart class تھی جس میں ہمارے Multiple products اور اس میں get reset ad product اور get products اور اس میں a key function رہی تھا Shopping Cart printer just printing invoice کے لئے رسپونسی بلتے اس کے پاس Shopping Cart کے رہی اور وہ print کرتے invoice کو اس کے لئے Shopping Cart storage class اور وہ database چیزوں کو store کرتے اب جس میں نے کہاں میں نے 2 new feature کو integrate تو same class میں safe سے a key mongo and safe سے بہتے مرحبن close principle کو break کرتے و دیکھانے کہ اب دیکھتے اب نکہ و دیکھ ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک ایک crewsettth us を strand apprent fro OK, sorry, we will put it here, OK, so we will override it here, save, save and save. And we have a logic for three. So, SQL Persistence saves, SQL Database in Mongo, Mongo, Mongo, and File, File in File.

So, this is our code, the whole Open Close Principle, we follow. So, if we see the main class, then we are exactly the same. We have created a card, we have created two items, we have printed the printer, then we have created three different variables, references, and the Persistence. In a database, we have created a file for a file for a file for a SQL and in three different functions.

Now, see, we have created a save function called, but in three different functions, we will work on the same function. So, first we have to print the invoice, then we have to see the saving, the SQL, the shopping, the Mongo, the shopping, the file, the function is the same, but the print is different because it is the method overriding. So, this is the Open Close Principle. Now, we discuss the next principle, which is called the Liscov Substitution Principle.

Let's go to the screen. So, now, we jump into the next design principle, which is the Liscov Substitution Principle. Okay? Now, let's see what this says.

So, L stands for Liscov Substitution Principle. Here, who is Liscov? Liscov is the one that has given this principle. Okay?

So, let's look at the definition of the FUTAFATS. So, this is its definition. Subclasses should be substitutable for their base classes. What does this mean?

Look, I will explain this line now. So, you will find that it is already in the form of inheritance. And this is a very basic property. But you will not know that it is a very basic property, but still, the most important thing is that when we make a real-life project, we do not know what to do with it, because we do not know the rules of all this.

Now, what is the reason for this? How does it not know? You will understand it once. Let's understand it.

So, I said that Subclasses should be substitutable for their base classes. What does this mean? Let's suppose that you have a class A. And a class B.

So, this B class inherits a class from this class. So, our A class is our base class. And our B is our subclass. Right?

Or, say, a child class from parent class. Now, the list of substitution principle is that, there is no such client. There is no such client. Which is being expected in any method.

That is, there is a method called, where you have to pass the A-base class reference and if I pass the B-base class reference, then there is no problem. So, everything should be done as it is. What does this mean? What does this mean?

That there is no subclass. It is substitutable for base class. So, wherever I can put the base class I can put my child class there. So, this was also called inheritance.

It was called inheritance. That we have a base class and a subclass. So, the subclass that we have is always spend our base class' features and never be narrowed. Right?

So, we have a base class that we have the A-base class. There are some methods on the Letsus method. M1, M2 and M3. So, I was saying that this is the B-base.

The same method will be done by M1, M2 and M3. Because it is inherited. But, M2, M3 and M3 are also different methods. Let's say, M4 and M5.

This is its specialized method. So, what did it do? It expanded A. That is, what did B basically do?

It extended A's functionalities. Right? It did not contract KBB. It did not narrow down KBB.

So, this is the list of substitution positions. It should be the same. Wherever we send the parent class object if we send the child there, then there is no point. Why?

We understood it now. Let's understand it once more. Let's say, we have an A and we have B. So, B is inherited from A.

Now, we have some methods. M1, M2 and M3. Right? The same method will be done by inheritance M1.

M2 will be done and M3 will be done. And I said, B has M4 and M5, which are made for the specialised method. So, now, no client is here. We have a client.

What does it mean to talk about this? Basically, I have a method that I do one. So, it can be a method from a letter. I will tell it a random method.

In which I expect an A to be a pointer. See? I expect an A to be a reference. So, now, if I am expecting an A, what will be the client?

If I am expecting an A, what will be the client? Will the methods of that A call? So, it can be called as M1 from that reference. It can be written here.

The reference of A is written here. It can be written here from this reference. A dot M1 can be called like this. Here, it can be called M2.

Here, it can be called M3. That's it. This method can be called M1, M2 and M3. Right?

So, I said that when the client is talking about A, that is, the reference of A will be passed here. So, M1, M2, M3 will be called. But I am saying that the list of the tradition principle, or LSP, is that the B in our subclass, if I send it here, what will happen? So, here, the basic list will be assigned.

So, the code will be like this. A star A equal to nu B. If I send B here, that's how it will happen. So, I can call M1, M2, M3.

So, I will call M1 from this variable A, if I call M1, M2, and M3, then it will also work. Right? Because M1, M2, M3 is also here. Inheritance is also here.

So, I don't need to declare it in B. If I had to declare it here, if I had to declare it here, sorry, I would have to define it here. If I had to declare it here, M1, M3, and I had to define it here. So, basically, it works here.

But let's say, it works, it works normally. So, this already defined by B, it doesn't need to define B. So, this is not happening. Right?

I, the client, it was never known, about M4 and M5 functions. This is specific to B, right? So, he never called it. So, he never called it.

So, everything is done. It should work. It should work. It is so simple, it is a list of substitution principles.

But inheritance, it works as simple as, it works as simple as, it works as much as it breaks. Why? It is used here, how it breaks. And how it can solve.

So, I hope you have understood this. Let's jump towards an example. Now, imagine, you will start with the UML diagram again. Okay?

We have a class of an account. Okay? This is a bank account. So, we have a class of an account.

Okay? And I am saying, we should have two features in each account. The one is deposit and withdraw. That is, I can deposit the cache.

And I can withdraw the cache. Let's say, this account is again, an abstract method. Let's write it like this. Okay?

That is, it does not define it. It just declares it and leaves it. And whatever is written in the chart, whatever is inheritance, okay? Now, I am going to apply the banking system related to the account class, the abstract class, and then I have decided to make a real concrete class.

So, I have made a savings account. I have made a current account. It can be a salary account. It can be a different account.

Now, let's go to two. A savings account or current account. Okay? Now, I have two classes.

Same is a class. And what are these two doing? They are inheriting it. Right?

If they are inheriting, they will have both functions. They will have a deposit. They will have withdraws. And they will have to override these methods.

Right? They will have to override this. And they will have to override the withdraw. So, this is our scenario.

Okay? It is absolutely right. You have to think that this is the account. The account is a savings account and the current account.

It is the account of the account. It is the inheritance relationship. So, what can we say? The account is a savings account.

The account is a current account. Okay? Now, let's say, again, we have a client. We always do the client.

Interface. So, the client always interacts with us. Because we know about that. We discuss that we work with the contract from the interface.

And we can also use the client. We can use any software, application. We can also interact with any class. We interact with the interface.

Now, the client is so knowledgeable that I can call the deposit and withdraw. So, let's make a proper class from the client. So, we have a client class. We have a client class.

Okay? And we have one to many accounts. Okay? This is a list.

It is a vector list. Accounts. And we have talked about all the accounts. The client is withdrawing the deposit and withdraw.

Now, we are seeing the list of the substitution principle. I have said that the bank has opened the new type of account. Okay? It is called fixed deposit account.

Okay? It is a very good account. It is more interesting if you keep money. What do you say?

We say fixed deposit. What do I write? The answer is fixed deposit account. Okay?

Now, I will take this account into interest. But, it will be available now. If you don't withdraw, you will know that there is an FD query. You cannot withdraw from the time period.

You can store it. You can deposit it. Basically, deposit is allowed. But, withdraw is not allowed.

But, I have thought that fixed deposit account is also an account. So, I will inherit it. Okay? So, if I will inherit it, then we have to define both the deposit and withdraw.

We have to override it. Now, we will easily override the deposit. Okay? We will override the deposit.

But, how will we override the withdraw? So, what do we generally do? If we can't override the withdraw, then we will do the work. We will override the withdraw here.

We will return the exception here. Sorry. We will simply do the exception through. So, we will write a simple through.

We will see that exception in the code. Now, we will do the exception. We have also accepted the exception through. Okay?

So, we thought that we can call the exception as if we can call the deposit. Now, where did the statement come? The client was aware of the list. The list of all the accounts is listed.

The list of all the accounts is listed. I can call the withdraws in this way. If the account was given by the mistake with the fixed deposit account and the client was given the withdraw. So, the exception should have been given.

And, the exception should not have been given. The client should have been given the exception. Because, the client is not aware of the exception. Sometimes.

So, the list of the substitution principle is broken. How is it broken? Because, the list of the substitution principle says that any child class should be substituted for his parent class. But, the fixed deposit child should not be substituted for his parent class.

Because, this makes a function withdraw. This is basically not able to override. Because, the function has to be overrated here. So, here, our list of the substitution principle breaks.

Now, how to solve this? First of all, let's solve a bad way. And, let's see the better way. The better way.

The better way. The bad way. The more people start the mind, the more they complete the study. That they do not use this way.

So, we will tell you that the fixed deposit account is being seen in this. Because, the exception is in the function withdraw. If the app is there, then, the account is there. The client code changes in this.

Basically, what will the client do? The list of accounts is in the loop. So, let's loop this. In this account list, let's say, accounts.

And, in that account, the deposit will be called and in that account, withdraw will be done. So, let's do a work. What do we do? Let's change the account.

That is, we put in the condition that if the account is the fixed deposit account, that is, the type of account is the fixed deposit. So, let's just call it deposit call. Sorry. And, if the account is else, then, deposit and withdraw can be called.

Right? If the client is changing the client, then, we have changed the client. But, this is very difficult. Because, what have you done?

Your client is tightly coupled with all the accounts. But, I said, the client should only talk about the interface. So, the client should know that the interface is the deposit and withdraw. But, I don't know how much the interface is.

How they implement it. So, why do I have to know that, there is a fixed deposit account, which is deposit and withdraw. But, what have you done? Write this code.

The files have been written. The client has tightly coupled these three accounts. Because, you have to know the client. The client should be aware that the account is in the list of these accounts.

If it is a savings account, then, I can call it in this. If it is fixed, then, the client should be aware. Now, think about it. We have to open a new account tomorrow to open a new account.

Let's open a new account. And, will implement the account. I will also have some conditions. Let's say, there is a deposit in it, there is a random condition.

Then, I have to change the code again. Every time, what I have to do? I have to change the code of the client's class. Open Close Principle Break.

We have solved the list of principles. We have solved the list of the substitution principles. Open Close Principle Break. This is why it is very complicated.

Secondly, you have to use your application to not use your application. We used the abstraction use to talk only to the client. We don't need to know the client. How much is the real implementation?

How does it implement? What is it? It can be done in a bad way. And, what else can be done in a different way?

Let's see. Let's see. Let's see in this diagram. We will change the data from our own.

We will need it. First, we will remove all the things we have. You will know that we will do the exception. And, we will remove the whole code.

Start. We deleted all the things we had. We have done the same thing. Now, what we have done?

We have said that, where is the deposit? Where is the deposit? The account? The interface is the account.

The source is the account. There are two methods. The fixed deposit is the account. This is the deposit.

If we don't use the deposit, the fixed deposit is the account. This is the account. This is the account. If the account is the account, the parent's method is to define the result.

Then, the list of the substitution will follow. The client's feature will not be reduced. This will apply. The client's type can handle the data.

The parent's type can handle the text. The client's type is the tip of the video. The client's type is the tip of the video. What is the problem?

The client's features are reduced. The client's type is increased. The client's type should be increased. The client's type is the tip of the video.

We changed the diagram to a bit. Let us remove the account. و فیکς جی پوزیٹی ایک ہون کو ایدھا چیل رٹا دیاں اور اس کو ایک نیا اینٹر فیس دیتے ہیں ایدھا پیرینٹ لگہ کیا کہاں چاہتے ہیں تو چلو دیکھتے ایک کام کرتے سب سے پہلے ایک تو ہم رکتے ہیں نون ویدھ روائبل ایک ہون ایک ہون جن سے پیسا ویدھروں نہیں کیا جا جا سکتے ایک ہون جن سے پیسا ویدھروں نہیں کیا جا سکتے تو جن سے پیسا ایک ہون ایدھا گوو honour كذکہ جو کی ہونک کاری干گاروں نہیں لیکن تو جن سے پیسا ایک ہونک دیتے ہیں ویدھاquisite اور یہاں ہم ایک اپس دیتے ہیں یا کے انٹر فیس پیس کا اگومyi akin س warto لیکن اور میں ایک ہونک بہت دیم جس کا نام ہے hit with baelt忠 تو میں نے twiceствуہ ایک ہونکاز ایک ہونکاؤ ایک ہون taking اور یہ جو интерфейسے, یہ اس интерфейس کو extend ڈ کر رہے ہیں پر اچھا, ابھی دیکھنے پر کو بعد میں سالف کریں گے یہ کپسٹٹٹلاسے, دوسی اپسٹٹٹٹلاسے, یہ سے extend ڈ کر رہے تو یہ بھی حبی میں لکتے تھا, abstract اب یہ ایک ایک extend ڈ کر رہے, تو اس میں کا deposit function تو اس میں بھی deposit اپنے اپنے آپا گیاں, تو وہ لیکنے کے ضرطی نہیں ہے بلکی ایک نیا فنگشن ان انڈ کر دیا ہے بیچھا سوڑڈ رہے ہیں تو اب یہ حیرار کے ماری بن کیا بھی اب سمپل کیا کیا ہم نے جو بھی درویبل تراکی کیا ہوتے جسے کی ہماری پاس تھا کررنت کیا ہوت اور ہماری پاس تھا سیویگن سے کیا ہوت یہ اس کو extend ڈ کر رہے ہیں یہ اس کو extend ڈ کر رہے same ڈ کر رہے سے ہماری پاس جو سیویگن کیا ہوتے وہ بھی اس کو extend ڈ کر رہے گا اور جو ہماری پاس نون وڈ درویبل ایک ہون تھا جسے کی ہماری پاس جو ہے فیخز دیポزٹ ایک ہون تھا ہماری پاس یہ دیریکٹلی بات کرے گا کیسے نون وڈ درویبل ایک ہون تھا تو یہ اس کو extend ڈ کر رہے گا یہ اس کو inherit کر رہے گا تو یہ سارے ایز ریلیششپ سے تو ہماری پاس یہ بھی اس ہے یہ بھی اس ہے یہ بھی اس ہے سارے ایز ریلیششپ سے ہمیں ٹکہ اب یہ اس کو inherit کر رہے تو اس کے پاس بھی deposit کا methoda i جہے گا بس deposit i جہے گا اس کے پاس یہ اس کو کر رہے اور یہ logical اس کو کر رہے تو اس کے پاس دونوں آجہیں گے ایک تو deposit بھی آجہے گا اور with the draw بھی آجہے گا same here p بھی آجہے گا deposit بھی آجہے گا اور with the draw بھی آجہے گا تو یہ ہے کہانی پوری کی پوری ہم نے کیا کیا یہاں پی جیسے گی ایک وہ تھا abstraction تھا Account ٹینوں اسی کو implement کر رہے گا ہم نے 2 abstractions کر دیا 2 level بھی 2 high-rg بناتی بھی سیگلی یہ high-rg بنا یہ ہم نے ایک non with the draw بھی Account نون with the draw بھی just a single deposit withdraw بھی اس کو inherit کر دیا تو deposit بھی آجہے گا اور باکی کی کہانی same ہے اب just current and saving account یعنی کی fixed deposit call کا parent ہم نے change کر دیا اب یہ change کر دیا کیا ہوا اب یہ list of principle کو dank سے follow ڈکہ گا فور ایک اب جو ہمارے پس Client ہو گا ایک اس کے پاس 2 list ہوں گی اب پہلے Client کے پاس 1 list ایک ایک Accounts کی پر اب Client کے پاس 2 طرح کے list ایک ہو گی ہمارے پاس Client کی non with draw بھی Accounts کی list اور ایک ہو گی with draw بھی Accounts کی list اب non with draw بھی Accounts کی list سے ایک Client کوئی بات already پہ دا ہے کہ اس طرح کی Account میں مجھے with draw call نہیں کرنا اس میں Client Open Close Principle کو break نہیں کر را کیوں کی Client tightly couple haini Client کو بس یہ باتتا ہے کی مہے بات 2 list ایک non with draw بھی Accounts ایک with draw بھی Accounts اور یہ Interface ہے مجھے Interface بتا ہے یہ کہتا سے if deposit سے مہ deposit call کر ہوں گا یہ کہتا if with draw plus deposit سے مہ deposit call کر ہوں گا simple Client کو اور کو جانے گزرت نہیں ہے اور Client سے فنترہٹ کرے گا اس سے اور اس سے تو اگر ہم دیان سے دیکھیں تو اس کو ہم اس کو ایسے draw کر سکتے ہیں کی یہ جو ہماری Client class ہے Client has this and has this کی ہے یہاں پی بھی Client کے پاس 1 to many تھا تو یہاں پی بھی Client کے پاس 1 to many یہ بھی ہے اور 1 to many یہ بھی ہے تو Client has 1 to many non with draw بھی Account اور 1 to many with draw بھی Account تو ہمارے پاس یہ پورا کا پورا ایو ایمیڈیگرہ میں ہم یہاں بن کے آتا ہے تو یہی سب جو ہم نے پڑا اسی کو فڑا فٹ سےコード میں دیکھتے چا لو حنجی تو یہ رہا کھوڑ آپ کی Scream پہ فٹا فٹ سے دیکھتے ہیں جو ہم نے بات کی بھی بلکہ وہیں تو سپ سے پہلے تو ہم یہ کرتے ہیں کی ہم نے سپ سے پہلے ایک Account class بنائی کیا Account class میں 2 میثہت رکھے Deposit اور وضرو دو نو وڈچول میثہتے ہیں یعنی کی ایک اپسٹٹلاز ہے اس کو انہرٹ کرنا پڑے گا اور اس کو override کرنا پڑے گا پھر میں نے 3 طرح کی Account بنائی Account , Current Account اور Fixed account یہ وہی ہے جو our LLoscope Substitution Principle کو بریک کر رہے تو Saving like how i have said یہ ایک Balanced لیتے ہیں اور Deposit اس میں Deposit ہے اور withdraw biya Deposit اللیم بلنس جو بھی amount کیا ہے ایک Account Checked کہ وہ Negative تو نہیں ہے اگر Negative ہوا رہا ہے ایک بتا وضروک تم سیدھا پرین کر دیں انسپشن فند نیتھا ہم بول دیں گے ویدھران امر ویدھران بلکل سیم لوگی کرنٹ میں بھی ہے سپ کچھ سیم ہے اس میں بھی دیپاوزٹ ہے اس میں بھی درو ہے اور بہیں سپ کر رہے اب آتے فکسٹھا میں گاؤنٹ اب اس نے کیا کیا کیوں کیا دیپاوزٹ تو ایزی لی کر سکتے ہیں تو اس نے دیپاوزٹ کر دیا لیکن اس کے بہت ویدھرو ہندر کرنے کو بتا دیگا نہیں تھا تو ایک ٹرییک اچھ بلک لگا دیا تو اب دیکھو کیا ہوگا جبی προسسٹرن سکچن چلے گا تو جو جو ایک کونز اس میں کیا کہتے ہیں ہمارے فکسٹھا میں کونٹ ہوں گے اس میں تو ایسارے ویدھرو فٹ جائیں گے اس میں ایک سپشن آجے گا تو یہی ہم نے دیکھو یہ کیا ایک کونز کی لیسٹھا میں نہیں اور اس میں ٹین ایک کونز پوشبیا کر دیئے ایک تو سیویگنگ ایک کارنگ ایک فکسٹ تو جیسی ہم نے یہ دونوں جو ہے اس میں فکسٹ اور اسہری ویدھرو اور دیپوزٹ دونوں چلے گا اس میں سپڑی پوزٹ چلے گا ویدھرو نہیں چلے گا اور پھر ہم نے کیا کہ بینگ کلین کو یہ کونٹ سکچن دیا اور ایک کونٹ سکچن پروسسٹرن سکچن کال کرا دیا اب اگر ہم جبیس کو رنگ کرتے ہیں تو اب دیکھو کیا ہوگا پہلے تو دیپوزٹٹٹ دیپوزٹٹ دیپوزٹٹ دیپوزٹٹ چلے گیا دونوں کے لئے لیکن ٹیسٹرکلے سے بڑپوزٹ چلے ٹھیکسپشن آگئی ویدھرول کے لے کہ ویدھرول not allowed in fixed term account تو یہ ہماری دکتا ہے لسکоф سپڑٹیشن принципل کی کیا فالو نہیں ہو رہا اب وہا لکوٹ دیکھتے ہیں جس میں ہم نے سے سالف کرنے کی کوشش کی دیگلت تڑیگے سے تو یہ رہا وہ کور جس میں ہم نے گلت تڑیگے سے لسکоф سپڑٹیشن принципل کو ہندل گیا تھا تو same ay بھی بلکول اگدام ہم نے گیا دیکھو وہی ہے account deposit with draw کر سکتے ہیں savings account, current account, fixed term account ہم نے گا یہ سپ تو same ay رہا ہم نکان fixed term account same ay current account same ay اور savings account بھی بھی بھی بھی بھی بھی بھی بھی بھی fixed term account exceptionally ہے λوچی کا لیرے رہے exceptionally ہے کام کرتے ہیں کلائنٹ کو آویر کر دے دے یہ تو ہم نے بات کی دیگی تو کلائنٹ کے προسس ٹرن سکشن کر دیا ہم نے loop کیا دیکھا Account میں deposit call کر دے اب پہلے with draw call کر دے سے پہلے اس کا time دیکھلے ہم نے کیا گا وہ fixed term account تو ہم نے اس کو skip کر دیا اور باکیوں کے لیا ہم نے with draw call کر دیا پری یہ تو gala تریگا تھا اس میں گراپ call کر گے تو اس کے لے وہ سکی پو جائے گا اور باکیوں کے لچل جائے گا skipping withdrawal for fixed term account یہ چل دو گیا پری گلا تریگا کیا ہم نے open close principle BREAK ہو گیا اس کلس کے لئے جا کر کے code چنجیس کر نے پڑے اب ایسے کل کو اور کئی account aying تو بھی ہم نے دو بھی کلس کی کو چنجیس کر نے پڑے تو یہ بکارت دیکھا تھا صیت دیکھا تھا وہ یہ رہ یہ رہ وہ صیت دیکھا آپ کی screen اب اگر آپ اس کو دہان سے دیکھا تو ہمارے پاس کیا ہے deposit only sorry اس کو اس کو اس کو اس کو اس کو اس کو اس کو اس کو اس کو اس کو اس کو withdrawable accounts کے لستے اور ایک deposit only accounts کے لستے same ہم نے constructor کے through in list کو initialize اور اب جو process transection کا method ہے اس میں ایک دو اگر لگلوب چلا ہے ایک withdrawal کے لئے withdrawal کے لئے withdrawal میں 1 deposit اور withdrawal 2 call اور deposit only میں 1 deposit call اور deposit only just a fixed client ایک object which we have a list pass اور his process transaction call اور his code will be so if we see his code then our print will be so deposit withdraw withdraw withdraw withdraw withdraw withdraw withdraw withdraw withdraw withdraw withdraw withdraw withdraw withdraw betrayal Bag wic