كيف يمكنني تجنب استخدام الإجماليات في الكود الخاص بي؟
-
27-09-2019 - |
سؤال
أتعلم البرمجة وتصميم البرمجيات وجافا في المدرسة الآن. الفصل الذي يجعلك مختلطًا هو تصميم البرامج. نحن نستخدم Word لتشغيل رمز VB بسيط للقيام برامج بسيطة. يقول مدربي إنني أفقد التماسك باستخدام إجماليات الجري. أواجه صعوبة في التفكير في طريقة لتجنبها. فيما يلي مثال على بعض الرمز الكاذب الذي أتحدث عنه (تسمى الوحدات النمطية نموذج برنامج تشغيل غير معروض):
CaluculateDiscountPrice module
DiscountPrice = (FloorPrice * (1 – DiscountRate))
End module
CalculateDeliveryPrice module
If DeliveryFee = “Yes” Then
DeliveryPrice = DiscountPrice + 20
ElseIf DeliveryFee = “No” Then
DeliveryPrice = DiscountPrice
End If
End module
CalculateTradeInCredit module
If TradeInCredit = “Yes” Then
CreditedPrice = DeliveryPrice – 5
ElseIf TradeInCredit = “No” Then
CreditedPrice = DeliveryPrice
End If
End module
CaluculateCostOfBed module
CostOfBed = CreditedPrice
End module
أساسًا DiscountPrice
يستخدم للانضمام إلى الوحدات الأولين وبعد ذلك DeliveryPrice
الثانية. من المفترض أن الوحدة الأخيرة قد لا تحتاج حتى إلى أن تكون هناك إصلاح هذه المشكلة. أي مساعدة للمبتدئين؟
المحلول
عندما أنظر إلى مثالك ، فإن ما يقفز في وجهي يمثل مشكلة اقتران بين الوحدات. (إذا لم تكن قد درست هذا المفهوم بالفعل ، فربما ستفعل ذلك قريبًا). ومع ذلك ، فإن الكثير من الاقتران والتماسك القليل جدًا في كثير من الأحيان يسيران معًا ، لذلك آمل أن أتمكن من إعطائك إجابة مفيدة. (التعاريف المفرطة في التبسيط ولكنها كافية من أجل الهير: تقوم الوحدات المتماسكة بعمل شيء واحد يركز بدلاً من العديد من الأشياء غير ذات الصلة ، والوحدات النمطية المقترنة تعتمد على بعضها البعض للقيام بكل ما يفعلونه. نريد عادةً أن يكون لدى الوحدات التماسك قويًا داخليًا ولكن ضعف الاقتران وحدات أخرى.)
أستنتج من الرمز الكاذب الذي تريد حساب سعر السرير مثل:
* start with the floor price
* discount it
* add in a delivery fee
* subtract a trade-in credit
* the result is the cost of the bed
عندما تعبر عن ذلك ، قد تلاحظ أن هذه العمليات (أو يمكن أن تكون) مستقلة عن بعضها البعض. على سبيل المثال ، لا تعتمد رسوم التسليم حقًا على السعر المخفض ، فقط على ما إذا كان سيتم فرض رسوم تسليم أم لا.
الآن ، الطريقة التي قمت بتنظيم تصميمك ، متغير "التسليم" الخاص بك هو حقًا سعر "كما تم تسليمه" يفعل تعتمد على السعر المخفض. هذا هو نوع الشيء الذي نريد التخلص منه. يمكننا أن نقول أن وحداتك مقترنة بإحكام لأنها تعتمد على بعضها البعض بطرق غير مطلوبة حقًا لحل المشكلة. يمكننا القول أنهم يفتقرون إلى التماسك لأنهم يفعلون أكثر من شيء واحد - أي وحدة سعر التسليم هي إضافة رسوم التسليم إلى السعر المخفض بدلا من مجرد حساب رسوم التسليم.
من الصعب أن نرى مع أمثلة لعبة ، ولكن هذا يهم أن التصميمات تصبح أكثر تعقيدًا. مع وجود بضعة أسطر من الرمز الكاذب ، يبدو من الطبيعي تمامًا أن يكون لديك "إجمالي الجري" المربوطة بينهما. ولكن ماذا لو كانت رسوم التسليم تعتمد على حساب معقد يتضمن المسافة إلى منزل العميل ، ووزن الشراء ، ويوم الأسبوع؟ الآن ، وجودها ايضا تنطوي على أي سعر مخفض سيصبح مربكا حقا.
لذلك ، مع وضع كل ذلك في الاعتبار ، فكر في هذا التصميم البديل:
CalculateDeliveryFee module
If DeliveryFeeCharged = “Yes” Then
DeliveryFee = 20
End If
End module
CalculateTradeInCredit module
If TradeInCreditApplied = “Yes” Then
TradeInCredit = 5
End If
End module
CaluculateCostOfBed module
DiscountPrice = (FloorPrice * (1 – DiscountRate))
AsDeliveredPrice = DiscountPrice + DeliveryFee
WithTradeInPrice = AsDeliveredPrice - TradeInCredit
CostOfBed = WithTradeInPrice
End module
الآن ، يتم تقليل الاقتران - وحدات التسليم والتجارة لا تعرف أي شيء على الإطلاق عن أسعار السرير. هذا يحسن أيضًا تماسكهم ، لأنهم يقومون بشيء أكثر تركيزًا - حساب الرسوم ، وليس لجمع الأسعار والرسوم. يعتمد حساب الأسعار الفعلي على الوحدات الأخرى ، لكن هذا متأصل في المشكلة. والحساب متماسك - "الشيء الوحيد" الذي يفعله هو حساب سعر السرير!