سؤال

هو تماما ضد جافا طريقة لإنشاء البنية مثل الأجسام ؟

class SomeData1 {
    public int x;
    public int y;
}

أستطيع أن أرى فئة مع accessors و mutators أكثر جافا مثل.

class SomeData2 {
    int getX();
    void setX(int x);

    int getY();
    void setY(int y);

    private int x;
    private int y;
}

فئة من المثال الأول هو notationally مريحة.

// a function in a class
public int f(SomeData1 d) {
    return (3 * d.x) / d.y;
}

هذه ليست مريحة.

// a function in a class
public int f(SomeData2 d) {
    return (3 * d.getX()) / d.getY();
}
هل كانت مفيدة؟

المحلول

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

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

public property String foo;   
a->Foo = b->Foo;

تحديث:فإنه من المستبعد جدا أن العقار سيتم إضافة الدعم في جافا 7 أو ربما من أي وقت مضى.أخرى JVM لغات مثل رائع ، سكالا ، الخ لا تدعم هذه الميزة الآن.- أليكس ميلر

نصائح أخرى

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

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

كود جافا الاتفاقيات من عام 1999 و لا تزال دون تغيير.

10.1 توفير الوصول إلى مثيل فئة المتغيرات

لا تجعل أي حال أو فئة متغير العامة من دون سبب وجيه.في كثير من الأحيان ، المتغيرات سبيل المثال لا تحتاج إلى أن يكون صراحة أو حصلت-في كثير من الأحيان أن يحدث كأثر جانبي من طريقة المكالمات.

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

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#177

http://en.wikipedia.org/wiki/Plain_old_data_structure

http://docs.oracle.com/javase/1.3/docs/guide/collections/designfaq.html#28

استخدام الحس السليم حقا.إذا كان لديك شيء من هذا القبيل:

public class ScreenCoord2D{
    public int x;
    public int y;
}

ثم هناك نقطة صغيرة في التفاف عليها في حاصل على واضعي.لن متجر x, y تنسيق في كل بكسل بأي طريقة أخرى.حاصل على واضعي إلا كنت بطيئا.

من ناحية أخرى ، مع:

public class BankAccount{
    public int balance;
}

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

أنها دائما الأفضل أن تعرف لماذا أنت تطبيق الممارسة الجيدة, حتى يتسنى لك معرفة عندما لا بأس أن ينحني القواعد.

لمعالجة التحولية المخاوف يمكنك أن يعلن x و y النهائية.على سبيل المثال:

class Data {
  public final int x;
  public final int y;
  public Data( int x, int y){
    this.x = x;
    this.y = y;
  }
}

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

رمز العميل ثم يمكن أن يكون 'قصيرة من ناحية الراحة التي وصفتها في رسالتك

public class DataTest {
    public DataTest() {
        Data data1 = new Data(1, 5);
        Data data2 = new Data(2, 4);
        System.out.println(f(data1));
        System.out.println(f(data2));
    }

    public int f(Data d) {
        return (3 * d.x) / d.y;
    }

    public static void main(String[] args) {
        DataTest dataTest = new DataTest();
    }
}

لا تستخدم public الحقول

لا تستخدم public الحقول عندما كنت تريد حقا أن التفاف الداخلية سلوك فئة.تأخذ java.io.BufferedReader على سبيل المثال.أنه يحتوي على الحقول التالية:

private boolean skipLF = false; // If the next character is a line feed, skip it

skipLF هو قراءة وكتابة في كل قراءة الأساليب.ما إذا كانت الطبقة الخارجية التي تعمل في موضوع مستقل تم تعديله بشكل ضار دولة skipLF في منتصف القراءة ؟ BufferedReader سوف تذهب بالتأكيد أحمق.

لا تستخدم public الحقول

خذ هذا Point الدرجة على سبيل المثال:

class Point {
    private double x;
    private double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }

    public double getX() {
        return this.x;
    }

    public double getY() {
        return this.y;
    }

    public void setX(double x) {
        this.x = x;
    }

    public void setY(double y) {
        this.y = y;
    }
}

وهذا من شأنه أن يجعل حساب المسافة بين نقطتين مؤلمة جدا في الكتابة.

