محول الواحدات Storm Units

الشيفرة المصدرية + التطبيق

Storm units.rar

أرجو أن تتحمل انتقاداتنا المستقبلية!!...

وأرجو أن يشارك الجميع في تحليل البرنامج، وخاصة أنه سيعمل على أجهزة كثيرة مادام مصمم على منصة 1.3،،!!

فالكل يستطيع تقريبا تشغيل مثل هذا البرنامج!

ولاسيما أنه يوجد برنامج منافس وهو برنامج محول من OMLX، هنا: /index.ph...CC+%E3%CD%E6%E1

بالتوفيق!! وإلى الأمام!!

السلام عليكم .... الأخ حسام أنا جاهز لجميع الانتقادات ... اليكم هذا التحديث الجديد

نسخة 0.5 ألفا

Storm units.rar

السلام عليكم

الأخوة الأعزاء ... ممكن تساؤل ، لقد قمت بتخصيص الحدث

ValueChanged

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

بالمناسبة من أجل الاستعاضة عن الحدث

ValueChanged

قمت باستعمال ثﻻثة أحداث تقوم مقام الحدث السابق و هي :

KeyReleased
MouseClicked
MouseDragged

لكن الاختصار واجب ... بدﻻ من استعمال ثﻻثة أحداث تنحل المشكلة بحدث واحد

جرب..

private void jList_InWeiValueChanged(javax.swing.event.ListSelectionEvent evt) {                                         
// TODO add your handling code here:
        if(evt.getValueIsAdjusting())return;
        Calculate(null);
    }

لو تطبع الأخطاء كاملة هنا لكان أفضل! لا تقل يخرج خطأ ولكن قل هذا هو نص الخطأ..

بالتوفيق!

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

بما أنك ذكرت مشروع الأخ فهد .. اطلع على هذا الرابط للمشروع المنافس

/index.ph...ST&f=43&t=77716

أرجو أن تنتظر ردي قليلاً...

ok man

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

التعليق الثاني بسيط، حيث أن مبرجي Java اعتادوا عند تسمية الطرق اتباع قاعدة التسمية للمتغيرات فأول كلمة تبدأ بحرف صغير لتميز أسماء الطرق عن الصفوف والبواني Constructors. (مجرد أمر بسيط أحببت ذكره لأني أعتبره من العادات الجيدة)

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

حقيقة لطالما حلمت بمثل هذا، واليوم بعد ما رأيت برنامجك وبرنامج الأخ OMLX وبرنامج الأخ أبو مازن وجدت الأمر مرسوماً جاهزاً. حتى تتخلص من الثوابت العديدة والـ switch case الطويلة، بإمكانك إنشاء قاعدة بيانات أو ملف XML بسيط يحوي حقل لاسم الوحدة، الوصف، ثم جدول فرعي مرتبط بالسابق بقاعدة واحد لعدة، يحوي حقل بأسماء الوحدات وحقل العملية الرياضية التي تحول الناتج من الوحدة الأولى في الجدول الرئيسي إلى الوحدة الثانية في الجدول الفرعي وحقل للوصف.

(لتوضيح الفكرة، استخدمت Access في رسم الجداول والروابط.)

فلا حظ معي في الصورة التالية:

أن حقل اسم الوحدة UnitName2 في الجدول tblCalculater يأخذ بياناته من الجدول tblUnits من أجل اختصار حجم البيانات، وعدم الحاجة لإعادة كتابة اسم كل وحدة.

أما في هذه الصورة أوضح كيف ربطنا الجدول calculator بجدول الوحدات units عن طريق ربط الحقل MainUnitID بالحقل ID في جدول units بقاعدة One to many.

المهم هنا أننا بعد إنشاء قاعدة البيانات هذه، أو ملف الـ XML بطريقة مكافئة لما سبق ذكره. تضيف إلى قاعدة البيانات الصيغة الرياضية لحساب التحويل من الوحدة الرئيسية إلى الوحدة المطلوبة في حقل Formula في جدول Calculator.

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

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

