قواعد الأعمال - أين يذهبون في OOP؟

Question

لدي فصل: جدول.

public class Schedule {

private int locationNum;
private int cost;
private String costReason; 
private Date weekOfChange;
private Date dayOfChange;
private String changeReason; 

// and all those getters and setters

public Schedule(int locationNum, int cost, String costReason, Date weekOfChange, Date dayOfChange, String changeReason) throws ApplicationException {
//change is all or nothing - all attributes are present or none
if((weekOfChange!=null && dayOfChange!=null && changeReason!=null) || (weekOfChange==null  && dayOfChange == null && changeReason == null))  {
this.weekOfChange = weekOfChange;
this.dayOfChange = dayOfChange;
this.changeReason = changeReason;
}
else { throw new ApplicationException();}
//similary another if block to ensure that if cost is specified 
//then there exists the corresponding reason code for it.
}
}

حتى الآن، أعجبني فئة الجدول الزمني. ومع ذلك، لم أفعل مع الشيكات، أود أن أفعل بعض الشيكات الأخرى:

• هو LocationNum رقم مخزن صالح في قاعدة البيانات.
• هو تطبيق ChangeReason أحد رموز التغييرات المختلفة 6 في قاعدة البيانات.
• الخ إل ....

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

الآن، إليك أسئلتي:

1. إذا كنت تعالج الجدول الزمني كبرنامج POJO وتجادل أن الكائن غير مسؤول عن التحقق من صحة نفسه - ما عليك نقل جميع التعليمات البرمجية في المنشئ إلى فئة Validator Validator في طبقة العمل. ولكن، إذا كنت أقوم بذلك، فلا جدولة وفق وقت الدم؟ هل هذا ما يسميه مخالفة مبدأ المسؤولية الفردية؟
2. دعونا نفترض أنني نقلت التعليمات البرمجية لدي في منشئتي إلى فئة طبقة عمل بحيث تكون جميع أنواع التحقق من الصحة الآن في طبقة Busines الخاصة بي. يتيح لك افتراض أن شخصا ما يتغير Dayofchange إلى NULL في DataStore الخاص بي والآن أحمل الكائنات من قاعدة البيانات الخاصة بي. الآن، مع هذا النوع من الكائن، يمكن تطبيقي كسر، أليس كذلك؟ coz أود أن يكون رمز مكتوب يفترض أن قواعد التحقق من الصحة يتم تلبية. أعتقد أن سؤالي يحصل على مربكة، لكن النقطة التي أحاول القيام بها هي أنه في هذا السياق، أذهب هذه الشيكات في المنشئ لضمان سلامة البيانات المخفية عن طريق جدولة فئة.
3. كيف يتم ذلك عادة؟ ما هو افضل نشاط؟

نقدر تورطك في هذه المناقشة.

Answer 1

إذا كان لديك حقا "كل هذه الأجيوب و Setters "ثم تحتاج إلى التحقق من صحة صفك أفضل مما كانت عليه في المنشئ. إذا كانت هناك نشاطاتك في صفك مثل هذا الاسبوع، يجب أن يكون Dayofchange و ChangeReas NULL أو ليس كل شيء يجب أن لا يغلى أن يقوم STILTERS بسرعة بوضع صفك بسرعة حالة غير صالحة. هل تقصد أن يكون لديك setters أو هل تقصد فصلك أن تكون غير ثابتة؟

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

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

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

لذلك لديك

    class Schedule {
         private Change change;
         private Cost cost;
         private Location location;

        public Schedule(Location location, Cost cost, Change change) {
           this.change = change;
           this.cost = cost;
           this.location = location;
        }
}

و colloborators مثل

public class Change {
    private Date weekOfChange; //shoudln't these two fields be one, a date is a date after all??
    private Date dayOfChange; //shoudln't these two fields be one??
    private String changeReason; 

    public Change(Date weekOfChange Date dayOfChange, String changeReason) {
      this.weekOfChange = weekOfChange;
      ...etc.
    } 
}

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

Answer 2

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

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

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

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

كيف يتم ذلك عادة؟ ما هو افضل نشاط؟

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

جيد الأسباب التي تواجه دروس قاعدة منفصلة ستكون:

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

Answer 3

يبدو أن هناك سلوكتان متميزان ل Schedule البناء. لذلك، يجب أن يكون هناك منتجان. ربما حتى فصول تنفيذ.

locationNum و changeReason. وبعد هذه حاليا مكتوبة ضعيفة. ربما يجب أن يكون لهم صفهم. بعد سؤالك، تعتمد القيم الصالحة على السياق. في اللحظة Schedule ليس لديه أي سياق. يمكنك الاحتفاظ Schedule مستقلة عن السياق، وفي هذه الحالة لا توجد قيود على قاعدة البيانات locationNum و changeReason. وبعد الذهاب في الاتجاه الآخر، Schedule, locationNum و changeReason يمكن أن تعتمد على السياق، وينبغي للموزول فقط التحقق من أنهم جميعا في نفس السياق. منشئ حزمة خاصة (يتصرف كرجل فقير friend) قد يحذف الشيكات.

POJO يعني كائن (مكتوب جيدا) وبالتالي السلوك. يبدو أن السؤال يستخدمه يعني "بنية". تجنب الهياكل.

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

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

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

Answer 4

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

Answer 5

للإجابة على أسئلتكم :

1) لا أعتقد أن صفك سيكون على علم الدماء، فمن الأفضل أن يكون DTO في الوقت الراهن، لا أرى أي مشكلة في هذا.

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