شرح فروق بين مفاهيم في جافا

السلام عليكم ورحمة الله وبركاته..

1- أعتقد أن الفرق بين overloading و overriding هو:

أن overriding للmethod تعني أنه عندما يتم توريث الميثود من super class فإنه يستخدم نفس الاسم لها بنفس الparameter مع تغيير في محتوى ال method

أما بالنسبة للoverloading فإنه يتم استخدام الmethod بنفس الاسم ونفس المحتوى لكن الparameter يتغير..-شاهد الصورة المرفقة-

2- Set تعني method للتعديل وGet تعني method للقراءة

هذا والله أعلم

رد الاخت zinab90 كان صحيحا 100% وهذا هو الفرق الفعلى بين overloading & overriding

اما عن ما هى getter & setter methods :

هما methods تكتب لكى تعطيك الصلاحيات للدخول لـلتعديل او القراءه على data field يكون صلاحيته private

ويكون هذا النظام فى كتابه الـ classes نظام الـكبسله او encapsulation

وهذا مثال بسيط على هذه الـ methods :

public class student {

    private String fullname;

    public String getFullname() {
        return fullname;
    }

    public void setFullname(String fullname) {
        this.fullname = fullname;
    }
}

اما عن الـ abstract فهناك abstract class و abstract method

وهذه هى طريقه كتابتهم

public abstract class student {

    public abstract void run();

    public abstract int sum();
}

فاى منهما لا وبالذات فى الـ methods لابد وان لا تحتوى على body اى لابد وان تكون فارغه حتى تتمكن من ان تجعل منها override

اما الفرق بين abstract class و الـ interface فالفارق ليس بالجوهرى هما الاثنان يصنعان نفس الفكره وهى ان تكون شىء فارغا لا يحتوى الا على اسماء فقط ثم تعمل له override فى حاله الـ class او implements فى حاله الـ interface

وهذا مثال على الـ interface

interface IntExample{

public void sayHello();
}
}

ستجد ان الاثنان متشابهين جدا جدا

اما عن الفرق بين late & early binding فحاول قراه الكلمات التاليه

بالنسبة للسؤال الخاص بـ early and late binding

لا علاقة له بجافا

ولا علاقة له بالوراثة

انظر هنا

http://word.mvps.org/faqs/interdev/earlyvslatebinding.htm

هذا أسلوب برمجي يمثل proxy pattern

للكائنات التي تستهلك الموارد

تحياتي

أوضحلك يا أخى بطريقة مبسطة

1- OverLoading & OverRiding

OverLoading

تتم بين اكتر من ميثود فى كلاس واحد و يكون لهما نفس الاسم

و الاختلاف بين الميثود و الأخرى يكون فى

-الباراميترات

-ال modifiers يعنى كونهم ,public , protected , private, default أو كما تشاء فى التنويع بينهم

مع العلم أنه فى حالة الـ private لن يتسنى لك استخدام الدالة من الأوبجكت

و هى خاصية مفيدة جدا حيث يمكنك مثلا عمل دالة لها أكثر من وظيفة حسب البارامترات المدخلة (نظريا)

مثال :

public class tryMethods {


	public static void main(String[] args) {

		Methods m = new Methods();
		m.Print();

		m.Print(3);

		m.Print("Welcome");

	}


}

class Methods{

	public void Print(){

		System.out.println("No name or number...");

	}
	protected void Print(int i){

		System.out.println(Integer.toString(i*2));

	}
	public void Print(String x){

		System.out.println(x);

	}


}

Overriding

شبيهة بال overloading إلى حد ما و لكنها

- لا تحدث بين الدالتين فى كلاس واحد إنما بين كلاس و كلاس وارث منه

-نفس البارامترات

- الاختلاف فى الmodifiers يكون مقنن حيث يمكنك التغيير (فى الكلاس الوارث) و لكن لmodifier صلاحيته أعلى (أقل تقييدا) و يمكنك استخدام نفس ال modifier

و لك أن تضيف static , synchronized,final أو غيرهم

