ما هو الهدف من واضعي حاصل في جافا ؟ [مكررة]

Question

هذا السؤال سبق الجواب هنا:

• لماذا استخدام حاصل على واضعي/accessors?[مغلقة] 38 إجابات

يرجى أن يغفر طول لكن هنا نوعان من البرامج كل نفس ، ولكن واحد مع واحد دون واضعي ، حاصل ، والمنشئات.

لقد اتخذت الأساسية فئة C++ قبل و لا تذكر أي من هذه من ذلك ، و في هذه اللحظة أنا لا أرى وجهة لهم, إذا كان أي شخص يمكن أن تفسر لهم في lamen حيث سأكون ممتنا لك.... في اللحظة التي يبدو أن لا شيء أكثر من مساحة المبذرون لجعل قانون بلدي تبدو أطول ، ولكن المعلم يقول أنها مهمة (و حتى الآن أن كل شيء).

شكرا مقدما!و الآن ها هو الكود:Mileage.java:

package gasMileage;

import java.util.Scanner; //program uses class Scanner

public class Mileage 
{
    public int restart;
    public double miles, gallons, totalMiles, totalGallons, milesPerGallon;
    public Mileage(int newRestart, double newMiles, double newGallons, 
                   double newTotalMiles, double newTotalGallons, double newMilesPerGallon)
    {
        setRestart(newRestart);
        setMiles(newMiles);
        setGallons(newGallons);
        setTotalMiles(newTotalMiles);
        setTotalGallons(newTotalGallons);
        setMilesPerGallon(newMilesPerGallon);
    }
    public void setRestart(int newRestart)
    {
        restart = newRestart;
    }
    public int getRestart()
    {
        return restart;
    }
    public void setMiles(double newMiles)
    {
        miles = newMiles;
    }
    public double getMiles()
    {
        return miles;
    }
    public void setGallons(double newGallons)
    {
        gallons = newGallons;
    }
    public double getGallons()
    {
        return gallons;
    }
    public void setTotalMiles(double newTotalMiles)
    {
        totalMiles = newTotalMiles;
    }
    public double getTotalMiles()
    {
        return totalMiles;
    }
    public void setTotalGallons(double newTotalGallons)
    {
        totalGallons = newTotalGallons;
    }
    public double getTotalGallons()
    {
        return totalGallons;
    }
    public void setMilesPerGallon(double newMilesPerGallon)
    {
        milesPerGallon = newMilesPerGallon;
    }
    public double getMilesPerGallon()
    {
        return milesPerGallon;
    }
    public void calculateMileage()
    {
        Scanner input = new Scanner(System.in);
        while(restart == 1)
        {
            System.out.print("Please input number of miles you drove: ");
            miles = input.nextDouble();
            totalMiles = totalMiles + miles;
            System.out.print("Please input number of gallons you used: ");
            gallons = input.nextDouble();
            totalGallons = totalGallons + gallons;
            milesPerGallon = miles / gallons;
            System.out.printf("Your mileage is %.2f MPG.\n", milesPerGallon);
            System.out.print("Would you like to try again? 1 for yes, 2 for no: ");
            restart = input.nextInt();
        }
        milesPerGallon = totalMiles / totalGallons;
        System.out.printf("Your total mileage for these trips is: %.2f.\nYour total gas consumed on these trips was: %.2f.\n", totalMiles, totalGallons);
        System.out.printf("Your total mileage for these trips is: %.2f MPG", milesPerGallon);
    }
}

Mileagetest.java:

package gasMileage;

public class Mileagetest 
{
    public static void main(String[] args) 
    {
        Mileage myMileage = new Mileage(1,0,0,0,0,0);
        myMileage.calculateMileage();
    }
}

والآن واحد من دون واضعي و حاصل:

Testmileage.java:

package gasMileage;

import java.util.Scanner;