أتمنى أن يكون شرحي شافياً وواضحاً.

الأخ مممس

اقتباس

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

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

اقتباس

مبرجي Java اعتادوا عند تسمية الطرق اتباع قاعدة التسمية للمتغيرات فأول كلمة تبدأ بحرف صغير لتميز أسماء الطرق عن الصفوف والبواني Constructors

أنا أحاول الاعتياد على هذه الطريقة لأنني مازلت محتفظ بأسلوب C++ في التسميات

اقتباس

شيفرة الطريقة CountConvert طويلة جداً وذلك بسبب الاعتماد على switch case كما أن الشيفرة تحوي عدد هائل من الثوابت، وكأنك تبني قاعدة بيانات البرنامج ضمن الشيفرة، وهذا يصعب عملية التطوير والإصلاح كثيراً

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

اقتباس

بإمكانك إنشاء قاعدة بيانات أو ملف XML

حتى الآن لم استعمل قواعد البيانات أو XML في جافا .... ان كان بامكانك استعمال XML فأرجو أن تقوم بتعديل شيفرة البرنامج لتستعمله .... من المهم عدم استعمال قواعد بيانات Access لأنها لن تعمل على Linux

اقتباس

الحل جميل جداً ويصنع ما يدعى بالتكامل بين البرامج والاستفادة من البرامج التي صنعها أصدقاءنا، فالحل يعتمد على برنامج الأخ أبو مازن

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

الأخ ممس

اقتباس

بما الأمور أصبحت معقدة بعض الشيء، ولكن -ثق بي- ليس فيها أي تعقيد إنما لعل شرحي لم يكن واضحا

بدون رياء :rolleyes: :rolleyes: :rolleyes: شرح علاقات بنية المعطيات واضح لكنني لم أفهم الباقي .... :lol: :lol: :lol: :lol: :lol: المهم أنني لم أتعامل مع ْXML بواسطة جافا قط ... أين الحل برأيك

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

تعليقات أخي MMSs في مكانها لكني سأزيد التعقيب الثالث له عن تصميم شفرة Count!

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

هذه المشاركة ستنتقد الأسلوب المتبع وفي رد مستقبلي سأدرج النصائح:

ذكر أخي MMSs أن الشفرة مليئة بالثوابت التي بلغت 120 تابع في Count !

السؤال هو: هل هذه التوابع مكونات داخلية من تصميم Count ، كان من الأفضل أن تكون هذه التوابع static لأنها أصلا ثابتة ولا تتغير مع إنشاء Count جديد كل مرة!،،

ما نوع الخدمة التي من المفترض أن تعطينا إياه الفئة Count؟ لاحظ أنها تحوي طرق لجلب قيم معينة فقط،، أحاول أن أقول أنه كان بالإمكان أن تكون جميع الطرق التي فيها (وهي طريقتين) أن يكونا static. أضف إلى ذلك الأمر أنه لا يحتاج أن نصنع Count جديد new، فهو لن يفيد شيئا،،

اجعل الفئة هكذا مثلا:

class Count{
private Count(){};
public static int asckiCode(...){};
public static void countConvert(..){}
}

طبعا هذه ليست أفضل طريقة، وليست هي المفضلة أبدا، لكنها أفضل من الاستخدام الحالي للفئة Count. مثلا!

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

