جيتر / سيترز. شر. والفترة

مقال بقلم إيجور بوجاينكو 19 سبتمبر 2014 | تم النشر في: Core Java بدأ هذا النقاش القديم بواسطة ألين هولوب في مقالته الشهيرة، في عام 2003، لماذا تعد طرق getter و setter شريرة - هل الحروف/setters مضادة للنمط ويجب علينا تجنبها، أم أنها شيء نحن' لا بد أن يكون هناك حاجة إليها في البرمجة الموجهة للكائنات. سأضيف سنتي إلى هذه المناقشة. جوهر النص أدناه هو أن الحروف والأدوات هي ممارسات سيئة، وليس لدى أولئك الذين يستخدمونها أي عذر. ولكن مرة أخرى، لتجنب سوء الفهم، أنا لا أقترح على الإطلاق تجنب استخدام get/set حيثما أمكن ذلك. لا. أنا أقول أنك لم تسمح لهم حتى بالاقتراب من الكود الخاص بك . ما رأيك في هذا البيان؟ يستحق اهتمامك؟ هل كنت تستخدم نمط get/set لمدة 15 عامًا وهل أنت مهندس Java محترم؟ وأنت لا تريد حتى الاستماع إلى هذا الهراء من شخص غريب؟ حسنا... أنا أفهم مشاعرك. لقد شعرت بنفس الشعور حتى عثرت على كتاب ديفيد ويست "التفكير الشيئي" - وهو أفضل كتاب قرأته عن البرمجة الشيئية على الإطلاق. إذن أرجوك. اهدأ وحاول أن تفهم ما أحاول شرحه. موضوع الجدل هناك عدة حجج ضد "الوصولات" (اسم آخر للحروف والأدوات) في العالم الموجه للكائنات. وكلها حجج صحيحة للغاية. دعونا نلقي نظرة سريعة عليهم. اسأل، لا تخبر : يقول ألين هولوب، "لا تسأل عن المعلومات التي تحتاجها للقيام بعمل ما؛ "اطلب" من الكيان الذي لديه تلك المعلومات أن يقوم بالمهمة نيابةً عنك." مبدأ التغليف المنتهك : يمكن تفكيك الكائن بواسطة كائنات أخرى لأنها قادرة على تضمين أي بيانات في الكائن، من خلال أدوات الضبط. لا يمكن للكائن ببساطة تغليف حالته بشكل آمن بما فيه الكفاية لأنه يمكن لأي شخص تغيير تلك الحالة. تم الكشف عن تفاصيل التنفيذ : إذا كان بإمكانك الحصول على كائن واحد من كائن آخر، فإننا نعتمد كثيرًا على تفاصيل تنفيذ الكائن الأول. إذا تغير غدًا (على سبيل المثال، نوع النتيجة)، فسيتعين علينا تغيير الرمز. من المؤكد أن جميع المبررات المذكورة أعلاه منطقية، لكن هذا يغفل النقطة الأكثر أهمية. المفهوم الخاطئ الأساسي يعتقد معظم المبرمجين أن الكائن عبارة عن بنية بيانات لها طرق. أقتبس مقال بوزيدار بوزانوف: Getters and Setters ليسوا أشرارًا. لكن معظم الكائنات التي يتم إنشاء الحروف والمحددات لها تحتوي ببساطة على بيانات. هذا الفهم الخاطئ هو نتيجة لسوء فهم كبير! الكائنات لا "تخزن البيانات فقط". الكائنات ليست هياكل بيانات مع الأساليب المرفقة. مفهوم "تخزين البيانات" جاء من البرمجة الشيئية واللغات الإجرائية، وخاصة C وCOBOL. سأكرر مرة أخرى: الكائن ليس مجرد مجموعة من عناصر البيانات والوظائف التي تتلاعب بها. الكائن ليس كائن بيانات. ماذا بعد؟ الكرة والكلب في البرمجة الشيئية الحقيقية، الكائنات هي كائنات حية، مثلي ومثلك تمامًا. إنها كائنات حية لها سلوكها وخصائصها ودورة حياتها. هل يمكن للكائن الحي أن يكون له واضع؟ هل يمكنك إرفاق ("ضبط") كرة بكلب؟ لا تفكر. ولكن هذا هو بالضبط ما يفعله جزء التعليمات البرمجية أدناه:

