سؤال

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

أحاول أن أفهم مفهوم التغليف.ما فكرت به هو إذا ذهبت من شيء مثل هذا:

ن = ن + 1

والتي يتم تنفيذها في البرية كجزء من مجموعة كبيرة من التعليمات البرمجية ثم آخذها وأضعها في وظيفة مثل هذه، ثم قمت بتغليف منطق الإضافة هذا في طريقة:

addOne(n)
    n = n + 1
    return n

أم أن الأمر يتعلق بالتغليف فقط إذا كنت أقوم بإخفاء تفاصيل addOne عن العالم الخارجي - كما لو كانت طريقة كائن وأستخدم معدّل وصول خاص/محمي؟

هل كانت مفيدة؟

المحلول

ربما تخلط بين التجريد والتغليف، والذي يُفهم في السياق الأوسع لتوجيه الكائن.

يتضمن التغليف بشكل صحيح العناصر الثلاثة التالية:

  • التجريد
  • إخفاء التنفيذ
  • تقسيم المسؤولية

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

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

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

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

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

نصائح أخرى

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

مايرز جدا.

وبالتأكيد هو عليه.

وعلى سبيل المثال، وهي طريقة تعمل فقط على معالمها سيعتبر "أفضل مغلفة" من الطريقة التي تعمل على بيانات ثابتة العالمية.

تم تغليف حول يمض وقت طويل قبل OOP:)

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

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

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

لا، الأشياء ليست <م> مطلوب لتغليف. في أوسع معانيه، "التغليف" تعني فقط "إخفاء تفاصيل عن الأنظار" و في هذا الصدد طريقة والتغليف تفاصيل تنفيذها.

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

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

<القوي> تحديث:. للإجابة على سؤالك المحدثة، على حد سواء "وضع التعليمات البرمجية في أسلوب" و "باستخدام معدل وصول" طرق مختلفة لتغليف المنطق، ولكن كل واحد أعمال على مستوى مختلف

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

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

وانه شيء على مستوى العنصر

هذا من:

<اقتباس فقرة>   

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

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

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

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

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

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

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

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

والتغليف هو العملية التي سمات (عضو البيانات) والسلوك (وظيفة عضو) من الكائنات في مجتمعة معا كما تشير كيان واحد من الطبقة.

النموذج المرجعي للمعالجة الموزعة المفتوحة - الذي كتبته المنظمة الدولية للتوحيد القياسي - يحدد المفاهيم التالية:

كيان:أي شيء ملموس أو مجرد من الاهتمام.

هدف:نموذج للكيان.يتميز الكائن بسلوكه، وبشكل مزدوج، بحالته.

السلوك (للكائن):مجموعة من الإجراءات مع مجموعة من القيود المتعلقة بوقت حدوثها.

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

التغليف:خاصية أن المعلومات الموجودة في كائن ما لا يمكن الوصول إليها إلا من خلال التفاعلات في الواجهات التي يدعمها الكائن.

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

أولاً، من الواضح أن الوظيفة هي نموذج لـ "الشيء محل الاهتمام"، حيث إنها تمثل خوارزمية ترغب (على الأرجح) في تنفيذها وتتعلق تلك الخوارزمية ببعض المشكلات التي تحاول حلها (وبالتالي فهي نموذج لها) .

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

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

هل تمتلك الوظيفة خاصية أن المعلومات الموجودة في الوظيفة لا يمكن الوصول إليها إلا من خلال التفاعلات في الواجهات التي يدعمها الكائن؟حسنًا، يمكن ذلك.

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

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

من السهل أيضًا الادعاء بأن الوظائف (أو الأساليب) نفسها مغلفة داخل الفئات.مرة أخرى، ستكون بعض الوظائف عامة (وبالتالي ستكون جزءًا من واجهة الفصل) وبعضها سيكون خاصًا (وبالتالي المعلومات مخفية داخل الفصل).يسمى الرسم البياني للوظائف والفئات بالرسم البياني الثاني.

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

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

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

إذا أخذنا هذه التعريفات (ربما الضعيفة بعض الشيء)، فيمكننا أن نقول نعم:إن وضع الوظيفة داخل الوظيفة يشكل تغليفًا.تغليف الكتل داخل الوظائف هو الرسم البياني الأول.

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

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

كل هذا بالطبع أكاديمي ما لم تتمكن من إثبات فائدة مثل هذا التغليف.

هناك قوتان تحفزان التغليف:الدلالية والمنطقية.

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

الدافع الآخر للتغليف هو المنطق.

تكوين النظام هو التحديد الدقيق والشامل لكل عقدة من النظام والمنطقة المغلفة التي توجد فيها؛تكوين معين لنظام Java - في الرسم البياني الثالث - هو تحديد جميع فئات النظام وتحديد الحزمة التي توجد بها كل فئة.

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

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

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

بالنظر إلى فئات n ومتطلبات الفئات العامة p لكل حزمة، توضح نظرية التغليف أن عدد الحزم، r، الذي يجب علينا تقليل MPE يتم الحصول عليه من خلال المعادلة:ص = جذر (ن / ع).

ينطبق هذا أيضًا على عدد الوظائف التي يجب أن تكون لديك، نظرًا للعدد الإجمالي، n، لكتل ​​McCabian في نظامك.تحتوي الوظائف دائمًا على كتلة عامة واحدة فقط، كما ذكرنا أعلاه، وبالتالي يتم تبسيط معادلة عدد الوظائف، r، الموجودة في نظامك إلى:ص = جذر (ن).

من المسلم به أن القليل منهم أخذوا في الاعتبار العدد الإجمالي للكتل في نظامهم عند ممارسة التغليف، ولكن يتم ذلك بسهولة على مستوى الفئة/الحزمة.علاوة على ذلك، فإن تقليل MPE هو أمر بديهي تمامًا تقريبًا:يتم ذلك عن طريق تقليل عدد الفئات العامة ومحاولة توزيع الفئات بشكل موحد على الحزم (أو على الأقل تجنب امتلاك معظم الحزم، على سبيل المثال، 30 فئة، وحزمة وحش واحدة تحتوي على 500 فئة، وفي هذه الحالة يمكن لـ MPE الداخلي للأخيرة تطغى بسهولة على MPE لجميع الآخرين).

وبالتالي فإن التغليف ينطوي على تحقيق التوازن بين الدلالي والمنطقي.

كل متعة عظيمة.

وفي المصطلحات صارم وجوه المنحى، يمكن للمرء أن يميل ليقول لا، و"مجرد" وظيفة ليست قوية بما فيه الكفاية ليتم استدعاؤها التغليف ... ولكن <لأ href = "http://www.google.com/ بحث HL = EN & defl = أون وف = تعريف:. التغليف والصناعات الاستخراجية = ioi5Sur_LZSJtgellJ24BA وسا = X & منظمة اوكسفام الدولية = glossary_definition وط = عنوان "يختلط =" نوفولو noreferrer "> في العالم الحقيقي الجواب واضح هو" نعم، وهي وظيفة بتغليف بعض التعليمات البرمجية "

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

وولمجرد أن يكون متحذلق، التغليف هو شكل من أشكال التجريد، وليس العكس. ؛ -)

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

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

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