2- أسلوب التشفير الغريب الذي استعملته حتى تعرف كيف تقرأ التوابع التي تريد هي من الأشياء العجيبة في البرنامج( الطريقة getAscii،، تعطي كلمة ويشفرها إلى رقم حتى تستخدم الرقم في عملية switch case!

أضف إلى ذلك أن الطريقة مكررة في كل من الفئات Length, Count, وغيرها!

3- أسلوب تكرار الواجهات الرسومية لكل من Length, Count وغيرها، الواجهة لا تعيد استخدام مكوناتها! في MainJFrame

4- التوابع كثيرة لأنك تنشئ تابعا جديدا للتحويل بين متر إلى سم ومن سم إلى متر!! أليست الأولى مقلوب الثاني؟ لماذا التكرار؟

5- يفترض استخدام البرمجة الغرضية التوجه في تصميم مثل هذا البرنامج ولا سيما أن تضع الأشياء المشتركة في كل من Lengthو Count وغيرها!

الملخص: إذا أردت إضافة محول جديد وليكن التحويل الحراري فأنت ستكتب هذه الأشياء في برنامجك:

1- ستصنع فئة جديدة بالكامل تحمل جميع قيم التحويل بين فهرنهايت و كلفن وبين كلفن وفهرنهايت،

2- ستضيف إليها أسلوب التشفير العجيب وتضع لكل نوع رقما تشفيريا خاصا!

3- ستكتب switch-case طويلة جدا.

4- كل خطوة من هذه الخطوات قد تأتي بالأخطاء التي من الصعب تصحيحها!

5- ستغير شفرة MainJFrame وتضيف JList جديد، و أشياء أخرى ولا تعيد استخدام الأشياء التي قد تم بناؤها سابقا،

6- ستضيف مستمعين لكل list جديد، وهكذا،،

7- ستنشئ برنامجا جديدا، وسيكون في مرحلة بيتا! لأنه تم تغيير أشياء كثيرة في الشفرة التي قد ينتج عنها أخطاء، وفترة تجربة البرنامج ستكون طويلة!

8- كلما أضفت تحويل جديد يزيد حجم برنامجك (على الأقل) 200 سطر!! الحجم الحالي للفئة Count فقط هو 800 سطر!

يتفوق برنامجك عن برنامج OMLX في أن شفرة الحسابات أو منطق البرنامج مفصول 80% من شفرة الواجهات الرسومية، فبرنامج Unit Storm منطقه في Count وأخواتها، وشفرة الواجهة في MainJFrame،، لكنهما ليسوا مفصولين (((تماما)))

أما برنامج المحول الإصدار الأول، فقد كان منطق البرنامج والواجهة الرسومية في نفس الفئة!

طبعا Count ليس مفصولا تماما عن الواجهة ولا يحتاج هذا الشيء إلى التحري الكبير، فيكفي أن تقرأ في أعلى الشفرة هذا التعليق:

package Units;
import java.lang.*;
import javax.swing.JButton;
import javax.swing.*;

إذا وجدت هذه الجمل يعني أني لن أستطيع استخدام حزمتك في إنشاء برنامج مبني على awt بدلا من swing، أو لن أستطيع استخدام واجهة أخرى،، مثلا أنا أريد أن أصنع برنامجا يعرض النتيجة على JButton وليس JTextArea،، حزمتك لن تساعدني في ذلك! افرض أني أريد أن آخذ حزمتك وأضعها في صفحة JSP،، لن أستطيع، لأن صفحات الشبكة تحوي HTML ولا تحمل JButton أو JTextField، أو حتى على الجوال، أقصد من هذا الأمر أنك ربطتني وربطت نفسك في صعوبة تغيير الواجهة الرسومية، فإذا أردت تغيير الواجهة الرسومية فيجب أن تغير منطق البرنامج في كل من Count, Length وغيرها!! وهذا أمر مزعج!

لكن عامة، يشترك برنامج المحول وبرنامج Unit Storm في نفس الملاحظات الأخرى الذي ذكرت هناك وهنا!

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

أرجو أن تقرأ الموضوع كاملا هنا:

برنامج محول الإصدار الأول من فهد OMLX

في الوصلة السابقة شرح مفيد لكيفية تصميم مثل هذا البرنامج، حاول التركيز على شرح التصميم، وأزيد وأقول أن MMSs شرح ذلك في مشاركته، لاحظ أن MMSs لم يتكلم عن الواجهة، بل تكلم عن منطق البرنامج! وهذا هو المهم!

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

في الرد المقبل سأتكلم عن كيف تعرف أن تصميمك ممتاز؟؟

---------------------

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

كيف تعرف أن تصميمك ممتاز؟؟

في موضوع برنامج المحول الإصدار الأول من OMLX تعرضت لهذه الأمور،، وصنعت برنامجا تطويرا يدعم الأفكار التي كتبتها في كلا الموضوعين تقريبا،،

في كلمات بسيطة، هل تصميمي ممتاز فعلا؟؟، لن نعرف هذا إلا بالامتحان والتجربة، الامتحان الأول كان في موضوع OMLX فقد صنعت المحرك أو منطق البرنامج وكان أقل من 400 سطر يحوي المنطق وبيانات التحويل ل 8 أنواع من التحاويل والله أعلم! وبعد هذا استخدمت طريقتين لعرض البرنامج، أقصد على واجهتين مختلفتين،،

والآن ماذا فعلت؟؟

1- جئت بهذا المحرك المكون من 3 فئات فقط يحوي كل ما نريده تقريبا، الأول Formula و الثاني Converter والثالث ConverterFactory! والأخير يحوي البيانات! والأول والثاني يحوي منطق البرنامج!

2- باستعمال Netbeans عملت نسخ ولصق Copy Paste لواجهة Unit Storm وغيرت قليلا في الشفرة،،

صنعت ConverterPanel وهذه تعرض التحويلات لنوع واحد!

صنعت ContainerPanel وهذا تقسم عرض التحويلات الأخرى على شكل TabbedPane،، كل pane عبارة عن new ConverterPanel()

صنعت MainFrame يضع في وسطه ContainerPanel حتى يصبح نافذة على سطح المكتب,,,

ربما نصنع مستقبلا Applet تضع في وسطه ContainerPanel حتى يصبح على المتصفح!

3- لاحظ أني لم أغير أي شيء في شفرة المحرك الأساسي، التي تحوي البيانات ومنطق البرنامج!

4- عملت اتصال بين ConverterPanel و Converter معين!

بمعنى آخر صنعت طريقة اسمها calcualte تقوم بالمطلوب!!

5- لم يأخذ دمج الواجهة الجديدة مع المحرك أكثر من ربع ساعة!!

بهذا أصبح لدينا واجهة الأخ بشير مع محركي!

6- إذا أردت إضافة نوع جديد من التحويلات وليكن مقاسات الألبسة،، فافعل هذا في شفرة ConverterFactory، الذي يحوي البيانات، ولا تغير أي حرف في شفرة الواجهة الجديدة!! فهي ستتعرف على الدوال الجديدة مباشرة!!

7- طبعا المحرك بسيط، وهو يقرأ البيانات من الشفرة،، لو كنت سأجعل البرنامج أقوى أكثر لجعلت بيانات البرنامج في ملف خارجي، كما اقترح الأخ MMSs! وهكذا إذا أردت إضافة الأنواع الجديدة فقط تكتب في البيانات مباشرة دون أن تغير حرفا واحدا في الشفرة!

هذه صورة بسيطة لبرنامج Unit Storm بعد التطوير البسيط:

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

----

بهذا نعرف إذا كان التصميم ممتازا أو لا،، تصميم هذا المحرك يجعلك تقوم بتغيير شكل برنامجك في أقل من ساعة دون تغيير أي شيء جذري في برنامجك!!

أرجو أن تقرأ شفرة المحرك، فهي غرضية التوجه،، وأرجو أن تقرأ تصميم الواجهة الجديد، فهو غرضي التوجه كذلك!

لم أصمم إلا اثنتين من JList وليس أكثر..

أرجو أن يكون هذا مفيدا،، إليك البرنامج الجديد، وشفرة برنامج OMLX المطور، والمحرك، وبرنامجك الإصدار الأول في مشروع واحد!

الملف الرئيسي هو com.cDell.units.gui.MainFrame

المحرك في الحزمة hussam.converter

إذا أردت إضافة نوع جديد من التحويلات فأضفها في ملف hussam.converter.ConverterFactory وسترى بإذن الله ما يسرك مباشرة في أي واجهة رسومية، سواء واجهتك أو واجهة الأخ فهد!

الحزمة hussam.converter.main عبارة عن واجهة البرنامج التي في موضوع OMLX الجديدة! تستطيع حذفها، فهي غير مستخدمة في برنامجك،، لكني أضفتها كي تعرف كيف ُتستخدم المحرك في الواجهة الأخرى!!

نسيت أن أذكر أن البرنامج يحتاج إلى جافا 1.5، وذلك لأن المحرك صنعته قديما على هذه الإصدارة!

وآسف على الإطالة... وأعتذر عن أي تقصير!!

StormUnit 2.0.zip

كما قلت أخي أبو مازن، فأنا لم أدقق كثيراً على الواجهات في البرنامج، وإنما على منطق البرنامج أو أسلوب عمله، وهذا غالباً ما يهمني وآخر ما أفكر في هو الواجهات. تعلمت هذا عندما بدأت بتعلم Java.

في الحقيقة أخي C&DEL أنا أيضاً لم أتعامل بعد لا مع قواعد البيانات ولا مع ملفات XML في Java، ولكني أعرف ما هي قواعد البيانات وكيف يمكن الاستفادة منها في البرامج (مثلك ومثل أي مبرمج تماماً). وهذا ما أردت الاستفادة منه.

دعنا مبدئياً من XML فأنا لا أعرف تماماً كيف أستطيع التعامل معها، ولكن دعنا أيضاً من قواعد البيانات، ودعنا نجرد الفكرة ونبسطها باستخدام ملفات نصية كما قال أخي أبو مازن.

تخيل معي..

يوجد ملف نصي مقسم إلى مجموعات، كل مجموعة مكونة من سطرين.

في السطر الأول اسم الوحدة الأولى ثم فاصلة ثم اسم الوحدة الثانية. حيث الوحدة الأولى هي التي يدخلها المستخدم والوحدة الثاني هي الوحدة التي سيحول الناتج لها.

مثلاً

المستخدم يدخل القياس بالمتر، ويريد تحويله إلى كيلومتر

في السطر الثاني معادلة التحويل.

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

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

الآن لنرى كيف ستكون الشيفرة التي سوف تأخذ القيمة التي أدخلها المستخدم، وأسماء الوحدات التي اختارها المستخدم، وكيف ستعيد الناتج لنا.

سوف تأخذ هذه الطريقة ثلاث متغييرات:

value من النمط double: القيمة التي أدخلها المستخدم.

fromUnit من النمط String: الوحدة التي أدخل قيمتها المستخدم.

toUnit من النمط String: الوحدة التي سوف يحول القيمة لها.

الخوارزمية:

نبحث عن السطر الذي ذكر فيه القيمة

fromUnit + ", " + toUnit

ثم نقرأ السطر التالي له (هو سطر الصيغة الرياضية طبعاً)، ونخزنه مبدئياً في متغير formula من النمط String.

نبحث في المتغير formula عن كل ورود لـ x فنحذفه ونضع مكانه قيمة المتغير value.

نطلب من الطريقة reader.readOperation أن تقرأ لنا هذه الصيغة الرياضية، فتقوم هي بطريقتها الخاصة بتحليل الصيغة الرياضية وحلها.

ثم نطبع النتجية المعادة في الطريقة result مربع النتيجة.

----------------------------------------------

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

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

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

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

String formula = getFromFileWhatEvenFormula(); 
//or
formula = "x/1000";// only
Operation o1 = reader.readOperation(formula);
// الآن غير قيمة x أو أي قيمة أخرى!!
reader.getOperatorSource().getLocalVariable("x").setOperaition(new ConstantNumber(value));
double result = o1.result();

للمزيد، اقرأ في كيف تستخدم الحزمة بسهولة في هذا الموضوع:

/index.php?showtopic=74047

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

Kilo Meter = Meter / 1000
Meter = Kilo Meter * 1000
Fihrinhiet = Celcius *9/5 +32

وهكذا:
[code]
بعدها اقرأ المعادلات سطرا سطرا، وعندها ستعرف اسم التحويل بمجرد معرفة اسماء المتغيرات:
[code]
String firstFormula = getFormula(); // ولتكن :
// Meter = Kilo Meter * 1000
Operation o1 = reader.readOperation(firstFormula);
Map variables = reader.getOperatorSource().getLocalVariables();

والآن أصبح لديك أسماء المتغيرات في المعادلة ومنها تعرف التحويل،، أقصد من هذه المشاركة أن تستخدم أسماء المتغيرات بدل وضع وصف لها كما تفضل MMSs. فبدل أن تكتب شرح + معادلة، اكتب المعادلة وكفى!

لكن حاليا هذا خارج أفق البرنامج الذي نحن بصدده، أرجو أن نرى إصدارات جديدة لنفس البرامج أو برامج غيرها!

ما شاء الله على الأخوان ، ما قصروا ،،، في تشريح البرنامج ،، :blink: :blink:

وسع بالك أخي بشير ،، :D :D

من الناحية منطق البرنامج فإني لا أتكلم عنه ،،،

أما من ناحية التصميم فلي رأي مخالف للأخ أبو مازن،،

لقد قاس مدى جمال وسهولة تصميم البرنامج بقابلية نقل واجهة البرنامج إلى المحركات أخرى ،،

وفي رأي أن مدى جمال و سهولة واجهة البرنامج لا تقاس بهذا المقياس ، لأن هذا المقياس مقياس المبرمج وليس المستخدم النهائي،

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

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

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

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

هذه وجهة رأيي ، ربما تكون مخطأ ولكن أنا أخالف رأي الأخوة تصميم واجهة البرنامج له أهمية لا تقل عن أهمية منطق البرنامج ،،،

تحليل الواجهة الرسومية وسهولة الاستخدام لكل من المحول من الأخ فهد وUnit Storm من الأخ بشير:

لم أتكلم حتى الآن عن هذين الأمرين، والآن أقول رأيي:

1- بالنسبة للواجهة الرسومية:

كلا البرنامجين واجهتمها جملية، لكن برنامج Unit Storm أجمل من وجهة نظري.

2- بالنسبة لسهولة الاستخدام: (وهو شيء مختلف عن جمال الواجهة الرسومية)

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

لكن لا أقصد أن Unit Storm صعب التعامل، بل هو ما يزال في منزلة السهولة!

شخصيا: أهتم بسهولة الاستخدام أكثر من الجمال!

-------------------------

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

بعض التوضيح:

تصميم = Design ولا أقصد GUI!

عندما أتكلم عن التصميم عادة أقصد تصميم شفرة منطق البرنامج، هل يوجد فيها تكرار؟ هل من السهل تطويرها؟ هل من السهل الكشف عن الأخطاء؟ هل من السهل إضافة الأشياء الجديدة عليها؟ هل من السهل نقلها واستخدامها بأشكال أخرى؟ هل من السهل فهم الشفرة من قبل أشخاص آخرين؟

اقتباس

كيف تعرف أن تصميمك ممتاز؟؟

أقصد كيف تعرف أن تصميم منطق شفرتك ممتاز؟ ولا أقصد كيف تعرف أن الواجهة الرسومية ممتازة! وكنت أقصد تصميم منطق البرنامج وليس واجهة Unit Storm،

تصميم منطق البرنامج في Unit Storm هي الفئة Count ولا أقصد الفئة MainJFrame!

تصميم منطق برنامج المحول في وسط شفرة الواجهة الرسومية.

سهولة الاستخدام وجمال الواجهة الرسومية أمران لم أقصدهما بتاتا..

وقد قلت رأيي في جمال الواجهة الرسومية فقط في هذا المقطع:

اقتباس

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

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

اقتباس

وفي رأي أن مدى جمال و سهولة واجهة البرنامج لا تقاس بهذا المقياس ، لأن هذا المقياس مقياس المبرمج وليس المستخدم النهائي،

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

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

لكني لم أقصد هذا المقياس :)،

