24-03-2010, 10:07 PM
السلام عليكم
مرحبا أخيo15s19
أشكرك على الجهد المبذول في مشروع المحادثة.
لم أستطع تجربة البرنامج (بعض مكونات اندي المستخدمة في المشروع ليست متاحة لدي في دلفي 6) ولكن بالنظر إلى الكود أرى أنك تقوم بعمل مميز.
لي بعض الملاحظات، أتمنى أن يتسع وقتك لها. طبعا الذي يتفرج ينظر بطريقة تختلف عن تلك التي ينظر بها المبرمج الغارقة يداه في العمل، ملاحظاتي تتركز على الناحية التنظيمية لتوليف البرنامج، وتقع في مجال ما يسمى ب، Refactory أي عمليات المراجعة والتنقيح وإعادة الضبط،والتي ينصح أن تتم بشكل دوري وفترات متقاربة:
تغيير إسم الوحدة uNetManager إلى
uServerNetManager أو uNetManager_Server(أعتقد الأخيرة أوضح)
للتفريق مع وحدة بنفس الاسم في برنامج الكلاينت
TServer تغير إلى TVirtualServerProvider
ويكون إسم المتغير من نوعه ServerProvider بدلا من Server
TChatServer تغير إلى ِTAppChatServer
ويكون إسم المتغير AppChatServer بدلا من ChatSever
في نسخة السيرفر يوجد TClient إذا كان المقصود به المتصل الحالي فأرى إعادة تسميته إلى TGuestClient أو TConnectedClient
وهكذا الأمر بالنسبة لنسخة الكلاينت:
uNetManage_Client
TVertualClientProvider بدلا من TClient
TAppChatClient بدلا من TChatClient
AppChatClient بدلا من ChatClient
المتغير Server والمنغير Client في نسخة الكلاينت أرى أن يعاد تسميتهم كالتالي:
ServerProvider و ClientProvider حيث أنهما سيشيران إلى توع التقنية المستخدمة في كل منهما.
أرى وضع المتغير Server أو ServerProvider (إذا تغير اسمه) داخل قسم private في صنفية AppChatServer فهذه الصنفية هي الوحيدة التي تستخدمه والمسئولة عن خلقه واتلافه.
الوحدة uNetManager يجب أن لا تعلم بتفاصيل التقنية المستخدمة في الربط، وبالتالي يجب أن لا تكون هناك أية إشارة لملفات اندي في قسم uses لديها. ويتبع هذا أن الصنفيات في هذه الوحدة يجب أن لا تستخدم مباشرة تقنية اندي أو أية تقنية ربط أخرى، مثلما هو حاصل الآن مع صنفية TClient .
إذا تمت الأمور بهذا الشكل يمكنني عندها أن أعزل الملف uNet_INDY الذي لا أملك مكوناته واستخدم أو أبرمج تقنية أخرى للربط.
أيضا الوحدة uNetManager يجب أن لا تخاطب مباشرة الوحدة uAppManager ، ويجب أن لا تعلم عنها شيئا. قهي مثل العبد الأعمى ينفذ الأمر و لا يعلم من يأمره. (افترض أن هناك برنامج آخر لمبرمج آخر وبريد أن يستفيد من خدمات هذه الوحدة.)
نفس الكلام ينطبق على الوحدة uAppManager ، فهي تستخدم مباشرة أوامر خاصة باندي وتتخطى الوحدة uNetManager التي يفترض أن تكون المسئول الوحيد عن أمور الربط والاتصال. كما أنها تخاطب مباشرة الشاشة الرئيسية في وحدة D4A_Serverfrm.
الوحدات uNet_Broad و uMisc باعتبارهما خاصتان باندي هل يمكن ضمهما إلى وحدة uNet_INDY.
طبعا نفس المبادئ السابقة تعمم على باقي الجوانب كقواعد البيانات.
سؤال: هل يمكن رفع مستوى التنظيم (أو التعقيد!) بجعل أوامر وحدة uNetManager ضمن صنفية نسميها TNetManager_Server
أخيرا، المبرمج هو صاحب الكلمة العليا، لتنفيذ ما يراه مناسب في الوقت الذي يراه مناسب.
وتقديري مرة أخرى.
مرحبا أخيo15s19
أشكرك على الجهد المبذول في مشروع المحادثة.
لم أستطع تجربة البرنامج (بعض مكونات اندي المستخدمة في المشروع ليست متاحة لدي في دلفي 6) ولكن بالنظر إلى الكود أرى أنك تقوم بعمل مميز.
لي بعض الملاحظات، أتمنى أن يتسع وقتك لها. طبعا الذي يتفرج ينظر بطريقة تختلف عن تلك التي ينظر بها المبرمج الغارقة يداه في العمل، ملاحظاتي تتركز على الناحية التنظيمية لتوليف البرنامج، وتقع في مجال ما يسمى ب، Refactory أي عمليات المراجعة والتنقيح وإعادة الضبط،والتي ينصح أن تتم بشكل دوري وفترات متقاربة:
تغيير إسم الوحدة uNetManager إلى
uServerNetManager أو uNetManager_Server(أعتقد الأخيرة أوضح)
للتفريق مع وحدة بنفس الاسم في برنامج الكلاينت
TServer تغير إلى TVirtualServerProvider
ويكون إسم المتغير من نوعه ServerProvider بدلا من Server
TChatServer تغير إلى ِTAppChatServer
ويكون إسم المتغير AppChatServer بدلا من ChatSever
في نسخة السيرفر يوجد TClient إذا كان المقصود به المتصل الحالي فأرى إعادة تسميته إلى TGuestClient أو TConnectedClient
وهكذا الأمر بالنسبة لنسخة الكلاينت:
uNetManage_Client
TVertualClientProvider بدلا من TClient
TAppChatClient بدلا من TChatClient
AppChatClient بدلا من ChatClient
المتغير Server والمنغير Client في نسخة الكلاينت أرى أن يعاد تسميتهم كالتالي:
ServerProvider و ClientProvider حيث أنهما سيشيران إلى توع التقنية المستخدمة في كل منهما.
أرى وضع المتغير Server أو ServerProvider (إذا تغير اسمه) داخل قسم private في صنفية AppChatServer فهذه الصنفية هي الوحيدة التي تستخدمه والمسئولة عن خلقه واتلافه.
الوحدة uNetManager يجب أن لا تعلم بتفاصيل التقنية المستخدمة في الربط، وبالتالي يجب أن لا تكون هناك أية إشارة لملفات اندي في قسم uses لديها. ويتبع هذا أن الصنفيات في هذه الوحدة يجب أن لا تستخدم مباشرة تقنية اندي أو أية تقنية ربط أخرى، مثلما هو حاصل الآن مع صنفية TClient .
إذا تمت الأمور بهذا الشكل يمكنني عندها أن أعزل الملف uNet_INDY الذي لا أملك مكوناته واستخدم أو أبرمج تقنية أخرى للربط.
أيضا الوحدة uNetManager يجب أن لا تخاطب مباشرة الوحدة uAppManager ، ويجب أن لا تعلم عنها شيئا. قهي مثل العبد الأعمى ينفذ الأمر و لا يعلم من يأمره. (افترض أن هناك برنامج آخر لمبرمج آخر وبريد أن يستفيد من خدمات هذه الوحدة.)
نفس الكلام ينطبق على الوحدة uAppManager ، فهي تستخدم مباشرة أوامر خاصة باندي وتتخطى الوحدة uNetManager التي يفترض أن تكون المسئول الوحيد عن أمور الربط والاتصال. كما أنها تخاطب مباشرة الشاشة الرئيسية في وحدة D4A_Serverfrm.
الوحدات uNet_Broad و uMisc باعتبارهما خاصتان باندي هل يمكن ضمهما إلى وحدة uNet_INDY.
طبعا نفس المبادئ السابقة تعمم على باقي الجوانب كقواعد البيانات.
سؤال: هل يمكن رفع مستوى التنظيم (أو التعقيد!) بجعل أوامر وحدة uNetManager ضمن صنفية نسميها TNetManager_Server
أخيرا، المبرمج هو صاحب الكلمة العليا، لتنفيذ ما يراه مناسب في الوقت الذي يراه مناسب.
وتقديري مرة أخرى.