public class Testmileage 
{
    int restart = 1;
    double miles = 0, milesTotal = 0, gas = 0, gasTotal = 0, mpg = 0;
    Scanner input = new Scanner(System.in);
    public void testCalculate()
    {
        while(restart == 1)
        {
            System.out.print("Please input miles: ");
            miles = input.nextDouble();
            milesTotal = milesTotal + miles;
            System.out.print("Please input gas: ");
            gas = input.nextDouble();
            gasTotal = gasTotal + gas;
            mpg = miles/gas;
            System.out.printf("MPG: %.2f", mpg);
            System.out.print("\nContinue? 1 = yes, 2 = no: ");
            restart = input.nextInt();
        }
            mpg = milesTotal / gasTotal;
            System.out.printf("Total Miles: %.2f\nTotal Gallons: %.2f\nTotal MPG: %.2f\n", milesTotal, gasTotal, mpg);
    }
}

Testmileagetest.java:

package gasMileage;

public class Testmileagetest 
{

    /**
     * @param args
     */
    public static void main(String[] args) 
    {
        Testmileage test = new Testmileage();
        test.testCalculate();
    }

}

شكرا مرة أخرى!

Answer 1

نقطة حاصل على واضعي ، بغض النظر عن اللغة, هو لإخفاء متغير الأساسية.هذا يسمح لك لإضافة التحقق المنطق عند محاولة تعيين قيمة - على سبيل المثال ، إذا كان لديك حقل تاريخ الميلاد, قد ترغب فقط يسمح إعداد هذا المجال إلى بعض الوقت في الماضي.هذا لا يمكن القسري إذا كان الحقل هو متاح للجمهور ، modifyable - تحتاج حاصل على واضعي.

حتى إذا كنت لا تحتاج إلى أي التحقق حتى الآن ، قد تحتاج إليها في المستقبل.كتابة حاصل على واضعي الآن يعني يتم الاحتفاظ واجهة متسقة ، لذلك البرمجية الموجودة لن كسر عند تغيير ذلك.

Answer 2

تعطي الإجابات الأخرى عموما فكرة جيدة عن بعض الأسباب لاستخدام Getters و Setters، لكنني أرغب في إعطاء مثال كامل إلى حد ما لماذا فهي مفيدة.

دعنا نأخذ، على سبيل المثال، ملف (يتجاهل وجود File فئة في جافا). هذه File يحتوي الفصل على حقل لتخزين نوع الملف (.pdf، .exe، .txt، إلخ) ... سنتجاهل كل شيء آخر.

في البداية تقرر تخزينها ك String مع عدم وجود getters و setters:

public class File {
   // ...
   public String type;
   // ...
}

فيما يلي بعض المشكلات مع عدم استخدام Getters و Setters.

لا تحكم في كيفية تعيين الحقل:

يمكن لأي عملاء من صفك فعل ما يريدون به:

public void doSomething(File file) {
   // ...
   file.type = "this definitely isn't a normal file type";
   // ...
}

أنت تقرر لاحقا أنك ربما لا تريد أن تفعل ذلك ... ولكن نظرا لأن لديهم حق الوصول المباشر إلى الحقل في صفك، فلن يكون لديك طريقة لمنعها.

عدم القدرة على تغيير التمثيل الداخلي بسهولة:

لا يزال في وقت لاحق، عليك أن تقرر أنك تريد تخزين نوع الملف كمثيل يسمى FileType, ، مما يسمح لك بربط بعض السلوك مع أنواع الملفات المختلفة. ومع ذلك، فإن العديد من عملاء الفصل الخاص بك يسترجعون بالفعل ووضع أنواع الملفات Stringس. لذلك سيكون لديك مشكلة هناك ... كنت كسر الكثير من التعليمات البرمجية (حتى الرمز في المشاريع الأخرى التي لا يمكنك حلها، إذا كانت مكتبة) إذا قمت بتغيير الحقل فقط من String إلى أ FileType.

كيف تحصل getters و setters هذا

الآن تخيل أنك قد جعلت بدلا من ذلك private وإنشاء

public String getType() {
   return this.type;
}