Dog dog = new Dog();
dog.setBall(new Ball());

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

Dog dog = new Dog();
Ball ball = dog.getBall();

أو مثال أكثر سخافة:

Dog dog = new Dog();
dog.setWeight("23kg");

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

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

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

Dog dog = new Dog("23kg");
int weight = dog.weight();

الكلب هو كائن حي غير قابل للتغيير ولن يسمح لأي شخص بالخارج بتغيير وزنه أو حجمه أو اسمه وما إلى ذلك. يمكنها أن "تخبر"، عند الطلب، وزنها أو اسمها. لا حرج في الأساليب العامة التي تكشف الاستعلامات عن خصائص "داخلية" معينة لكائن ما. لكن هذه التوابع ليست "حروفًا" ولا ينبغي أبدًا أن تتلقى البادئة "get". نحن لا "نخرج" من الكلب. نحن لا نحصل على اسمها. نطلب منها أن تخبرنا باسمها. هل ترى الفرق؟ نحن لا نتحدث حتى عن الدلالات هنا. نحن نفرق بين النهج الإجرائي للبرمجة وبين النهج الشيئي. في البرمجة الإجرائية، نعمل مع البيانات ونعالجها ونحصل عليها ونضبطها ونحذفها إذا لزم الأمر. نحن المسؤولون، والبيانات هي مجرد عنصر سلبي. الكلب لا يمثل شيئًا بالنسبة لنا، فهو ببساطة "يحتوي على بيانات". ليس لديها حياتها الخاصة. يمكننا الحصول بحرية على كل ما نحتاجه منه ووضع (تعيين) أي بيانات فيه. هذه هي الطريقة التي تعمل بها (تعمل) لغات C وCOBOL وPascal وغيرها من اللغات الإجرائية. والوضع معاكس تمامًا في العالم الموجه للكائنات. نحن هنا نتعامل مع الأشياء ككائنات حية، لها تاريخ ميلادها ولحظة وفاتها، ولها شخصيتها وعاداتها، إذا أردت. يمكننا أن نطلب من الكلب أن يعطينا جزءًا من البيانات (على سبيل المثال، وزنه) ويمكنه إرجاع المعلومات إلينا. لكن تذكر دائمًا أن الكلب هو العنصر النشط. إنها تقرر ما يحدث بعد الطلب. ولهذا السبب من الخطأ تمامًا أن تبدأ أساليب الكائن بـ set أو get. وهذا لا يتعلق حتى بانتهاك التغليف، كما يعتقد الكثير من الناس. يتعلق الأمر بحقيقة أنك إما تفكر ككائن أو أنك لا تزال تكتب COBOL باستخدام بناء جملة Java. ملاحظة . ونعم، قد تسأل: "ماذا عن JavaBeans وJPA وJAXB والعديد من واجهات برمجة تطبيقات Java الأخرى التي تعتمد على get/set؟" ماذا عن الوظيفة المضمنة في روبي والتي تسهل إنشاء الملحقات؟ حسنًا، ماذا يمكنني أن أقول لك... لم يحالفك الحظ. إن البقاء في عالم COBOL الإجرائي البدائي أسهل بكثير من فهم واحتضان العالم الرائع للأشياء الحقيقية. بي بي اس _ لقد نسيت أن أقول، نعم، إن إدراج التبعيات عبر أداة الضبط يعد أيضًا نمطًا سيئًا مضادًا. ولكن المزيد عن ذلك في المنشور التالي! المقالة الأصلية