اقتباس

لقد قاس مدى جمال وسهولة تصميم البرنامج بقابلية نقل واجهة البرنامج إلى المحركات أخرى ،،

بل العكس، لقد قست مدى جمال تصميم (المنطق أو المحرك) بقابلية تغيير واجهة البرنامج إلى واجهات مختلفة بسرعة شديدة!

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

----

خلاصة:

لقد كتبت المشاركات السابقة دون أن أعيد قراءتها جيدا، وأعتذر مجددا عن عدم وضوح فكرتي. ربما الآن بعد توضيح فكرتي سيكون من السهل فهم التعقيبات السابقة!

أمر تصميم الواجهة الرسومية أمر ذوقي، وسهولة الاستخدام والوضوح أمر مهم جدا لأي برنامج ناجح!

لا عليك أستاذي أبو مازن ،،،

وكلمة التصميم تحتمل النوعين، أنا قصدت واجهة التطبيق و انت قصدت آلية عمل التطبيق،،

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

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

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

تحياتي

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

أي إذا كانت الدالة مثلاً:

kilometer = meter / 1000

فهل يوجد طريقة convert مثلاً لقلب الدالة السابقة، حتى تصبح :

meter = kilometer * 1000

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

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

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

وأرى أن في كل برنامج من البرنامجين صفة جيدة، في برنامج المحول الأخ OMLX الحساب التلقائي لكل الوحدات، فهي أفضل وأسرع، ولكن لا أحبذ فكرة الأزرار لاختيار نوع التحويل (طول، مساحة، حرارة)، حيث أن برنامج Storm Units للأخ C&DEL أفضل من هذه الناحية لأنه يعرض الأنماط في تبويبات. كما لا أحبذ أن ينقل المستخدم المؤشر من مربع نص إلى مربع نص آخر حتى يدخل قيمة الوحدة التي يريد حسابها، فلو كان التحويل يتم بين عدد كبير من الوحدات، فإن الانتقال بزر Tab يصبح أمر طويل، أما إذا وضع مربع نص واحد وبجانبه قائمة منسدلة ComboBox لاختيار الوحدة التي يدخلها، ثم تظهر نتائج التحويل في الأسفل بجانب اسم كل وحدة لكان أفضل.