و التدريج من أعلى لأسفل كالتالى:

public

protected

default

ولا مجال للـ private هنا

و إن قمت بأخذ object من الكلاس الوارث و نفذت الدالة من غير override سيتم تنفيذ دالة الكلاس الموروث منه

إنما بتطبيق ال override يتم تنفيذ دالة الكلاس الوارث

كلاس وارث = sub Class

كلاس موروث منه = Super Class

ملحوظة : يمكنت إضافة @Override

قبل اسم الميثود التى ترغب فى أن تعمل Override لكى يساعدك ال compiler فى عمل override سليم :wink:

مثال :

public class TryInhirit {


	public static void main(String[] args) {

	Employee e = new Employee();
	float sal =e.countSal();
	// هنا يطبع الخاج الخاص ب Employee
	System.out.println(Float.toString(sal));

	Manager m = new Manager();
	sal = m.countSal();
	// هنا يطبع الخاج الخاص ب Manager
	System.out.println(Float.toString(sal));

	sal = m.countSal(2);
	// لاحظ هنا overload
	System.out.println(Float.toString(sal));
}

}
class Employee{
	float sal=10;

		 float countSal(){

		return sal;
	}

	void printHi(){
		System.out.println("Hi");
	}

}

class Manager extends Employee{
	@Override
		protected float countSal(){
		return sal*2;
	}

	float countSal(int x){

		return x*sal;

	}

}

أرجو التنبيه من الأخوة إن أخطأت ,, شكراا

2- Setter & Getter

لآ أجد فائدة للفرق بينهما سوى أن

ال Setter تكون void لها بارامتر

ال Getter يكون لها return type

و عامة Setter & Getter مصطلح متفق عليه عند جميع مبرمجي الجافا و مزاياه كثيرة

-يعطى أمانا أكثر لبرنامجك

-يعطيك طبعا من الخباثة :cool: سأوضحه فيما بعد

-و أصبح يعطى وصولا أسهل حيث أن 99% من الكلاسات إن لم يكن كلها يستخدم هذا المصطلح

و هتان الدالتان متلازمتان (ليس إجباريا و لكن يفضل ذلك)

الفكرة

قم بعمل متغير private مثلا اسمه x و نوعه int

private int x;

إذا حين تأخذ object من الكلاس لن تتسنى لك رؤية الobject

هنا يأتى دور ال Setter

و قاعدة التسمية : إن كان اسم المتغير variable

set+Variable

أى نضيف قبله set

و نضيف اسم المتغير مع جعل أول حرف منه capital

هكذا

void setX(int n)
{
x=n*2;
}

ستجد أنك أدخلت قيمة للدالة كـ(بارامتر) و حدث الآتى

-تم وضع القيمة التى أدخلتها فى متغير private

-عملت عملية فى الرقم المدخل و هذا سيفيدك عندما يكون المتغير من أنواع يصعب على المستخدم التعامل معها .

-تم وضع القيمة (مشفرة) فيمكنك ضرب القيمة مثلا فى 2 و عند استرجاعها تقسم على 2 فيكون هذا الرقم مشفر إلى حد ما أى لا يتضح للمستخدم ما هى القيمة المخزنة (بخباااااااثة) :haha:

و يتم الاسترجاع أو الاستعلام عن المتغير ال private عن طريق ال Getter

و قاعدة تسميته مثل ال Setter تماما

get+Variable

مثال :

int getX(){
return x/2;
}

و يكون كل تعاملك مع الدالتين setter و getter

ستجدهم بصورة مبالغ فيها فى تعاملك للكلاسات المختلفة

أذكرك أن هذا المصطلح ليس إجبارى و لكن يفضل التعامل به لأنك ستتعامل معها كثيرا مستقبلا إن شاء الله و ستكون متمرسا معها

أتمنى من الاخوة إن وجدوا لى أخطاء فليصححوها ,, شكراا

3-abstract & interface

أوضح لك أولا معنى

abstract & concrete

و هما صفتان للclass و الmethod

