ثابتة الفول في جافا

Question

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

نهج واحد لهذه المشكلة تم ذكرها هنا في ستاكوفيرفلوو يسمى "ثابتة كائن نمط في C#" حيث يتم تجميد الكائن مرة واحدة بنيت بالكامل.لدي بديل النهج أحب أن أسمع آراء الناس على ذلك.

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

على سبيل المثال

public interface DateBean {
    public Date getDate();
    public DateBean getImmutableInstance();
    public DateBean getMutableInstance();
}

public class ImmutableDate implements DateBean {
    private Date date;

ImmutableDate(Date date) {
    this.date = new Date(date.getTime());
}

public Date getDate() {
    return new Date(date.getTime());
}

    public DateBean getImmutableInstance() {
        return this;
    }

    public DateBean getMutableInstance() {
        MutableDate dateBean = new MutableDate();
        dateBean.setDate(getDate());
        return dateBean;
    }
}

public class MutableDate implements DateBean {
    private Date date;

public Date getDate() {
    return date;
}

public void setDate(Date date) {
    this.date = date;
}

public DateBean getImmutableInstance() {
    return new ImmutableDate(this.date);
}

    public DateBean getMutableInstance() {
        MutableDate dateBean = new MutableDate();
        dateBean.setDate(getDate());
        return dateBean;
    }
}

هذا النهج يسمح فول سيتم بناؤها باستخدام التفكير (حسب المعتاد الاتفاقيات) و أيضا يسمح لنا لتحويل ثابتة البديل في أقرب فرصة.للأسف من الواضح أن هناك كمية كبيرة من المتداول في الفول.

أنا مهتم جدا أن نسمع الآخرين تجاه هذه المسألة.(اعتذر عن عدم توفير سؤال جيد ، والتي يمكن أن تكون الإجابة بدلا من مناقشة :)

Answer 1

وأنا أعتقد أن استخدام نمط الوفد - جعل فئة ImmutableDate مع عضو DateBean واحد يجب تحديد في المنشئ:

public class ImmutableDate implements DateBean
{
   private DateBean delegate;

   public ImmutableDate(DateBean d)
   {
      this.delegate = d;
   }

   public Date getDate()
   {
      return delegate.getDate();
   }
}

إذا أي وقت مضى بحاجة إلى قوة ثبات على DateBean د، I ImmutableDate فقط جديدة (د) على ذلك. كان يمكن ان أكون ذكية وتأكدوا أنني لم تفويض مندوب، ولكن تحصل على هذه الفكرة. أن يتجنب قضية عميل يحاول أن يلقي إلى شيء قابلة للتغيير. هذا هو مثل الكثير من JDK الحال مع Collections.unmodifiableMap () الخ (في تلك الحالات، ومع ذلك، وظائف طفرة لا يزال يتعين تنفيذها، ويتم ترميز لرمي استثناء وقت التشغيل. أسهل بكثير إذا كان لديك واجهة الأساسية من دون mutators).

ولكن مرة أخرى أنه هو رمز المتداول مملة ولكن هذا هو النوع من الشيء أن IDE جيد مثل الكسوف يمكن لصناعة السيارات في توليد بالنسبة لك مع مجرد بضع نقرات الماوس.

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

Answer 2

بعض التعليقات (ليس بالضرورة مشاكل):

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

على سبيل المثال

public interface DateBean {
    public Date getDate();
}

public class ImmutableDate implements DateBean {
    private final long date;

    ImmutableDate(long date) {
       this.date = date;
    }

    ImmutableDate(Date date) {
       this(date.getTime());
    }

    ImmutableDate(DateBean bean) {
       this(bean.getDate());
    }

    public Date getDate() {
         return new Date(date);
    }
}


public class MutableDate implements DateBean {
    private long date;

    MutableDate() {}

    MutableDate(long date) {
       this.date = date;
    }

    MutableDate(Date date) {
       this(date.getTime());
    }

    MutableDate(DateBean bean) {
       this(bean.getDate());
    }

    public Date getDate() {
        return new Date(date);
    }

    public void setDate(Date date) {
        this.date = date.getTime();
    }

}

Answer 3

ويمكنني استخدام واجهات والصب للسيطرة على التحولية من الفاصوليا. وأنا لا أرى سببا وجيها لتعقيد الأشياء نطاقي مع أساليب مثل getImmutableInstance() وgetMutableInstance().

لماذا لا مجرد الاستفادة من الإرث والتجريد؟ منها مثلا.

public interface User{

  long getId();

  String getName();

  int getAge();

}

public interface MutableUser extends User{

  void setName(String name);

  void setAge(int age);

}

وإليك ما العميل من قانون سوف تفعل:

public void validateUser(User user){
  if(user.getName() == null) ...
}

public void updateUserAge(MutableUser user, int age){
  user.setAge(age);
}

هل الإجابة عن سؤالك؟

والبطاقة الصفراء