public void setType(String type) {
   this.type = type;
}

السيطرة على إعداد الخاصية:

الآن، عندما تريد تطبيق متطلبات أن بعض السلاسل فقط أنواع الملفات صالحة وتمنع السلاسل الأخرى، يمكنك فقط كتابة:

public void setType(String type) {
   if(!isValidType(type)) {
       throw new IllegalArgumentException("Invalid file type: " + type);
   }
   this.type = type;
}

private boolean isValidType(String type) {
   // logic here
}

القدرة على تغيير التمثيل الداخلي بسهولة:

تغيير String تمثيل النوع سهل نسبيا. تخيل أن لديك enum ValidFileType التي تنفذ FileType ويحتوي على أنواع صالحة من الملفات.

يمكنك بسهولة تغيير التمثيل الداخلي لنوع الملف في الفصل مثل هذا:

public class File {
   // ...
   private FileType type;
   // ...
   public String getType() {
      return type.toString();
   }

   public void setType(String type) {
      FileType newType = ValidFileType.valueOf(type);

      if(newType == null) {
         throw new IllegalArgumentException("Invalid file type: " + type);
      }

      this.type = newType;
   }
}

منذ أن استدعاء عملاء الفصل getType() و setType() على أي حال، لا شيء يتغير من وجهة نظرهم. تم تغيير فقط Internals من الفصل، وليس الواجهة التي تستخدمها الفئات الأخرى.

Answer 3

التغليف

محاولة طرق الملحقات ("setters and getters") محاولة إخفاء التفاصيل حول كيفية تخزين البيانات الموجودة في كائن. في الممارسة العملية، فهي وسيلة تمجدها لتخزين واسترداد البيانات في أزياء غير موجهة نحو الكائنات. لا يغليف المستفيدون بشكل فعال أي شيء في هذا الفرق العملي القليل بين القطعتين التاليين من التعليمات البرمجية:

Person bob = new Person();
Colour hair = bob.getHairColour();
hair.setRed( 255 );

وهذا:

Person bob = new Person();
Colour hair = bob.hairColour;
hair.red = 255;

كلا مقتطفات الكود يعرض فكرة أن الشخص يقترن بإحكام إلى الشعر. ثم يكشف هذا الاقتران الضيق نفسه عبر قاعدة التعليمات البرمجية، مما يؤدي إلى برنامج هش. وهذا هو، يصبح من الصعب تغيير كيفية تخزين شعر الشخص.

في حين أن:

Person bob = new Person();
bob.setHairColour( Colour.RED );

هذا يتبع فرضية "أخبر، لا تسأل". بمعنى آخر، يجب توجيه الكائنات (بواسطة كائنات أخرى) لأداء مهمة محددة. هذه هي النقطة كاملة من البرمجة الموجهة للكائنات. ويبدو أن عدد قليل جدا من الناس يحصلون عليه.

الفرق بين السيناريوهين هو هذا:

• في الوضع الأول، لم يكن لدى بوب سيطرة على ما لون شعره سيصبح. عظيم لمصمام الشعر مع ميل للرؤوس، وليس عظيم جدا لبوب الذي يحتقر هذا اللون.
• في الوضع الثاني، يحتوي BOB على سيطرة كاملة على ما يصبح لون شعره لأنه لا يسمح لأي كائن آخر في النظام بتغيير هذا اللون دون إذن بوب.

هناك طريقة أخرى لتجنب هذه المشكلة هي إرجاع نسخة من لون الشعر بوب (كحل جديد)، لم يعد إلى جانب بوب. أجد أنه أن يكون حلا غير ممنوح لأنه يعني أن هناك سلوك يرغب فئة أخرى، باستخدام شعر الشخص، لم يعد مرتبطا بالشخص نفسه. التي تقلل من القدرة على إعادة استخدام التعليمات البرمجية، مما يؤدي إلى التعليمات البرمجية المكررة.

اختبئ أنواع البيانات