Point a = new Point(5.0, 4.0);
Point b = new Point(4.0, 9.0);
double distance = Math.sqrt(Math.pow(b.getX() - a.getX(), 2) + Math.pow(b.getY() - a.getY(), 2));

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

class Point {
    public double x;
    public double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }
}

Point a = new Point(5.0, 4.0);
Point b = new Point(4.0, 9.0);
double distance = Math.sqrt(Math.pow(b.x - a.x, 2) + Math.pow(b.y - a.y, 2));

نظيفة!

ولكن تذكر:ليس فقط الفئة يجب أن تكون غائبة من السلوك ، ولكن يجب أن يكون أيضا لا سبب السلوك في المستقبل أيضا.


(هذا هو بالضبط ما هذا الجواب يصف.اقتباس "رمز اتفاقيات لغة البرمجة جافا:10.أساليب البرمجة":

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

لذا الوثائق الرسمية كما تقبل هذه الممارسة.)


أيضا, إذا كنت إضافية على يقين أن أعضاء أعلاه Point فئة يجب أن تكون ثابتة ، ثم هل يمكن إضافة final الكلمات الرئيسية لفرض الأمر:

public final double x;
public final double y;

بالمناسبة يا بنية أنت تعطي مثالا موجودة بالفعل في جافا مكتبة الفئة الأساسية كما java.awt.Point.وقد x و y العام المجالات ، التحقق من ذلك لنفسك.

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

Re:أكو, izb جون Topley...

احترس من التحولية القضايا...

قد يبدو من المعقول أن تغفل حاصل/المحددات.فإنه في الواقع قد يكون حسنا في بعض الحالات.المشكلة الحقيقية مع المقترح نمط يظهر هنا التحولية.

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

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

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

انظر:"فعالة جافا"من قبل يشوع بلوخ -- البند رقم 13:صالح ثبات.

PS:كما نضع في اعتبارنا كل JVMs هذه الأيام سوف تحسين بعيدا وطن إذا كان ذلك ممكنا ، مما أدى إلى مجرد حقل واحد-قراءة التعليمات.

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

كما ذكر آخرون أعلاه, هناك 2 المشاكل التي واجهت و هم في الحقيقة لا يمكن حلها:

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

و هذا هو أفضل سيناريو العمل تماما في خاص بذاته المشروع.بمجرد تصدير كل شيء المشار إليها في مكتبة هذه المشاكل سوف تصبح أكبر.

جافا جدا مطول, و هذا هو المغري شيء للقيام به.لا تفعل ذلك.

إذا كان جافا طريقة OO طريقة, ثم نعم, خلق فئة مع الجمهور المجالات فواصل مبادئ حول إخفاء المعلومات التي تقول أن كائن أن إدارة الداخلية الخاصة به الدولة.(حتى أنا ليس فقط تنفث المصطلحات في فائدة من إخفاء المعلومات هو أن الأعمال الداخلية من فئة مخفية وراء واجهة - يقول أردت تغيير الآلية التي struct الدرجة أنقذ واحد من المجالات ، ربما ستحتاج إلى العودة وتغيير أي الطبقات التي تستخدم الطبقة...)

يمكنك أيضا الاستفادة من دعم التخطيط الاستراتيجي المشترك javabean تسمية متوافقة مع الطبقات التي سوف يضر إذا كنت ترغب في, قول, استخدام فئة في خادم جافا الصفحة التي كتبت باستخدام لغة التعبير.

على JavaWorld المادة لماذا جالبة واضع طرق الشر المادة أيضا قد يكون من مصلحة لكم في التفكير عند عدم تنفيذ accessor و mutator الأساليب.

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

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

المشكلة مع استخدام الجمهور الوصول الميداني هو نفس مشكلة جديدة بدلا من طريقة مصنع - إذا غيرت رأيك في القائمة المتصلين مكسورة.لذا من API تطور وجهة نظر, انها عادة ما تكون فكرة جيدة أن لدغة الرصاصة واستخدام حاصل/المحددات.

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

بالمناسبة على e-بارتك تأكيد, فمن غير المرجح أن المنظمة البحرية الدولية أن العقار سيتم إضافة الدعم في جافا 7.

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

بوصفها جانبا, حتى لو كنت أكتب هذا الكائن الخاص الطبقة الداخلية وأود أن لا تزال توفر منشئ لتبسيط رمز تهيئة الكائن.وجود 3 خطوط من التعليمات البرمجية للحصول على كائن قابل للاستخدام عند واحد سوف تفعله هو مجرد فوضى.