بمعنى

إضافة كلمة abstract قبل الــ

Class : يمنعك من أخذ object منه

method : يجعلها فارغة لا تحتوى على Body (سأوضح الفائدة فيما بعد)

أما Concrete

تعنى أن ال class ليس abstract و ال method ليست abstract

فهما class و method عاديان جداااا

ولا تكتب concrete قبلهما

أمثلة

مع الclass

abstract class test{
}

مع ال method

abstract void count();

مع الملاحظة

لا يمكنك وضع abstract method داخل concrete class

إذا أى class يحتوى على abstract method تستنتج أنه abstract class

أما ال abstract class يمكنك وضع concrete method فيه

فائدة الـ abstract method

تجبرك عندما ترث ال class أن تعمل لهم override

يعنى الـ override سيكون حينها إجبارى

Interface

ظهر لحل مشكلة تعدد الوراثة فلا يمكنك جعل كلاس يرث من أكثر من كلاس أبدا

فحل المشكلة تقريبا فأصبح لك أن ترث من class واحد و أن تستخدم دوال أكثر من interface

و الinterface يكتب كالتالى

interface Emp{

}

و كل المتغيرات بداخله يجب أن تكون public final static

و الmethods تكون public abstract

تستنتج أنه عليك عمل override لكل ال methods بداخله

اذا الكلاس

لل، class تعمل له extend

والـ interface تعمل له implements

أما ال interface

لل interface يعمل له extend و بالمقدور عمل أكتر من extend لأكثر من interface

و لا يستطيع أن يقترب من ال class :cool:

مثال :

interface A{

	public abstract void sell();

}
interface B extends A,C{}

interface C {}

class Employee{
	float sal=10;

		 float countSal(){

		return sal;
	}



}

class Manager extends Employee implements A,B,C{
	@Override
		protected float countSal(){
		return sal*2;
	}

	@Override
	public void sell() {
		System.out.println("Sold...");

	}
}
public class TryInhirit {


	public static void main(String[] args) {
		float sal;

	Manager m = new Manager();
	sal = m.countSal();

	System.out.println(Float.toString(sal));
	m.sell();

}

}

و إن لم تعمل override ل abstract method سينبهك ال compiler بذلك

أرجو من الاخوة توضيح إن أخطأت ,, شكرااا

السلام عليكم ...

الإخوة لم يقصروا بالشرح ...

عند دراسة لغات البرمجة أو الــ OOP أو الــ design Pattern أو ... يجب التركيز على أمرين :

1. موضوع الـ "كيفَ" How : أي كيف نقوم بالشئ , بمعني أننا كيف نعمل Override للـ Method و كيف نعمل Overload و كيف نجعل الــ Class كــ Abstract و .. الخ .
2. موضوع الــ "لماذا" Why : أي لماذا نقوم بالشئ , بمعنى لماذا نجعل الــ Class كـ Abstract و لماذا نجعل المتحولات كــ Private و لماذا نستخدم الــ Inheritance و .. الخ .

سأذكر بعض المعلومات عن الــ Why ..