في Java، التي لا يمكن أن تحتوي على توقيعات طريقين تختلف فقط عن طريق نوع الإرجاع، فإنه لا يخفي حقا نوع البيانات الأساسي المستخدمة من قبل الكائن. سوف نادرا ما، إذا أرى ما يلي:

public class Person {
  private long hColour = 1024;

  public Colour getHairColour() {
    return new Colour( hColour & 255, hColour << 8 & 255, hColour << 16 & 255 );
  }
}

عادة ما يكون للمتغيرات الفردية نوع بياناته مكشوف حرفي عن طريق استخدام الملحق المقابل، ويتطلب إعادة التدوير لتغييره:

public class Person {
  private long hColour = 1024;

  public long getHairColour() {
    return hColour;
  }

  /** Cannot exist in Java: compile error. */
  public Colour getHairColour() {
    return new Colour( hColour & 255, hColour << 8 & 255, hColour<< 16 & 255 );
  }
}

في حين أنه يوفر مستوى من التجريد، إلا أن الحجاب الرقيق لا يفعل شيئا مقابل اقتران فضفاض.

قل، لا تسأل

لمزيد من المعلومات حول هذا النهج، اقرأ قل، لا تسأل.

ملف مثال

النظر في التعليمات البرمجية التالية، تعديل قليلا من إجابة colind:

public class File {
   private String type = "";

   public String getType() {
      return this.type;
   }

   public void setType( String type ) {
      if( type = null ) {
        type = "";
      }

      this.type = type;
   }

   public boolean isValidType( String type ) {
      return getType().equalsIgnoreCase( type );
   }
}

طريقة getType() في هذه الحالة زائدة عن الحاجة وسيؤدي حتما (في الممارسة) إلى رمز مكررة مثل:

public void arbitraryMethod( File file ) {
  if( file.getType() == "JPEG" ) {
    // Code.
  }
}

public void anotherArbitraryMethod( File file ) {
  if( file.getType() == "WP" ) {
    // Code.
  }
}

مشاكل:

• نوع البيانات. ال type لا يمكن تغيير السمة بسهولة من سلسلة إلى عدد صحيح (أو فئة أخرى).
• البروتوكول الضمني. لقد تم استهلاك الوقت لتجرخص النوع من المحدد (PNG, JPEG, TIFF, EPS) إلى الجنرال (IMAGE, DOCUMENT, SPREADSHEET).
• يقدم البق. لن يؤدي تغيير البروتوكول الضمني إلى إنشاء خطأ مترجم، مما قد يؤدي إلى الأخطاء.

تجنب المشكلة تماما عن طريق منع الطبقات الأخرى من يسأل للبيانات:

public void arbitraryMethod( File file ) {
  if( file.isValidType( "JPEG" ) ) {
    // Code.
  }
}

هذا يعني تغيير get طريقة الملحقات إلى private:

public class File {
   public final static String TYPE_IMAGE = "IMAGE";

   private String type = "";

   private String getType() {
      return this.type;
   }

   public void setType( String type ) {
      if( type == null ) {
        type = "";
      }
      else if(
        type.equalsIgnoreCase( "JPEG" ) ||
        type.equalsIgnoreCase( "JPG" ) ||
        type.equalsIgnoreCase( "PNG" ) ) {
        type = File.TYPE_IMAGE;
      }

      this.type = type;
   }

   public boolean isValidType( String type ) {
      // Coerce the given type to a generic type.
      //
      File f = new File( this );
      f.setType( type );

      // Check if the generic type is valid.
      //
      return isValidGenericType( f.getType() );
   }
}

لا يوجد رمز آخر في النظام سوف يكسر عند File تنقل الفئة البروتوكول الضمني من أنواع محددة (على سبيل المثال، JPEG) إلى أنواع عامة (على سبيل المثال، الصورة). يجب أن يستخدم كل الكود في النظام isValidType الطريقة، التي لا تعطي النوع إلى كائن الدعوة، ولكن يقول ال File فئة للتحقق من صحة نوع.

