سؤال

سؤال سريع:متى تقرر استخدام الخصائص (في C#) ومتى تقرر استخدام الطرق؟

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

public void SetLabel(string text)
{
    Label.Text = text;
}

في المثال، Label هو عنصر تحكم على صفحة ASPX.هل هناك مبدأ يمكن أن يحكم القرار (في هذه الحالة) بجعل هذا طريقة أو خاصية.

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

نصائح أخرى

نعم، إذا كان كل ما تفعله هو الحصول والإعداد، فاستخدم خاصية.

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

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

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

بشكل عام، فلسفتي هي أنك إذا بدأت في كتابة اسم أسلوب يبدأ بـ get أو set ويأخذ صفرًا أو معلمة واحدة (على التوالي)، فهو مرشح رئيسي لخاصية ما.

إذا كنت تقوم خاصية الفعلية من وجوه الخاص بك، ثم يمكنك استخدام خاصية.

إذا كنت أداء مهمة / وظيفة ثم عليك استخدام أسلوب.

في المثال الخاص بك، فمن خاصية محددة يتم تعيين.

ولكن إذا كانت وظيفة لAppendToLabel ثم يمكنك استخدام أسلوب.

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

وطرق تلخص العملية.

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

وأنا استخدم أساليب عندما أقوم بإنشاء العملية، مثل استرجاع البيانات من قاعدة البيانات. أي عملية لها أجزاء متحركة، هو المرشح لأسلوب.

في المثال التعليمات البرمجية الخاصة بك وأود أن التفاف عليه في الملكية إذا كنت بحاجة إلى الوصول إليه خارج انها تحتوي على الدرجة:

public Label Title 
{
   get{ return titleLabel;}
   set{ titleLabel = value;}
}

وضبط النص:

Title.Text = "Properties vs Methods";

إذا كنت فقط تعيين الخاصية نص تسمية هذه هي الطريقة التي أود أن تفعل ذلك:

public string Title 
{
   get{ return titleLabel.Text;}
   set{ titleLabel.Text = value;}
}

وضبط النص:

Title = "Properties vs Methods";

من خلال البحث في MSDN، وجدت مرجعًا لـ الخصائص مقابل الأساليب الذي يوفر بعض الإرشادات الرائعة لإنشاء الأساليب:

  • العملية عبارة عن تحويل، مثل Object.ToString.
  • العملية باهظة الثمن بما فيه الكفاية بحيث تريد التواصل مع المستخدم بحيث ينبغي عليهم التفكير في تخزين النتيجة.
  • سيكون للحصول على قيمة خاصية باستخدام GET Accessor تأثير جانبي يمكن ملاحظته.
  • يؤدي استدعاء العضو مرتين متتاليتين إلى نتائج مختلفة.
  • ترتيب التنفيذ مهم.لاحظ أن خصائص النوع يجب أن تكون قادرة على ضبط واسترداد بأي ترتيب.
  • العضو ثابت ولكنه يُرجع قيمة يمكن تغييرها.
  • يقوم العضو بإرجاع مصفوفة.الخصائص التي يمكن أن تكون صفائف الإرجاع مضللة للغاية.عادة ما يكون من الضروري إرجاع نسخة من الصفيف الداخلي بحيث لا يمكن للمستخدم تغيير الحالة الداخلية.هذا ، إلى جانب حقيقة أن المستخدم يمكن أن يفترض بسهولة أنه خاصية مفهرسة ، يؤدي إلى رمز غير فعال.

وخصائص Symantically هي سمات من الأشياء الخاصة بك. الأساليب هي السلوكيات من وجوه الخاص بك.

والتسمية هي سمة وإنه من المنطقي أن تجعل من الممتلكات.

في مجال البرمجة الموجهة يجب أن يكون لديك فهم واضح لما هو جزء من السلوك وما هو مجرد سمة.

والسيارات {اللون، نموذج، العلامة التجارية}

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

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

ما عليك سوى إلقاء نظرة على اسم جدا ... "الملكية". ماذا يعني؟ القاموس يعرف ذلك بطرق عديدة، ولكن في هذه الحالة "سمة أساسية أو مميزة أو نوعية لشيء ما" يناسب أفضل.

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

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

وفكر خصائص مثل الصفات. سيارة لديها العديد من الصفات. اللون، MPG، نموذج، الخ .. ليست كل الخصائص هي setable، وبعضها calculatable.

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

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

أفضّل استخدام الخصائص لأساليب الإضافة/المجموعة مع 1 معامل.إذا كانت المعلمات أكثر، استخدم الأساليب.

يجب أن تكون

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

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

وزائد كبيرة أيضا لخصائص هو يمكن أن ينظر إلى أن قيمة الممتلكات في Visual Studio أثناء التصحيح.

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

كان

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

وكل شيء أساليب شيء آخر هي الطريقة المفضلة.

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

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

من حيث التصميم، تمثل الخصائص بيانات أو سمات كائن الفئة، في حين أن الأساليب هي إجراءات أو سلوكيات كائن الفئة.

في عالم .Net هناك آثار أخرى لاستخدام الخصائص:

  • يتم استخدام الخصائص في Databinding، في حين لا يتم استخدام أساليب get_ / set_.
  • خصائص مستخدم تسلسل XML كآلية طبيعية للتسلسل.
  • يتم الوصول إلى الخصائص عن طريق بروبرتيغريد السيطرة والمتدرب IcustomTypeDescriptor, والتي يمكن استخدامها بشكل فعال إذا كنت تكتب مكتبة مخصصة.
  • يتم التحكم في الخصائص بواسطة صفات, ، يمكن للمرء استخدامه بحكمة لتصميم البرامج الموجهة نحو الجانب.

المفاهيم الخاطئة (IMHO) حول استخدام الخصائص:

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

في المثال هنا كان من الممكن كتابته، مع المزيد من المعنى التجاري على النحو التالي:

public String Title
{
    set { Label.Text = text; }
}

هنا مجموعة جيدة من القواعد الارشادية لمعرفة متى يتم استخدام الخصائص مقابل الأساليب من بيل فاغنر

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

  • يجب ألا يُرجع الحصول على مرجع إلى هياكل البيانات الداخلية (انظر البند 23).يمكن للأسلوب إرجاع نسخة عميقة، ويمكن أن يتجنب هذه المشكلة.

* مأخوذ من إجابتي على سؤال مكرر.

هذا بسيط.

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

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

ولقد جئت من جافا واعتدت الحصول على .. تعيين .. وطريقة لفترة من الوقت.

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

واليوم لدي SetAge طريقة (عمر الباحث) tomonrow سوف يكون لي أيضا SetAge طريقة (التاريخ تاريخ الميلاد) التي تقوم بحساب العمر باستخدام تاريخ الميلاد.

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

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