الأخوة الأعزاء

لن تتصورا كم أنا مسرور جدا لمناقشة هذا البريمج معكم في الحقيقة لقد تركت الانترنت فترة قصيرة لكنني وجدت هذه الاقتراحات الرائعة و خاصة و أخص بالذكر الأخوة أبو مازن ، MMss ، OMLX ... و أريد أن نتبهوا الى أن هذا البرنامج كتب على عجل بواسطة Delphi و التي من معروف عنها أنها أكثر اللغات بعدا عن OOP لذلك اضطررت لاستعمال طريقة ميكروزفت الملعونة CCP (cut,copy,paste) و بعد تحويل الsyntax يجب تحويل الشيفرة بشكل كامل (بامكانكمالاطلاع على شيفرة Delphi ضمن توقيعي) لتصبح OOP و أريد أن تعذروني لسبب مهم و هو أنني بالرغم من أنني مارست C++ لفترة طويلة و أنجزت برامج عديدة أهمها برنامج تجاري شبيه لـCorel (أو أفضل منه) و هو OOP 100% الا أنني أحس الآن أنني موثوق الى نخلة بالسماء ليس باستطاعتي العودة الى C++( بسبب تعدد بيئات التشغيل ) و ليس بامكاني التحرك السريع في Java بسبب عدمي فهمي المعمق لها (بامكانك مراجعة رابط "هل جافا هي الخيار الصحيح" ضمن توقيعي)