1. لماذ الــ Setter و الــ Getter للـ Private Variables : ببساطة لأن تغيير قيم بعض المتحولات يجب أن يرافقه قيود و اعمال أخرى .. بمعنى أن المتحولات التي عند تغيير قيمها يجب فحص قيمتها و التأكد منها أو القيام بشئ ما عند تغيير القيمة , يجب وضع هذه المتحولات كــ Private أما المتحولات التي لا قيود أو لا أعمال أخرى فلا مانع من وضعها كـ Public ولكن درجت العادة (Coding Style) أن متجولات الصف تكون Private (و أحيانا Protected) فنحن لو أردنا تغيير قيمة متحول مباشرة صرنا نكتب كلمة set لتخرج لنا قائمة الإكمال التلقائي AutoComplete و تظهر لنا الإجرائيات التي تبدأ بــ set ..
   1. مثال على القيد Constraint : لنفرض أنه لدينا صف Employee و من القيود لدينا في النظام (مثلا) أنه ممنوع أن يكون اسم الموظف فيه أرقام , فنضع هذا القيد في الــ setter للـ Name كمايلي :
      
      {
      private String m_Name="";
      
      public void setName(String name)
      {
      for(int i = 0 ; i < name.length() ; i ++)
      if(Character.isDigit(name.charAt(i)))
      throw new IllegalArgumentException("Employee name Can Not Contain Digits.");
      }
      
      }

      public class Employee

      و عند التجريب لنحاول :
      
      employee.setName("hou1ssam");

       Employee employee = new Employee();

      سنجد ظهر رسالة الخطأ التي حددناها في الــ Exception . و الأمثلة على القيود كثيرة , مثلا قيم الشهر يجب أن تكون من 1 و حتى 12 , و قيد آخر أنه لا يمكن تغير اسم المستخدم مثلا و الأتصال مفتوح ... الخ.
   2. مثال على العمل Action : لنفرض أنه لدينا صف Shape يمثل شكل ما يمكن رسمه و له خصائص مثل اللون و الحجم .. فكلما غيرنا اللون أو الحجم يجب إعادة رسم الشكل من جديد حتى يظهر اللون الجديد و الحجم الجديد .. و لو كان المتحول Width أو Color متحولان عامان لحصل خطأ منطقي أنه يمكننا تغيير قيمهما دون أن تظهر التغيرات الجديدة :
      
      {
      private Color mColor = Color.red;
      
      public void setColor(Color color)
      {
      if(this.mColor != color)
      {
      this.mColor = color;
      ReDrawShape();
      }
      }
      
      private void ReDrawShape()
      {
      //Draw your Shape Here
      System.out.println("Shape ReDraw With new Color" + mColor);
      }
      }

      class Shape

      و الاستدعاء :
      
      shape.setColor(Color.yellow);

      Shape shape = new Shape();

      و بانسبة للـ Getter نفس الشئ .. إما قيد أو عمل شئ ما ...و المثال التالي واضح :
      
      {
      
      private Employee mManager;
      
      public Employee getManager()
      {
      if (mManager == null)
      selectManagerFromDB();
      
      return mManager;
      
      }
      
      private void selectManagerFromDB()
      {
      //mManager = select Manager from DB
      }
      }
      

      public class Employee

   3. لماذا الــ abstract class : عندما نحاول بناء هرمية صفوف خاصة بنا, و تجميع الإجرائيات المشتركة و وضعها في الصف الأب , نجد أن الــ Implementation لاحد الإجرائيات تختلف من صف ابن إلى صف آخر و سنأخذ مثال على ذلك من الــ JDK ..لنأخذ مثلا الــصفوف FileInputStream و ByteArrayInputStream و ObjectInputStream و PipedInputStream و StringBufferInputStream هي صفوف تشترك بعدة إجرائيات لذلك تم وضع الإجرائيات المشتركة في صف اسمه InputStream ولكن عند عمل تحقيق فعلي Concrete للإجرائية read تبين أنها تختلف من صف لآخر , فقراءة البيانات من ملف تختلف عن قراءة البيانات من سلسلة نصية لذلك تم تعريف الإجرائية read على أنها abstract وبالتالي الصف InputStream كله abstract أي لا يمكن عمل new منه :
      
      byte[] buff = new byte[] {1 , 2, 3,4 , 5};
      InputStream inputStream ;
      if(x == 1)
      inputStream = new FileInputStream("E:\\d1.txt");
      else
      inputStream = new ByteArrayInputStream(buff);
      
      int toRead = inputStream.read();
      System.out.println(toRead);

      int x = 0 ;

      و لو لم تكن الإجرائية read معرفة داخل الصف InputStream لما استطعنا استخدامها بهذا الشكل ..
   4. لماذا الــ Overriding : ببساطة لأن آلية عمل الإجراء في الصف الأب لم تعد مناسبة للصف الأبن و كمثال على ذلك في الــ JDK .. نعلم أن كلا من الصفين TextArea و TextField يرث من الصف TextComponent الذي فيه إجرائية setText لوضع النص و لكن بما أن الــ TextField يمثل حقل نصي بسطر واحد فإن الــ setText الموجودة في الصف الأب TextComponent لم تعد تناسبه لذلك يعمل لها Overriding و يعمل إجرائية جديدة (تغطي ) الإجرائية القديمة و لكن تقوم بإضافة النص في سطر واحد و ليس في أسطر عدة كما في TextArea الذي لم يعمل Overriding للإجرائية setText لأن طريقة عملها تناسبه في إضافة النص في عدة اسطر ..المثال :
      
      TextComponent textComponent2;
      
      
      textComponent1 = new TextField();
      textComponent1.setText("Hel\r\nlo");
      
      
      textComponent2 = new TextArea();
      textComponent2.setText("Hel\r\nlo");
      Frame frame = new Frame();
      frame.setLayout(new FlowLayout());
      frame.setSize(300 , 300);
      frame.add(textComponent1);
      frame.add(textComponent2);
      frame.show();
      

      TextComponent textComponent1;

      شغله و ستلاحظ كيف تم إضافة خانتي نص و لكن واحدة فيها النص بسطر واحد و الأخرى بسطرين مع أننا استخدمنا نفس قيمة النص و نفس الإجرائية ..
   5. لماذا الــ Interface : أنا لست من مؤيدي فكرة أن الــ Interface جاءت لتحل مشكلة الورائة المتعددة , فهناك لغات تدعم الوراثة المتعددة و الــ Interface في وقت واحد , و هل نظن أن مبرمجي مترجم (Compiler) الجافا عجزوا عن جعل الجافا تدعم الورائة المتعددة فيما نجح بذلك واضعو (مترجم) لغة الـ Cpp .. باختصار (باعتقادي) عندما تصبح كل الإجرائيات في الصف مجردة , يتم تحويله إلى Interface ..لأنه لم يعد فيه أي إجراء فعلي Concrete .. و كمثال على ذلك الواجهة MenuContainer التي تحققها الكثير من صفوف الـJDK و بالتالي يمكننا النظر إلى هذه الصفوف كلها على أنها من نوع واحد هو هذه الواجهة .. :

      MenuContainer [] MenuContainerArray = new MenuContainer[] {new Button() , new TextArea() , new Frame() , new JScrollBar()};

      
      و الله أعلم ..