جدا جدا السؤال القديم, ولكن اسمحوا لي أن جعل آخر مساهمة قصيرة.جافا 8 قدم امدا التعبير وطريقة المراجع.امدا التعبيرات يمكن أن تكون طريقة بسيطة المراجع لم تعلن "صحيح" الجسم.ولكن لا يمكن "تحويل" حقل في طريقة المرجعية.وهكذا

stream.mapToInt(SomeData1::x)

ليس قانونيا ،

stream.mapToInt(SomeData2::getX)

هو.

أنا لا أرى ضررا في ذلك إذا كنت تعرف أنه دائما ما تكون بسيطة البنية و أنك لن ترغب في إرفاق السلوك إلى ذلك.

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

أنا هنا إنشاء برنامج لإدخال اسم سن من 5 أشخاص مختلفين وإجراء اختيار نوع (سن الحكمة).اعتدت الدرجة التي تكون بمثابة الهيكل (مثل لغة البرمجة C) و الرئيسي الصف لأداء العملية كاملة.فيما يلي أنا تأثيث رمز...

import java.io.*;

class NameList {
    String name;
    int age;
}

class StructNameAge {
    public static void main(String [] args) throws IOException {

        NameList nl[]=new NameList[5]; // Create new radix of the structure NameList into 'nl' object
        NameList temp=new NameList(); // Create a temporary object of the structure

        BufferedReader br=new BufferedReader(new InputStreamReader(System.in));

        /* Enter data into each radix of 'nl' object */

        for(int i=0; i<5; i++) {
            nl[i]=new NameList(); // Assign the structure into each radix

            System.out.print("Name: ");
            nl[i].name=br.readLine();

            System.out.print("Age: ");
            nl[i].age=Integer.parseInt(br.readLine());

            System.out.println();
        }

        /* Perform the sort (Selection Sort Method) */

        for(int i=0; i<4; i++) {
            for(int j=i+1; j<5; j++) {
                if(nl[i].age>nl[j].age) {
                    temp=nl[i];
                    nl[i]=nl[j];
                    nl[j]=temp;
                }
            }
        }

        /* Print each radix stored in 'nl' object */

        for(int i=0; i<5; i++)
            System.out.println(nl[i].name+" ("+nl[i].age+")");
    }
}

رمز أعلاه هو خالية من اختبار...مجرد نسخ ولصق في IDE و ...أنت تعرف ماذا ؟ ؟ ؟ :)

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

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

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

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

وبالتالي يمكنك بدء تشغيل مع unintercepted المجالات مع الحق في الوصول إلى التصفيات.كما متطلبات البرنامج تنمو إرفاق المنطق ربما التحقق من صحة, إنشاء نسخة من الكائن الذي عاد ، إلخ.

فإن حاصل/واضع فلسفة يفرض تكاليف على عدد كبير من الحالات البسيطة حيث لا تكون هناك حاجة إليها.

سواء الجانب نمط نظافة أو لا إلى حد ما النوعي.سوف تجد أنه من السهل أن نرى فقط المتغيرات في فئة عرض المنطق بشكل منفصل.في الواقع ، فإن المبرر على Apect المنحى البرمجة هو أن العديد من الشواغل الشاملة و حصرها في الجسم الفئة نفسها ليست مثالية (تسجيل مثالا على ذلك -- إذا كنت تريد تسجيل كل ما يحصل جافا يريد منك أن تكتب مجموعة كاملة من حاصل والاحتفاظ بها في المزامنة ولكن AspectJ يسمح لك بطانة واحدة).

مسألة IDE هو الأحمر-الرنجة.ليس كثيرا على الكتابة كما هو القراءة و التلوث البصري الذي يطرح نفسه من الحصول على/مجموعات.

الشروح تبدو مشابهة إلى جانب المنحى البرمجة لأول وهلة إلا أنها تتطلب منك باستفاضة تعداد pointcuts طريق ربط الشروح ، مقابل موجزة بطاقة البرية-مثل pointcut مواصفات في AspectJ.

أتمنى الوعي AspectJ يمنع الناس من قبل الأوان يستقر على اللغات الديناميكية.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top