Answer 4

هذه الفكرة هي أنه إذا استدعاء فئات العميل الخاصة بك وظائف الحصول على / تعيين، فيمكنك تغيير ما يفعلونه لاحقا ومعزول المتصلين. إذا كان لديك متغير عام، فأنا أمتلكها مباشرة، لا توجد وسيلة لك لإضافة السلوك في وقت لاحق عند الوصول إليها أو تعيينها.

حتى في مثالك البسيط، يمكنك الاستفادة من ذلك.

بدلا من استخدام:

milesPerGallon = miles / gallons;

في Calculatemileage ()

يمكنك تغيير SetMiles () و SetGallons () لتحديث Whilspergallon عندما تم استدعاؤها. ثم، قم بإزالة SetMilesPergallon () للإشارة إلى أنه خاصية للقراءة فقط.

Answer 5

النقطة المهمة هي أن الفئة يجب ألا تسمح بالوصول المباشر إلى حقولها، لأن هذا أمر خاص بالتنفيذ. قد ترغب في تغيير الفصل لاحقا من أجل استخدام وحدة تخزين بيانات أخرى، ولكن احتفظ بالفصل نفسه بالنسبة ل "مستخدمين"، أو قد ترغب في إنشاء واجهة لا يمكن أن تتضمن الحقول أيضا.

إلقاء نظرة على ويكيبيديا المادة حول هذا الموضوع.

Answer 6

أنها توفر واجهة عامة لفصلك، وبعض قياس التغليف. النظر في كيفية الوصول إلى البيانات العامة دون الحصول على getters و setters.

Mileage m = new Mileage();
m.miles = 5.0;
m.gallons = 10.0;
...

الآن إذا قررت أنك تريد إضافة بعض التحقق من الصحة إلى صفك، فعليك تغيير التعليمات البرمجية الخاصة بك في كل مكان تم الوصول إليه مباشرة. إذا كنت تستخدم مجرد Jetters و Setters من البداية (فقط حيث هناك حاجة إليها) يمكنك تجنب هذا الجهد، وتغيير التعليمات البرمجية فقط في مكان واحد.

Answer 7

يعطيك استخدام Getters و Setters المرونة لتغيير التنفيذ لاحقا. قد لا تعتقد أنك بحاجة إلى ذلك، لكن في بعض الأحيان تقوم بذلك. على سبيل المثال، قد ترغب في استخدام نمط الوكيل للحمل كسول كائن مكلف لاستخدامه:

class ExpensiveObject {
    private int foo;

    public ExpensiveObject() {
       // Does something that takes a long time.
    }

    public int getFoo() { return foo; }
    public void setFoo(int i) { foo = i; }
}

class ExpensiveObjectProxy extends ExpensiveObject {
    private ExpensiveObject realObject;

    public ExpensiveObjectProxy() { ; }

    protected void Load() {
       if ( realObject == null ) realObject = new ExpensiveObject();
    }

    public int getFoo() { Load(); return realObject.getFoo(); }
    public void setFoo(int i) { Load(); realObject.setFoo(i); }
}

class Main {
    public static void main( string[] args ) {
         // This takes no time, since ExpensiveOjbect is not constructed yet.
         ExpensiveObject myObj = new ExpensiveObjectProxy();

         // ExpensiveObject is actually constructed here, when you first use it.
         int i = myObj.getFoo();
    }
}

حيث يأتي هذا في كثير من الأحيان للعب هو عندما يكون لديك كائنات تم تعيينها إلى قواعد البيانات من خلال Orm. يمكنك تحميل الأشياء التي تحتاجها فقط، ثم العودة إلى قاعدة البيانات لتحميل الباقي إذا كان / عندما يتم استخدامه بالفعل.

Answer 8

في المقامين العامين والآجيلة كانت اختراقا سيئا من قبل بناة واجهة المستخدم الرسومية المبكرة (Borland) للتحصل حول حقيقة أن جميع المتغيرات يجب أن تكون خاصة (حقا، هذا أمر ضروري للغاية)