houssam11350_11350 كتب:

شغله و ستلاحظ كيف تم إضافة خانتي نص و لكن واحدة فيها النص بسطر واحد و الأخرى بسطرين مع أننا استخدمنا نفس قيمة النص و نفس الإجرائية ..[*]لماذا الــ Interface : أنا لست من مؤيدي فكرة أن الــ Interface جاءت لتحل مشكلة الورائة المتعددة , فهناك لغات تدعم الوراثة المتعددة و الــ Interface في وقت واحد , و هل نظن أن مبرمجي مترجم (Compiler) الجافا عجزوا عن جعل الجافا تدعم الورائة المتعددة فيما نجح بذلك واضعو (مترجم) لغة الـ Cpp .. باختصار (باعتقادي) عندما تصبح كل الإجرائيات في الصف مجردة , يتم تحويله إلى Interface ..لأنه لم يعد فيه أي إجراء فعلي Concrete .. و كمثال على ذلك الواجهة MenuContainer التي تحققها الكثير من صفوف الـJDK و بالتالي يمكننا النظر إلى هذه الصفوف كلها على أنها من نوع واحد هو هذه الواجهة .. :

MenuContainer [] MenuContainerArray = new MenuContainer[] {new Button() , new TextArea() , new Frame() , new JScrollBar()};

و الله أعلم ..

لم أقصد بقولى مشكلة أنها معضلة آسف أسأت التعبير ,, أعتبر الـ interface مجرد abstract class يطبق قواعد ال abstract إجباريا على كل ما بداخله

جزاك الله خيرا