سؤال

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

أين الجود قوة الكذب ؟ في constrast, البرمجة الوظيفية سمات ثراء إلى الأفعال بدلا من الأسماء ، وهكذا كل من التغليف و دلالات يتم توفير أساليب بدلا من هياكل البيانات.

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

أو هو التغليف مفتاح كل قيمة الرمز ؟

تحرير:أقصد على وجه التحديد نوع التغليف OO هنا. changeColor(door,blue) يصبح door.changeColor(blue).

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

المحلول

ويبدو أنك تستخدم تعريفا ضيقا بدلا من "تغليف". هل أكون على صواب في افتراض التي تقوم بتعريف التغليف أن يكون، "الجمع بين البيانات مع الأساليب؟"

إذا كنت مخطئا ثم الرجاء تجاهل بقية هذا المنصب.

وتغليف ليس مصطلح فضفاض. في الواقع، انه يعرف من قبل المنظمة الدولية للتوحيد القياسي. النموذج المرجعي للISO للمعالجة الموزعة المفتوحة - يحدد المفاهيم الخمسة التالية:

والكيان: أي الخرسانة أو الشيء المجرد من الفائدة

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

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

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

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

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

http://www.cs.umd.edu/ الطبقة / spring2003 / cmsc838p / التصميم / criteria.pdf

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

في مشاركتك، يبدو أنك يمكن القول أن الفرق بين التغليف في OO وفي البرمجة الوظيفية ينبع من إدارة البيانات، ولكن على الأقل وفقا لISO وParnas، وإدارة البيانات ليست هي مفتاح التغليف. لذلك أنا لا أرى لماذا التغليف في البرمجة الوظيفية ضرورة أن يكون مختلفا عن ذلك في OO.

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

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

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

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

ومفهوم "اقتران المحتملين،" مفيد هنا.

و"اقتران"، ويعرف نفسه بأنه "مقياس لقوة الرابطة التي وضعتها اتصال من وحدة واحدة إلى أخرى،" في بلد آخر ورقات كبيرة الحوسبة و:

http://www.research.ibm.com/journal/ SJ / 382 / stevens.pdf

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

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

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

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

وجاء في شكل قوي أن عبء تحويل مجموعة من الكيانات هي وظيفة من عدد من الكيانات تحويلها. ويشير الشكل الضعيف أن عبء الحد الأقصى المحتمل لتحويل مجموعة من الكيانات هي وظيفة من أقصى العدد المحتمل للكيانات تحويلها.

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

والعبء المحتمل أقصى درجة المعدلة يمكن أن يفرض هو صدم من جميع الفئات التي تعتمد عليها.

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

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

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

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

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

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

وهناك قوة كبيرة بالفعل في هذه دلالات.

ما هو الغريب بالنسبة لي هو أنك حفرة دلالات ضد التغليف والبحث عن الفوز. أشك في أنك سوف تجد واحدة.

في رأيي، هناك نوعان من القوى التي تحفز التغليف: والدلالي والمنطقي

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

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

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

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

والتحيات، إد.

نصائح أخرى

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

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

وكما مبرمجا ليسب الذي تقدم يمكن القول إن أيا من هذه النظام الكائن، وأنا أقول: لا شيء ما سبق

وjwz: "طراز كائن الزائفة من Smalltalk يفقد وأن وظائف عامة (مقيدة بشكل مناسب من قبل عدم الخارجية، يتجاوز القاعدة) فوز"

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

عزل تعقيد هو المنظمة البحرية الدولية أن الهدف الرئيسي من أي تصميم:تغليف وظائف وراء واجهة أسهل للاستخدام من الوظيفة نفسها.

OO يوفر آليات مختلفة من أجل ذلك - وهما oyu نذكر:

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

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


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

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

المرونة التي ذكرتها هي في فهمي القدرة على تغيير بوف وفقا للاحتياجات الخاصة بك - ولكن هذا يتعارض مع التغليف:ما هي تفاصيل لا طائل من موقف واحد قد تكون فقط ذات الصلة في آخر.

OO, OTOH هو مقصر النهج:نغير بوف من خلال الانتقال إلى مستوى أعلى.في "القديم OO" هناك تسلسل هرمي واحد من POVs, واجهات - في هذا النموذج - وسيلة إلى نموذج مختلف POVs.

إذا جاز لي أن أقول ذلك ، فإن قوة OO هو أفضل مناسبة "الناس العاديين".

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

كيفية اختيار الأكثر فعالية "شعبة"/"تقسيم" مشروع كبير لتحقيق الأهداف أعلاه ؟ وقد أظهرت التجربة أن OO هي الرابح الأكبر هنا ، وأنا أعتقد أن الكثير من الناس يتفقون على أن اثنين من السمات الرئيسية من س س التي تجعل جيدة في هذا هي:

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

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

وقوة التصميم وجوه المنحى هي متناسبة مع مقدار <م> الربط المتأخر يحدث في التصميم. هذا هو مفهوم كاي من OO، وليس فكرة نيجارد. كتب آلان كاي :

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

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

والكثير من الأدب يتجاهل الربط المتأخر لصالح فكرة C ++ التوجه الكائن.

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

ويتم تنفيذ آليات OOP بسهولة في سهل C مع البنيات ومؤشرات الدالة. يمكنك حتى الحصول على القليل من OOP يشعر به الأمر على هذا النحو. ومع ذلك، والتعابير OOP ليست ما يقرب من المرتقبة في مثل هذه البيئة. عندما يكون هناك دعم اللغة الفعلي لOOP ثم التعبير من نموذج يخرج، والطريقة لغة تنفذ فكرة لديها تأثير حقيقي للغاية على ما "، وقال" وكيف. على سبيل المثال، نرى الاختلافات في التعليمات البرمجية باستخدام إغلاق / lambdas في ثغة، بيثون، روبي، وما إلى ذلك.

وحتى في نهاية المطاف انها ليست حول المكونات والمفاهيم الأساسية، وإنما كيف انهم وضع معا، ويستخدم هذا جعل OO في C ++ ما هو عليه.

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

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

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

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

و، البرمجة الوظيفية البحتة يمكن استخدام الكائن على التواصل .. ولكن هذه الكائنات تحتاج إلى أن تكون ثابتة. هكذا، مرة أخرى IMHO، FP يمكن بسهولة استخدام مفهوم OO. لغة حتمية مثل C يمكن الاستمرار في استخدام مفهوم OO .. على سبيل المثال، ملف لكل "من الدرجة الاولى" مع قسم الخاص الذي لا ينبغي أن تستخدم.

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

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

الاستمرار في التشبيه:للحصول على أقصى قدر من الطوب فقط ووضعها معا.على نفسه ينطبق على الفئات والكائنات.

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

بعض من هذه الأنماط بل هي إجابة الفقرة الثالثة السؤال:

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

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

و(اقرأ "نمط تصميم" من قبل عصابة من أربعة لفهم قوة OO).

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

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

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