SOLID principles شرح | Part 2

ما شوفت الجزء الأول من SOLID تعالى نشوف باقى المبادئ لنتخلص من الاسبجتى كود

دردشة

احنا كنا اتكلمنا عن 2 من مبادئ SOLID وكنا ماشين الحروف بالترتيب خلصنا S - O وطبعا بعد ما تشوف المقالات هنا لازم تكمل عليها بالسيرش والتطبيق عشان الحاجات دى مهم تكون عارفها كويس المهم عشان انا رغاى انا عارف تعالى نكمل المبادئ ال 3 اللى فاضله .

1- Liskov

2- Interface Segregation

3- Dependency inversion

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Liskov

بص يا سيدى كان فى واحده اسمها Barbara Liskov فى مؤتمر سنه 1987 عرضت المبدأ دا عشان كدا اتسمه باسمها كويس انه مش اسمها الاول

قالت ايه بقا "إذا كانت S هي sub_class من T، فيمكن استبدال كائنات من النوع T بكائنات من النوع S دون التسبب بمشاكل في التطبيق" مقصود بالكائنات الاوبجيكتات طب الكلام دا معناه اية؟

أن لو شيلت اى اوبجيكت من نوع ال parent class وبدلته ب اوبجيكت من ال sub_class بتاعه يفضل كل خصائص وميثود ال parent class زى ما هى وأن ال sub_class متغيرش فيه والبرنامج ميحسش بأى تغير.

الخلاصه"Subtypes must be substitutable for their base types"

مثال توضيحى

- parent class

class Vehicle{
	
	String color;
	int speed;
	
	public String getColor(){
		
		//return color
	}
	
	public String getSpeed(){
		
		//return speed
	}
	
}

- two sub-class

class Car extends Vehicle{
	
	
	public boolean isSelfDriving(){
		
		//return value
	}
	
}

class plane extends Vehicle{
	
	
	public double getMaximumHeight(){
		
		//return value
	}
	
}

تعالى بقا نستخدم مبدأ Liskov

Vehicle vehicle = new Plane() ;
vehicle.getSpeed();
vehicle = new Car();
vehicle.getColor();

لاحظ هنا انى لو استبدلت parent class بأى اوبجيكت بكلاس وارث منه مفيش حاجه هتتغير فى البرنامج .

لو ركزت شويه هتلاقيه نفس مبدأ ال polymorphism

دا بيساعدك فتوسيع مشروعك .

تخيل انت كل شويه محتاج تضيف كلاس جديد وتوسع مشروعك وكل شويه وانت بتبعت اوبجيكت فهتحتاج كل شويه تتأكد هو من أى كلاس فهتعمل جمل if كتير ممكن تكون بتتأكد بكلمه instance of او باى طريقه تانيه.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Interface Segregation

خلينى افرحك واقولك ان المبدأ دا سهل خالص ومش هناخد فيه شرح كتير المبدأ اسمه Interface Segregation بس احنا كدا خلصنا ايو بجد والله .

اصل المبدأ باين مش أنت ساعات بتكون عندك class بيعمل implement ل interface

قدر انت مش عايزه يعمل override لكل الميثود اللى فى ال interface مثلا محتاج method_1 , method_2 وفيه class تانى محتاج method_3 المبدأ اسمه ايه "فصل الانترفيس" فهتقسم ال interface يبقى interface_1 , interface_2

وكل class يعملimplement لل interface بتاعه بس كدا.

مثال توضيحى

اعتقد ان مش محتاج مثال عشان منطولش بس خلينا أسألك واقولك لو أنت عندى class بيعمل implement ل interface وفيه ميثود انا مستخدمتهاش يبقا كدا بحقق المبدأ ولا لا؟

بالظبط برافو عليك يبقى انا منفذتش مبدأ Interface Segregation.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Dependency inversion

لو دماغك فيها حاجه فضيها لان دا مهم وفيه شويه تفاصيل فضيتها؟

بص بقا الاول احنا عارفين الفرق بين High-Level modules و Low-Level modules الموديل مقصود بيه الوحده زى كلاس او ميثود المهم لو انا عندى 2 كلاس الاول للكتاب والتانى للرف زى كدا

class Book {
 void seeReviews() {...}
 void readSample() {...}
}

class Shelf {
 Book book;
 void addBook(Book book) {...}
 void customizeShelf() {...}
}

خلينى أسالك بقا اى كلاس معتمد على التانى هتلاقى الرف معتمد على الكتاب صح يعنى ايه الكور عندى هو كلاس الكتاب ودا الكلاس اللى هيتنفذ الاول فبنسميه Low و كلاس الرف دا اللى فوق فنسميه High نوضحها اقدر الماتور والعربيه يبقى الماتور low والعربيه دى اللى فوق اللى انت بتشوفها فى النهايه كدا عرفنا الفرق بينهم اعتقد

الهدف بقا من المبدأ ايه هقولك . عايزك تخلى كلاس ال high ميعتمدش على كلاس ال low واخليهم يعتمدوا على ال abstract

مثال توضيحى

شوفت كلاس الكتاب والرف اللى مكتوبين فوق

1-كلاس book بيتيح للمستخدمين رؤية المراجعات وقراءة عينة من كل كتاب يخزنونه على الرفوف الخاصة بهم.

2-كلاس shelf بيتيح إضافة كتاب إلى رفهم وتخصيص الرف

طيب انت بتقول لو انا سيبتهم كدا مفهاش مشكله وايه يعنى هقولك بقا اهميه المبدأ هنا لو قولتلك صاحب المكتبه عايزك تمكن العملاء من إضافة أقراص DVD إلى أرففهم أيضاً .

فهتحتاج تعمل كلاس ليه

class DVD {
 void seeReviews() {...}
 void watchSample() {...}
}

وتروح تعدل كلاس shelf ولو عدلت فيه يبقا ضيعت مبدأ ال Open-Close اللى اتكلمنا فيه كمان قبل كدا طيب نعمل ايه؟ ما قولنا حلها من خلال ال abstract واننا منخليش كلاس high يعتمد على low

ركز هنا شوف عملنا ايه مع كلاس الBook وال DVD

public interface Product {
 void seeReviews();
 void getSample();
}

class Book implements Product {
 @Override
 public void seeReviews() {...}
 @Override
 public void getSample() {...}
}

class DVD implements Product {
 @Override
 public void seeReviews() {...}
 @Override
 public void getSample() {...}
}

شوف بقا كلاس الرف هنضيف فيه ال product سواء كتاب او DVD او حتى لو محتاج تضيف حاجه تانيه .

وطبعا class ال Book or DVD هتزود عليه الميثود بتاعتك غير ال override

class Shelf {
 Product product;
 void addProduct(Product product) {...}
 void customizeShelf() {...}
}

مش ملاحظ حاجه اننا طبقنا مبدأ Liskov المبدأ دا 3*1.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

الى اللقاء

عايز اقولك مبروك انت كدا بقيت عارف جزء كبير ومهم من Design Principal معلش انا عارف ان البوست كان طويل ويمكن فيه حاجات رخمه بس ياريت تمسك مبدأ مبدأ وتفهمه وتروح تسيرش وتفهمه اكتر وتشوف تطبيقه بامثاله اكتر عيد تانى على البوست لو وقع منك حاجه

#SOLID

#Design_Pattern

#Clean_Code

SOLID principles Part 1