سؤال

لدي Access db أستخدمه في دفتر الشيكات الخاص بي (مع قدر لا بأس به من VBA البسيط إلى حد ما خلفه) وأرغب في إعادة كتابته كبرنامج مستقل مع واجهة SQL خلفية.أفكر في استخدام إما C++ أو Java أو Python.

لقد افترضت، قبل أن أبدأ، أنني سأكتبها OO لأنني اعتقدت أنني سأفكر "بمصطلحات OO" (بسبب فصل OO Logic وفصل C ++ الذي أخذته)، لكنني وجدت أنه لا يمكنني سوى تصور الأمر على أنه إجرائي (ولكن ربما لأنني عالق عقليًا في التفكير في كيفية عمل قاعدة البيانات في Access).كيف أقرر؟هل أنا منطقي أم يبدو أنني لا أفهم المفاهيم؟

شكرا لمساعدتك.

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

المحلول

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

نصائح أخرى

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

الآن سوف البطة كما حمل كارفهي مع الطماطم.

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

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

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

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

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

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

في محاولة للتفكير في تطبيقاتك إلى كائن من البداية قد تقودك إلى نقطة عالقة من التسلسلات والهندسة الحيوية في الفصل الدراسي.

أنا لست عبقرية، لذلك قد أكون مخطئا، ولكن في تجربتي، بدءا من وظائف بسيطة ثم التفكير في تجميعها في كائنات أو وحدات أفضل من البدء بالقول: حسنا، سآخذ هذا الكائن الذي يتفاعل مع هذا الكائن، والذي ينفذ نمط X، بهذه الطريقة سوف Decouple واجهة Y من التنفيذ Z. في وقت لاحق، قد تلاحظ أن نموذج المجال الخاص بك ضعيف. خذ مسار التصميم التطوري والبدء في لبنات بناء صغيرة.

إذا كنت تبحث عن تطبيق سريع يمكنك تمديده، تحقق من البيانات الديناميكية.

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