بعض الناس يسمونهم تجريد، لكنهم ليسوا كذلك. جهاز مرجوم / Getter ليس أفضل من أحد الأطراف العامة. ما زالوا يسمحون بالوصول الكامل إلى المتغير في بعض الأحيان لا يمكن للفئة التحكم ولا يزال يقيد التغييرات في الفئة (إذا كان المتغير الخاص بك هو int، فلا يزال يتعين عليك تغيير كل شيء يستدعي STERTER و Getter لتغيير المتغير إلى سلسلة في

يتم تشجيع Getters و Setters الوصول إلى بيانات الفصل من خارج الفصل. ربما يكون هناك أي رمز يصل إلى عضو في الفصل موجودا داخل تلك الفئة (كدول تصميمك) وبالتالي يجب ألا يحتاج إلى العتاق أو الحصول على Getters. يجب أن تكون غير ضرورية.

كما أجبر وضعف على جميع فصوصك فظيعة، فهذا يعني أن فصولك لا يمكن أن تكون ثابتة في حين يجب أن يكون لديك بالفعل سبب وجيه حقا لجعل قابلة للتغيير قابلة للتغيير.

ومع ذلك، فهي مفيدة من المفيد للمخاوف الشاملة مثل محركات الاستباب ومقناة واجهة المستخدم الرسومية حيث يمكنهم الحصول عليها وتعيين القيم ويمكن للفئة مراقبة ما حصل أو تغييره أو تعديله أو التحقق منه.

سيكون نمط أفضل بالنسبة لتلك الأنظمة التي تحتاج إلى الوصول المتغير الشامل للمتغير هي الوصول إلى المتغير مباشرة من خلال التفكير ولكن لاستدعاء STERTER أو Getter إذا كان أحد موجود - جعل STERTER و Getter خاص إذا كان ذلك ممكنا.

هذا من شأنه أن يسمح لكي تعامل الشفرة الشاملة لعمل OO بشكل صحيح، وستسمح لفصولك بتعديل مجموعات ويحصل عندما يحتاج إليها والسماح للمحترنين (والتي هي في بعض الأحيان مفيدة حقا) عند الضرورة.

Answer 9

نقطة طرق الملحقات أي. Getters و Setters هو توفير مختبئ المعلومات المغلقة AKA. إنها واحدة من المبادئ الأساسية للبرمجة الموجهة للكائنات.

طرق الملحقات

معلومات إخفاء / تغليف

Answer 10

الجواب في كلمة واحدة هو واجهات.

تسمح الواجهات بالأساليب، وليس الحقول، لذا فإن الاتفاقية المنشأة هي الحصول على طرق GetX و SetX لهذا الغرض.

(والواجهات هي الطريقة لفك ضغط وظيفة من التنفيذ في جافا)

Answer 11

مثالك متطرف إلى نقطة العبثية. نعم، كل هؤلاء اللاعبين والتعاليب ينفطون الرمز وإضافة قيمة في هذه الحالة. لكن الفكرة الأساسية للمغولات مخصصة للأنظمة الأكبر تتكون من العديد من مكونات التفاعل، وليس للبرامج الصغيرة والمتاحة ذاتيا.

خصائص الاستخدامات المفيدة والمعقولة من getters و setters:

• فئة تستخدمها العديد من الفئات الأخرى (إخفاء تفاصيل التنفيذ تجعل الأمر أسهل للعملاء)
• getters و setters فقط بالنسبة للحقول التي يحتاجون إليها بالفعل - كعنا من ذلك قدر الإمكان، يجب أن تكون معظم الحقول خاصة واستخدامها فقط داخل صفها
• عدد قليل جدا من الفضلات بشكل عام: حقول قابلة للتغيير تجعل الأمر أكثر صعوبة في تتبع حالة البرنامج من الحقول للقراءة فقط
• getters و setters التي في الواقع فعل شيء إلى جانب الوصول إلى Fied، على سبيل المثال، قم بالرسائل التي ترمي استثناءات لقيم غير صالحة أو تحديث "آخر تعديل"، أو Getter يحسب قيمة على ذبابة بدلا من الاعتماد على مجال أساسي

Answer 12

سريع إلى الأمام بضعة أشهر. ربما يطلب منك معلمك أن تنفذ نسخة عن بعد من فئة الميلاج. ربما كخدمة ويب، ربما شيء آخر.

بدون Getter / Setter، يجب عليك تغيير كل رمز في كل مكان يقوم بتدوير الميل، مع وجود Getter / Studers لك إلى حد كبير (في عالم مثالي على الأقل) يجب أن يغير إنشاء نوع MiLAGE.

Answer 13

تسمح لك Getters و Setters ببناء اختصارات مفيدة للوصول إلى بيانات وتحسينها داخل كائن. بشكل عام، يمكن اعتبار ذلك كبديل له وظيفتين مع كائن يستخدم للحصول على قيمة، مثل ذلك:

{
    getValue: function(){
        return this._value;
    },
    setValue: function(val){
        this._value = val;
    }
}

الميزة الواضحة لكتابة JavaScript بهذه الطريقة هي أنه يمكنك استخدام قيم غامضة لا تريد الوصول إلى المستخدم مباشرة. النتيجة النهائية تبحث عن شيء مثل ما يلي (باستخدام إغلاق لتخزين قيمة الحقل الذي تم إنشاؤه حديثا):

function Field(val){
    var value = val;

    this.getValue = function(){
        return value;
    };

    this.setValue = function(val){
        value = val;
    };
}

إضافة طرق SETTER و Getter لجعل حالة الفاصوليا المدارة يمكن الوصول إليها، تحتاج إلى إضافة طرق Stred و Getter لهذه الحالة. تستدعي طريقة CreatesSalitation طريقة Bean'sgreet، وسترجع طريقة Getalitation النتيجة. بمجرد إضافة أساليب Studter و Getter، اكتمال الفول. يبدو الكود الأخير مثل هذا: تحيات الحزمة؛

import javax.inject.Inject;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;

@Named
@RequestScoped
public class Printer {

    @Inject @Informal Greeting greeting;

    private String name;
    private String salutation;

    public void createSalutation() {
        this.salutation = greeting.greet(name);
    }

    public String getSalutation() {
        return salutation;
    }
    public String setName(String name) {
       this.name = name;
    }

    public String getName() {
       return name;
    }
}

Answer 14

التغليف و رمز إعادة استخدام التعليمات هو جمال البرمجة الموجهة للكائنات. إذا كنا نتعامل مع بعض البيانات الحساسة في التعليمات البرمجية لدينا، فنحن نعلن أنه حقول بيانات خاصة، أي أننا نقوم بتغليف بياناتنا حتى لا يمكن لأحد الوصول إليه مباشرة. يجب على أي شخص يريد الوصول إلى حقول البيانات هذه يجب الاستفادة من setters و getters أي آلية الوصول التي تسيطر عليها للتعامل مع حقول البيانات الحساسة. المثال التالي يمكن أن يكون مفيدا في فهم ميزة وأهمية STERTER و Getters.

• لقد قمت بتنفيذ فئة أقوم فيها باستخدام الأيام المتغيرة.
• في صفي، لا يمكن لأحد تعيين قيمة الأيام أكثر من 365.
• يريد بعض المرء أن يرث من صفي. (رمز إعادة الاستخدام).
• الآن عندما يدخل قيمة الأيام التي يزيد عن 365، فستفشل جميع وظائف صفي.
• وبالتالي، كان يجب أن أعلنت متغير الأيام كحقل بيانات خاص.
• الآن إذا كنت قد أعلنت حقل بيانات Days كخاصة، فلا يمكن لأحد أن يضع قيمة الأيام أكثر من 365 عاما حيث كنت قد قمت بتنفيذ وظائف SETTER مع القيود المذكورة حول المدخلات.