درک پیاده سازی کلاس در دلفی ؟؟!!

[Modifier]

سلام
من بیشتر با سی شارپ کار کردم ...
بنا به دلایلی باید با دلفی کار کنم تا مدت ها ...
من توی سی شارپ یکسری کدهای آماده برای خودم ساخته بودم که کارهامو زود راه می انداخت...بخصوص توی کار با دیتابیس...

میخوام نمونه اون کدها رو توی دلفی هم پیاده سازی کنم ..

توی سی شارپ مفهوم و روند نوشتم کلاس واقعا خیلی گویا و راحت بود.. براحتی 3لایه پیاده سازی میکردم...
مثلا من توی پروژه هام همیشه سه تا namespace داشتم (presentaion layer,BLL,DAL) و ...

مفاهیم خیلی روشن بودن ...

ولی حالا ... :عصبانی++: واقعا داره اشکم در میاد :گریه:

چندتا سوال : آیا توی دلفی unit ها کار namespace های توی سی شارپ رو انجام میدن ؟
توی سی شارپ namespace عملا مثل دلفی فایل نداشت در اصل یک class Lib بود که ایجاد میکردیم و بعد به طور جداگانه فایل های کلاس رو میساختیم و یکی یکی اونها رو پیاده سازی میکردیم...

توی سی شارپ مثلا اگه میخواستم یک Inteface بسازم توی یک فایل جدا میساختم... ولی حالا توی دلفی باید توی یک unit بسازم...که عملا ما از unit ارث بری نمیکنیم...
و ... و ... و ...

من کارهایی که میخوام بکنم رو راه حلاشو بلدم ... با مفاهیم شی گرایی هم آشنا هستم ...
فقط میخوام یه نفر Start شروع رو تو مخم بزنه ...که روندش دستم بیاد...

در ضمن :
چرا توی دلفی برای نوشتن برنامه های چند لایه میان از component استفاده میکنن...؟؟؟
( RemObjects SDK,DataSnap )
واقعا این موضوع هم منو خیلی گیج کرده و خیلی سوال دارم ....

ممنون...
یاعلی.

[Felony]

چندتا سوال : آیا توی دلفی unit ها کار namespace های توی سی شارپ رو انجام میدن ؟
توی سی شارپ namespace عملا مثل دلفی فایل نداشت در اصل یک class Lib بود که ایجاد میکردیم و بعد به طور جداگانه فایل های کلاس رو میساختیم و یکی یکی اونها رو پیاده سازی میکردیم...
تقریبا ، تو دلفی داخل یونیت ها کلاس ها ، توابع و ... معرفی و پیاده سازی میشن ، حالا ممکنه این یونیت رو کاربر خودش بسازه یا قبلا توسط خود دلفی تعریف شده باشه ( مثل کتابخانه های استاندارد دلفی = Windows, Classes , SysUtils و ... )


توی سی شارپ مثلا اگه میخواستم یک Inteface بسازم توی یک فایل جدا میساختم... ولی حالا توی دلفی باید توی یک unit بسازم...که عملا ما از عدهف ارث بری نمیکنیم...
منظورتون از هدف چیه ؟ شما میتونید تو پیاده سازی کلاستون از هر کلاس دیگه ای که قبلا نوشته شده باشه و موجود باشه ارث بری کنید ، مثلا :
Type
MyButton= Class(TButton);

[tdkhakpur]

توی سی شارپ مثلا اگه میخواستم یک Inteface بسازم توی یک فایل جدا میساختم... ولی حالا توی دلفی باید توی یک unit بسازم...که عملا ما از عدهف ارث بری نمیکنیم...

میتوانید مانند سی شارپ بدون اینکه از کلاش دیگه ای مشتق بگیرید کلاس ریشه داشته باشید.


MyClass = class
private
public
end;



در ضمن :
چرا توی دلفی برای نوشتن برنامه های چند لایه میان از component استفاده میکنن...؟؟؟
( RemObjects SDK,DataSnap )


خب کامپوننت مثل توابع اماده میمونه فقط تفاوتش این هست که در این نوع توابع باید پارامترها را دستی به تابع قید کنید ولی به کامپوننت بصورت ویژال میدید تا ایم مقادیر موقع اجرا برنامه سر جای خودشان قرار بگیره.
در ضمن کامپوننتها به دلیل داشتن propery میتوانند بسیار از تغیراتی را که در یکی از پارامترها رخ میده در کل کلاس اعمال کنند.

[Modifier]

توی سی شارپ مثلا اگه میخواستم یک Inteface بسازم توی یک فایل جدا میساختم... ولی حالا توی دلفی باید توی یک unit بسازم...که عملا ما از unit ارث بری نمیکنیم...
و ... و ... و ...

ممنون...
یاعلی.

ببخشید این قسمت رو اصلاح کردم ...شرمنده...

[Modifier]

تقریبا ، تو دلفی داخل یونیت ها کلاس ها ، توابع و ... معرفی و پیاده سازی میشن ، حالا ممکنه این یونیت رو کاربر خودش بسازه یا قبلا توسط خود دلفی تعریف شده باشه ( مثل کتابخانه های استاندارد دلفی = Windows, Classes , SysUtils و ... )


منظورتون از هدف چیه ؟ شما میتونید تو پیاده سازی کلاستون از هر کلاس دیگه ای که قبلا نوشته شده باشه و موجود باشه ارث بری کنید ، مثلا :
Type
MyButton= Class(TButton);

ممنون از صحبتتتون ولی من جای دیگه ای گیر کردم و دستم جلو نمیره...

یه مثال میزنم...یه package میخوایم بنویسم که توش یکسری کلاس داریم برای کار با دیتابیس...
مثلا اسم package ما DBTools هست ...

اگه توی سی شارپ بخوایم بنویسیم DBTools میشه یه namespace و کلاس ها به اون اضافه میشن ... اگر Interface نیاز داشته باشه اضافه میکنیم و همین طورAbstract Class و ...

توی دلفی چطور اینو پیاده سازی میکنن...

آیا همهشو میریزن توی یه Unit به نام DBTools و ....

؟؟؟!!!

[Modifier]

میتوانید مانند سی شارپ بدون اینکه از کلاش دیگه ای مشتق بگیرید کلاس ریشه داشته باشید.


MyClass = class
private
public
end;

من زیاد مشکل با مفاهیم اصولی شی گرایی ندارم البته نمیگم که خیلی میدونم ولی اااااااااای یه چیزایی میدونیم ... ولی توی دلفی یکم گیج میخورم چون یکم از قواعدی که تا حالا خوندم و نوشتم متفاوته ... به مثالی که توی پست قبل زدم توجه کیند ... شما اون رو چطور پیاده سازی میکنید ...؟


خب کامپوننت مثل توابع اماده میمونه فقط تفاوتش این هست که در این نوع توابع باید پارامترها را دستی به تابع قید کنید ولی به کامپوننت بصورت ویژال میدید تا ایم مقادیر موقع اجرا برنامه سر جای خودشان قرار بگیره.
در ضمن کامپوننتها به دلیل داشتن propery میتوانند بسیار از تغیراتی را که در یکی از پارامترها رخ میده در کل کلاس اعمال کنند.

خب مشکل من همینه ...
من نمیفهمم لایه BLL کجاست .. DAL کجاست ... ؟ چون خودم اون ها رو نساختم ...

اصلا چرا کامپوننت مگه نوشتن لایه ها خیلی سخته !!!!!!!؟

....
:گیج::گیج::گیج::گیج:


یه سوال دیگه :

آیا اصولیه که هم Interface و Abstaract Class و کلاس ریشه و فرزندان و ... رو در یک Unit آورد ؟

[vcldeveloper]

چرا توی دلفی برای نوشتن برنامه های چند لایه میان از component استفاده میکنن...؟؟؟
( RemObjects SDK,DataSnap )
DataSnap بخشی از کتابخانه استاندارد دلفی هست، همانطور که WPF یا WCF و غیره بخشی از کتابخانه استاندارد دات نت هستند. RemObjects SDK یک کتابخانه جدا هست که توسط شرکت RemObjects توسعه داده میشه، و می تونید اون رو تقریبا معادل .NET Remoting در نظر بگیرید. از RemObjects SDK زیاد استفاده میشه، چون هم امکانات بیشتری از DataSnap دلفی داره، و هم شرکتش یکی از Technology Partner های قوی شرکت سازنده دلفی محسوب میشه. در واقع Delphi Prism (نسخه دات نت دلفی) رو همین شرکت RemObjects میسازه، و شرکت سازنده دلفی آن را به اسم خودش میفروشه. همچنین، RemObjects SDK علاوه بر دلفی، نسخه های مربوط به دات نت و Lazarus هم داره که با هم سازگار هستند.

توسعه کتابخانه دلفی با استفاده از کامپوننت هایی که خودتون می نویسید یا کامپوننت هایی که دیگران می نویسند، یک امر بسیار رایج هست.



توی سی شارپ مفهوم و روند نوشتم کلاس واقعا خیلی گویا و راحت بود.. براحتی 3لایه ÷یاده سازی میکردم...
مثلا من توی پروژه هام همیشه سه تا namespace داشتم (presentaion layer,BLLm,DAL) و ...

مفاهیم خیلی روشن بودن ...

ولی حالا ... :عصبانی++: واقعا داره اشکم در میاد :گریه:

چندتا سوال : آیا توی دلفی unit ها کار namespace های توی سی شارپ رو انجام میدن ؟
مفاهیم اینچنینی در دلفی و #C خیلی با هم تفاون چندانی ندارند، چون مفاهیم اولیه مربوط به کتابخانه کلاس های دات نت از دلفی گرفته شده.

unit ها در دلفی دقیقا معادل namespace ها در دات نت نیستند، ولی به آنها شباهت دارند. یک unit میتونه شامل یک یا چند کلاس و interface باشه، و برای استفاده از اون کلاس ها یا interfaceها، باید نام یونیت مربوطه در بخش uses مربوط به یونیت استفاده کننده، درج بشه. شما می تونید هر کدوم از اون لایه های مدنظرتون رو در یک unit تعریف و پیاده سازی کنید، یا اینکه اگر حجم شان زیاد هست، هر لایه را در چند یونیت تعریف کنید. برای ایجاد حالتی مشابه namespaceها در دات نت، دلفی از دات (.) در نام unit ها پشتیبانی میکنه، و می تونید مثلا یونیت هایی مثل این داشته باشید:
Presentation.UserInput
Presentation.Reports.UsersList
BusinessLogic.FieldValidation

حالا شما این یوینت ها رو می تونید با ذکر نامشان در uses هر یونیت دیگه، در اون یونیت استفاده کنید. یا میتونید اینها را در یک Package قرار بدید، و از طریق اون Package، کلاس های آنها را در اختیار سایر برنامه نویسان قرار بدید (به صورت کامپوننت یا کلاس های غیر کامپوننت).


توی سی شارپ مثلا اگه میخواستم یک Inteface بسازم توی یک فایل جدا میساختم... ولی حالا توی دلفی باید توی یک unit بسازم...که عملا ما از unit ارث بری نمیکنیم...
یونیت چیزی نیست که ازش ارث ببرید، همانطور که در دات نت هم از namespace ارث نمی برید. interface یا abstract class یا هر Data Type دیگه ایی که میخواید را می تونید در یک یا چند یونیت تعریف کنید. در سایر یونیت ها برای دسترسی به آنها، باید نام اون یونیت را به لیست uses یونیت استفاده کننده، اضافه کنید. مثلا اگر شما یک Interface با نام IMyInterface در یونیتی با نام MyUnit تعریف کردید، و حالا میخواید این Interface را در یک کلاس که در یونیت MyImpUnit تعریف شده، پیاده سازی کنید، باید ابتدا اسم یونیت MyUnit را به لیست uses یونیت MyImpUnit اضافه کنید؛ سپس می تونید در کلاس تان آن اینترفیس را پیاده سازی کنید.

[vcldeveloper]

اصلا چرا کامپوننت مگه نوشتن لایه ها خیلی سخته !!!!!!!؟
کامپوننت ها در دلفی چیزهای عجیب و غریبی نیستند، بلکه یک یا چند کلاس هستند که برخی از قابلیت های کتابخانه کلاس های دلفی را توسعه دادند. در اون مثال شما، RemObjects SDK وظیفه ایجاد یک Communication Channel رو بین لایه های مختلف برعهده داره. گفتم؛ مثل NET Remoting. حالا شما تصور کنید اگر قرار بود Remoting رو در دات نت خودتون بنویسید، چقدر کار می برد؟ البته RemObjects SDK در دلفی یکی از گزینه ها برای اون کار هست. همانطور که گفتم، در کتابخانه استاندارد دلفی DataSnap هم همان وظیفه را برعهده داره. غیر از اینها، کامپوننت های مجانی و پولی مختلفی هستند که آنها هم همین کار را انجام میدند. این دیگه انتخاب برنامه نویس هست که کدام را استفاده کنه. در دلفی یا بسیاری از سایر محیط های توسعه، اینطور نیست که همه چیز را یک شرکت مثل مایکروسافت در اختیار برنامه نویس قرار بده. شرکت سازنده یک بستر فراهم میکنه، برنامه نویسان و شرکت های کامپوننت سازی از آن بستر برای ارائه قابلیت های مختلف به سایر برنامه نویسان استفاده می کنند، و آن را توسعه میدند.



من نمیفهمم لایه BLL کجاست .. DAL کجاست ... ؟ چون خودم اون ها رو نساختم ...
RemObjects SDK فقط Communication Channel و Interface بین لایه ها را مشخص میکنه. اون چیزی که مدنظر شما ست، RemObjects DataAbstract هست، که روی RemObjects SDK سوار میشه، و با ارائه یک Schema، سعی میکنه Data Access Layer رو از سایر بخش ها جدا کنه، و Business Ruleها رو از طریق یک زبان اسکریپتی از برنامه نویس دریافت میکنه و در Schema اعمال میکنه.

[Modifier]

واقعا ممنون آقای کشاورز ... انشاالله روز به روز به علم و عزتتون افزوده بشه ...
فعلا نیاز دارم به مدتی فکر و مطالعه و تست و ... تا ذهنم باز تر بشه ...

ولی سولات کوچیک دیگه ای هم دارم ...

آیا RemObjects SDK توی دلفی 2010 کارایی داره ؟


سعی میکنه Data Access Layer رو از سایر بخش ها جدا کنه....آیا میشه کلاس ها و متدهای نوشته شده توسط خودم رو که برای کار با DB هست رو به اون معرفی کنم ... ؟
یا اینکه ما باید بهش یه ConnectionString بدیم و ... و .... و .... و خودش کار ها رو میکنه ...؟
آیا خودش به Db متصل میشه یا در کنارش باید از Ado استفاده کرد ....؟

Business Ruleها رو از طریق یک زبان اسکریپتی از برنامه نویس دریافت میکنه و در Schema اعمال میکنه. مثلا من توی یه برنامه حسابداری محاسبات مربوط به تراز آزمایشی رو توی BLL انجام میدم ... آیا منظورتون اینه که بهش میگیم که در چه این موقع بیا از این تابع یا متد استفاده کن ؟


آیا اصولیه که هم Interface و Abstaract Class و کلاس ریشه و فرزندان و ... رو در یک Unit آورد ؟


وقتی سیستمی رو تحلیل و طراحی میکنیم... با استفاده از زبان و مفاهیم UML...
معمولا به سه نمونه کلاس میرسیم ...(boundry,Control,Entity)...
تا فاز Analysis مشکلی نیست ...
ولی وقتی میخواهیم اون رو design کنیم باید با توجه به امکانات زبان برنامه نویسیمون طراحی بشه ...

حال...
من یه سیستم رو به صورت سه لایه آنالیز کردم ... و میخوام طراحیه اون بر اساس قابلیت های دلفی و ساختار های مورد استفاده در دلفی باشه ...
مثلا اگه بخوام با کامپوننت های مذکور کار کنم باید با ساختار و روند کار شون و حدالقل کلاس های ریشه ای مورد استفادشون آشنا باشم ...که بدونم چطور بین لایه ها داده هام حرکت میکنند و ...

2 سوال :

آیا آیا نیازی به دانستن اینها هست تا چه حد ؟

چطور آشنا بشم؟ آیا ساختارشون در دسترس هستند؟اصلا صرف میکنه ؟(میشه مختصری توضیح بدین)

[vcldeveloper]

آیا RemObjects SDK توی دلفی 2010 کارایی داره ؟
بله.


آیا میشه کلاس ها و متدهای نوشته شده توسط خودم رو که برای کار با DB هست رو به اون معرفی کنم ... ؟
بله.


یا اینکه ما باید بهش یه ConnectionString بدیم و ... و .... و .... و خودش کار ها رو میکنه ...؟
شما می تونید براش Connection تعریف کنید، و سپس Datasetهایی رو تعریف کنید که از طریق کوئری های مختلف داده ها شون از بانک دریافت می کنند. این لایه ممکنه از هر ابزاری برای اتصال به بانک استفاده کنه. هدف این هست که اولا تفاوت های بانک های اطلاعاتی مختلف از نظر پیاده سازی روی سایر لایه های برنامه اثر نزاره، و ثانیا سایر لایه های برنامه وابسته به ساختار بانک اطلاعاتی نباشند.

همچنین، از اون جایی که این سرور بین سرور بانک اطلاعاتی و کلاینت ها قرار میگیره، مکانیزم های مختلفی برای بررسی داده های رد و بدل شده بین سرور و کلاینت فراهم میکنه. هم میتونه اعتبارسنجی داده ها را در سمت سرور انجام بده، و هم در سمت کلاینت. این کنترل ها را هم میتونه از طریق کد دلفی انجام بده، و هم از طریق اسکریپت های JavaScript که در داخل فایل Schema ذخیره میشند، و تغییر در آنها نیاز به کامپایل مجدد برنامه نداره.

از طرف دیگه، چون بر روی RemObjects SDK سوار هست، میشه کلاس هایی در سمت سرور تعریف کرد، و آنها را در اختیار کلاینت ها برای تعامل با سرور قرار داد.


مثلا اگه بخوام با کامپوننت های مذکور کار کنم باید با ساختار و روند کار شون و حدالقل کلاس های ریشه ای مورد استفادشون آشنا باشم ...که بدونم چطور بین لایه ها داده هام حرکت میکنند و ...

آیا آیا نیازی به دانستن اینها هست تا چه حد ؟
باید حداقل با امکاناتی که به شما ارائه میشه، و چگونگی استفاده از این امکانات آشنا باشید.


چطور آشنا بشم؟ آیا ساختارشون در دسترس هستند؟
اگر بخواید از DataSnap دلفی استفاده کنید، درباره اش در Help دلفی و در کتب دلفی توضیح داده شده. سورس کدش هم مثل سورس سایر بخش های کتابخانه دلفی در دسترس هست.

اگر بخواید از RemObjects DataAbstract استفاده کنید، در سایتش یک Wiki (http://wiki.remobjects.com/wiki/Why_Data_Abstract%3F) وجود داره که حاوی مطالب و مقالات متعدد درباره آن هست. علاوه بر اون، به همراه خودش تعداد زیادی Demo نصب میشه. سورس کدش هم در صورتی که آن را خریداری کنید (یا از نسخه های کرک شده همراه با سورس استفاده کنید) در دسترس هست.

[vcldeveloper]

آیا اصولیه که هم Interface و Abstaract Class و کلاس ریشه و فرزندان و ... رو در یک Unit آورد ؟
بستگی به نوع استفاده داره. تعریف کلاس های مرتبط با هم در یک یونیت مزیت هایی داره؛ مثل دسترسی اون کلاس ها با بخش های private هم، یا عدم نیاز به استفاده از نام یونیت های مختلف در بخش uses یونیت های استفاده کننده. اما متناسب با نوع استفاده، میتونه مضر هم باشه، مثلا بزرگ شدن بیش از حد یک یونیت، یا در شرایطی که باید رابط Interface در اختیار بخش های مختلف یک نرم افزار یا سایر نرم افزارها برای پیاده سازی قرار بگیره، ارائه پیاده سازی هایی از اون Interface در داخل همون یونیت غیر ضروری هست.

در هر حال، این مسئله بستگی به نوع کار شما داره.

[BORHAN TEC]

سلام

من این منابع را برای یادگیری DataSnap و RemObjects SDK به شما معرفی میکنم.
برای یادگیری DataSnap میتونید به این منابع مراجعه کنید:

نسخه پی دی اف: http://www.embarcadero.com/images/dm/technical-papers/delphi-2010-wp-datasnap-091016.pdf
نسخه ویدیویی: http://www.bobswart.nl/DataSnap2010

آموزش RemObjects SDK(همراه با نکاتی برای کار با دیتابیس ها):
نسخه ویدویی: http://www.bobswart.nl/CodeRageIV

[Modifier]

سلام
چندتا سوال :
توی تعریف بعضی کلاسها یا Interface ها دیدم :

ITools = class;
چرا به اینگونه تعریف نکرده اند:

ITools = Tclass;

بعد از اینکه به صورت زیر تعریف کردند :

ITools = class;
به دین صورت عمل شده :

TTools = class of ITools
چرا اینگونه عمل نشده :

TTools = ITools;

[vcldeveloper]

توی تعریف بعضی کلاسها یا Interface ها دیدم :

ITools = class;

این یعنی Forward Declaration؛ در مواردی کلاس مربوطه مورد نیاز یک یا چند کلاس دیگه در همان یونیت هست، ولی اون کلاس ها قبل از اون کلاس تعریف شدند، پس این کلاس از نظرشان ناشناخته هست. در همچنین مواردی، با این نوع تعریف قبل از تعریف اون کلاس ها، به کامپایلر می فهمونید که این کلاس وجود داره، و تعریف کاملش در ادامه یونیت خواهد آمد.


به دین صورت عمل شده :

TTools = class of ITools

این یعنی Class Reference؛ یک Class Reference اشاره کننده ایی به خودِ کلاس (نه یک شی از کلاس) هست. Class Reference ها کاربردهای خاصی دارند، مثل ایجاد شی از یک خانواده از کلاس ها، بدون اینکه نوع دقیق کلاس در زمان اجرا مشخص باشه.

[Modifier]

یعنی وقتی این چنین مینویسیم :

type

IMyInterface = class;
TMyClass = class of IMyInterface;

IMyInterface = class;
private
protected
public
constructor Create();virtual;
end;

میخوایم یکسری تعاریف اولیه مربوط به کلاس رو معرفی کنیم که فکر کنم برای خواناتر بودن و داشتن دید کلی در مورد اون چیزی که در اوامه توی قسمت Implemetaion خواهد آمد میباشد ؟ درسته ؟

و اگر نخوایم اینگونه باشد باید اینطور تعریف کنیم :

type

IMyInterface = class;
private
protected
public
constructor Create();virtual;
end;

TMyClass = class of IMyInterface;

درسته ؟

تا اونجایی که متوجه شدم کد زیر :

TTools = class of ITools
برای ساختن DLLبه صورتی که در حالت پویا فراخوانی شود لازم است.

[vcldeveloper]

میخوایم یکسری تعاریف اولیه مربوط به کلاس رو معرفی کنیم که فکر کنم برای خواناتر بودن و داشتن دید کلی در مورد اون چیزی که در اوامه توی قسمت Implemetaion خواهد آمد میباشد ؟ درسته ؟
نه، مفهومشون همون چیزی هست که در بالا توضیح دادم. برفرض اگر شما کلاس A و B دارید، و کلاس A در داخل خودش از کلاس B استفاده می کند، و کلاس B هم در داخل خودش ارجاعی به کلاس A داشته باشه، اون وقت هر دوی این کلاس ها به هم وابسته هستند. اگر شما اول کلاس A را تعریف کنید، کامپایلر ایراد میگیره که کلاس B را نمیشناسه، اگر هم کلاس B را اول تعریف کنید، کامپایلر ایراد میگیره که کلاس A را نمی شناسه! اون وقت هست که یکی از اینها را Forward declare می کنید، تا کامپایلر متوجه بشه که این کلاس وجود داره، و تعریفش در ادامه خواهد آمد.


برای ساختن DLLبه صورتی که در حالت پویا فراخوانی شود لازم است.
نه، ساخت DLL یا لود پویای یک DLL نیازی به class reference نداره. یک class reference یک اشاره گر به ساختار یک کلاس بخصوص هست. اصلی ترین کاربردشان هم همون ساخت اشیاء پویا از یک خانواده از کلاس ها، بدون دانستن نوع دقیق شی ساخته شده هست. نمونه استفاده از اونها رو می تونید در متد Application.CreateForm ببینید، که میتونه هر فرمی از خانواده کلاس های مشتق شده از TForm را ایجاد کنه.

[Modifier]

با توجه به این نکته که اگر از Unit ی که درون آن Interface هایی تعریف شده است استفاده کنیم ، باید همه Interface ها رو پیاده ساری کنیم...
آیا بهتر نیست که هر Interface دورن یک Unit جدا نوشته شود ؟

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

آیا این منطقیه که از یک Unit که درون آن Interface معرفی شده ، در داخل یک Unit دیگر که آن هم قرار Interface ی دیگر رو معرفی کنه استفاده کنیم؟ (بهتر اینطور بگم Interface اول به نوعی ریشه Interface های دیگر است بدین معنی که Interface ها دارای سلسله مراتب هستند : پدر و فرزند)

[Modifier]

اصلی ترین کاربردشان هم همون ساخت اشیاء پویا از یک خانواده از کلاس ها، بدون دانستن نوع دقیق شی ساخته شده هست.
یعنی یکسری از اشیاء مختلف که از یک خانواده هستند یا بهتر بگم در کلاس مورد نظر که در طرف راست دستور زیر میباشد اشتراک دارند را میسازیم..

TSampleClass = class of TPublicClass
و فکر کنم اینجاست که Polymorphism بکار میره ؟

مثلا :

Procedure TForm1.CreateClass(Class :TSampleClass);
Begin
...
End;
که تابع بالا برایش مهم نیست که کلاسی که برای نمونه سازی برایش فرستاده میشود از چه نوعی هست ، فقط تنها چیزی که باید باشد و این را میداند این است که : پارامتر Class از نوع TSampleClass است که آن هم از نوع TPublicClass میباشد که با توجه به نشانی کلاسی که داخل پارامتر میباشد constructor مربوط را فراخوانی میکند (پلی مورفیک).

آیا برداشت من درسته ؟

حالا یک نکته مبهم دارم :
یعنی برای مثال :

اگر کلاس فرستاده شده TButton باشد ، constructor مربوط به آن را صدا میزند و اگر نوع دیگری به همین صورت عمل میکند...؟
یا اینکه contructor ی که در TPublicClass هست رو صدا میزند چون در همه کلاس هایی که میخواهد از روی آن نمونه سازی بشه مشترکه ؟

از این 2 نوعی که برای فراخوانی constructor در حالت Polymorphism گفتم کدام درسته ؟

[vcldeveloper]

با توجه به این نکته که اگر از Unit ی که درون آن Interface هایی تعریف شده است استفاده کنیم ، باید همه Interface ها رو پیاده ساری کنیم...
آیا بهتر نیست که هر Interface دورن یک Unit جدا نوشته شود ؟
الزامی به پیاده سازی Interface های تعریف شده در یک یونیت نیست. زمانی پیاده سازی یک Interface الزامی هست که کلاسی خودش مستقیما پیاده سازی یک Interface را در تعریف خودش ذکر کند. پس اگر شما 1000 اینترفیس هم در یک یونیت داشته باشید، نیازی به پیاده سازی آنها ندارید.



آیا این منطقیه که از یک Unit که درون آن Interface معرفی شده ، در داخل یک Unit دیگر که آن هم قرار Interface ی دیگر رو معرفی کنه استفاده کنیم؟
use کردن یک یونیت در داخل یونیت دیگه، موجب ارث بری کلاس ها یا اینترفیس های موجود در یونیت دوم از یونیت اول نمیشه.


بهتر اینطور بگم Interface اول به نوعی ریشه Interface های دیگر است بدین معنی که Interface ها دارای سلسله مراتب هستند : پدر و فرزند
اینترفیس ها می تونند به صورت ساختار سلسله مراتبی تعریف بشند، و از هم ارث ببرند. در دلفی، پدر همه اینترفیس ها IInterface هست، و همه اینترفیس ها از این اینترفیس ارث می برند.


یعنی یکسری از اشیاء مختلف که از یک خانواده هستند یا بهتر بگم در کلاس مورد نظر که در طرف راست دستور زیر میباشد اشتراک دارند را میسازیم..
بله.


و فکر کنم اینجاست که Polymorphism بکار میره ؟
بله، یکی از مصادیق کاربرد Polymorphism هست.


اگر کلاس فرستاده شده TButton باشد ، constructor مربوط به آن را صدا میزند و اگر نوع دیگری به همین صورت عمل میکند...؟
یا اینکه contructor ی که در TPublicClass هست رو صدا میزند چون در همه کلاس هایی که میخواهد از روی آن نمونه سازی بشه مشترکه ؟
constructor همون کلاس TButton فراخوانی میشه. البته دقت داشته باشید که کلاسی که به اون تابع پاس می کنید باید از خانواده TPublicClass فرضی که در اون مثال استفاده کردید، باشه؛ یعنی یا باید خودِ TPublicClass باشه، یا یکی از کلاس های مشتق شده از آن، و البته constructor اش هم virtual باشه، نه اینکه class of TPublicClass تعریف کنید، ولی TButton را به اون تابع پاس بدید.

[Modifier]

وقتی من در داخل IMyInterface چند Function یا Procedure تعریف میکنم و با استفاده از دایرکتیوهای Virtual و Abstract مشخص میکنم که اینها Pure Virtual Abstract Methode هستند و بعد این ها رو در داخل TMyClass پیاده سازی میکنم و با دایرکتیو Override نشانه گذاری میکنم.
حالا..
وقتی که من از TMyClass نمونه سازی میکنم دسترسی به Function یا Procedure هایم ندارم!
چرا ؟
بعد من برای آنها یک Property تعریف میکنم ، که باعث میشه که دسترسی پیدا کنم!
چرا؟
تا اونجایی هم که متوجه شدم به Access Modifier ها هم مربوط نمیشه البته منظورم Protected و Public است.

آیا باید برای همه Function ها و Procedure ها یک Property تعریف کرد ؟

[vcldeveloper]

وقتی من در داخل IMyInterface چند Function یا Procedure تعریف میکنم و با استفاده از دایرکتیوهای Virtual و Abstract مشخص میکنم که اینها Pure Virtual Abstract Methode هستند و بعد این ها رو در داخل TMyClass پیاده سازی میکنم و با دایرکتیو Override نشانه گذاری میکنم.
حالا..
وقتی که من از TMyClass نمونه سازی میکنم دسترسی به Function یا Procedure هایم ندارم!
چرا ؟
بعد من برای آنها یک Property تعریف میکنم ، که باعث میشه که دسترسی پیدا کنم!
چرا؟
تا اونجایی هم که متوجه شدم به Access Modifier ها هم مربوط نمیشه البته منظورم Protected و Public است.
لطفا یک نمونه کد قرار بدید که منظورتون رو برسونه.

[Modifier]

مربوط به Interface :

type
IDb = class
private
protected
function GetConnectionString(): String; virtual; abstract;
public
end;
implementation
{IDb}
end.

مربوط به کلاسی که Interface رو پیاده سازی میکند :

type
TAdoDb = class(IDb)
private
protected
function GetConnectionString(): String; override;
public
property ConnectionString: String read GetConnectionString;
end;
implementation
{TAdoDb}
function TAdoDb.GetConnectionString(): String;
begin
Result := 'Empty';
end;

مربوط به استفاده و نمونه سازی از کلاس :

type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
AdoDbTools: TAdoDb;
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
begin
AdoDbTools := TAdoDb.Create();
Form1.Caption := AdoDbTools.ConnectionString;
end;

اگر من برای ConnectionString خصوصیت تعریف نکنم امکان دسترسی به متد مربوط بهم داده نمیشه ، البته با Property هم دسترسی غیرمسقیم هست.

مابقی توضیحات :

وقتی من در داخل IMyInterface چند Function یا Procedure تعریف میکنم و با استفاده از دایرکتیوهای Virtual و Abstract مشخص میکنم که اینها Pure Virtual Abstract Methode هستند و بعد این ها رو در داخل TMyClass پیاده سازی میکنم و با دایرکتیو Override نشانه گذاری میکنم.
حالا..
وقتی که من از TMyClass نمونه سازی میکنم دسترسی به Function یا Procedure هایم ندارم!
چرا ؟
بعد من برای آنها یک Property تعریف میکنم ، که باعث میشه که دسترسی پیدا کنم!
چرا؟
تا اونجایی هم که متوجه شدم به Access Modifier ها هم مربوط نمیشه البته منظورم Protected و Public است.

آیا باید برای همه Function ها و Procedure ها یک Property تعریف کرد ؟

[vcldeveloper]

مربوط به کلاسی که Interface رو پیاده سازی میکندشما Interface تعریف نکردید، بلکه یک کلاس تعریف کردید! اون IDb یک کلاس هست. اگر میخواید اینترفیس باشه، باید بنویسید:


IDb = interface
...
end;

در ضمن، در یک اینترفیس تعریف توابع به صورت abstract معنی نداره؛ چون توابع Interface پیاده سازی ندارند، و پیاده سازی آنها توسط کلاس های مورد نظر صورت میگیره.

[Modifier]

در ضمن، در یک اینترفیس تعریف توابع به صورت abstract معنی نداره؛ چون توابع Interface پیاده سازی ندارند، و پیاده سازی آنها توسط کلاس های مورد نظر صورت میگیره.
بله ،وقتی که کلاس تبدیل به Interface شد، دیگه اجازه استفاده از Virtual و Abstract بهم نداد و شد :

type
IDb = Interface
function GetConnectionString(): String;
procedure SetConnectionString(const value: String);
end;

[Modifier]

تابع زیر که در Sysutils.pas تعریف شده چه کار میکنه ؟ تا اونجایی که فهمیدم مرتبط با Interface است و نشان دهنده متدها یا اجزا دیگر دورن Interface است یا ...

function Supports(const Instance: IInterface; const IID: TGUID;...

این قضیه استفاده از Guid چیه ؟من ابتدا استفاده نکردم و مشکلی نبود ولی جایی خوندم که باید استفاده کنم!

آیا بهتره برای استفاده از function ها یا procedure های پیاده سازی شده از property استفاده کنم یا بجای اینکه اون ها رو Protected تعریف کنم ، public تعریف کنم و بطور مستقیم استفاده کنم ؟

وقتی که میخوام کلاسی رو که ساختم رو از حافظه خارج کنم و از بینش ببرم فقط اجازه Free کردن بهم میده ، یعنی مجبورم از یونیت classes استفاده کنم تا بشه از FreeOnRelease استفاده کرد ؟

به طور کلی توی پیاده سازی کلاس ها و Interface ها توی Unit های مربوطه چه Unit های دیگری رو باید اضافه کرد ؟ (حدالقل ها)

[vcldeveloper]

تابع زیر که در Sysutils.pas تعریف شده چه کار میکنه ؟ تا اونجایی که فهمیدم مرتبط با Interface است و نشان دهنده متدها یا اجزا دیگر دورن Interface است یا ...
بررسی میکنه که آیا یک نمونه شی از اینترفیس مورد نظر پشتیبانی میکنه یا نه.


این قضیه استفاده از Guid چیه ؟من ابتدا استفاده نکردم و مشکلی نبود ولی جایی خوندم که باید استفاده کنم!
قبلا در مقاله ایی درباره Interface ها در دلفی، در تالار مقالات همین بخش دلفی توضیح دادم.


وقتی که میخوام کلاسی رو که ساختم رو از حافظه خارج کنم و از بینش ببرم فقط اجازه Free کردن بهم میده
خب باید چه اجازه ایی بده؟ Free کلاس ساخته شده را از حافظه خارج میکنه.


به طور کلی توی پیاده سازی کلاس ها و Interface ها توی Unit های مربوطه چه Unit های دیگری رو باید اضافه کرد ؟ (حدالقل ها)
هر یونیتی که از داده هایش استفاده کردید.



آیا بهتره برای استفاده از function ها یا procedure های پیاده سازی شده از property استفاده کنم یا بجای اینکه اون ها رو Protected تعریف کنم ، public تعریف کنم و بطور مستقیم استفاده کنم ؟
این سوال برای من مفهوم نیست. property یک داده مرتبط با کلاس یا شی هست که یا مستقیما با یک فیلد متناظر در اون کلاس یا شی کار میکنه، یا اینکه برای خواندن و نوشتن خودش از توابعی در کلاس یا شی استفاده میکنه.

در ضمن، لطفا همه سوالات خودتان را به صرف اینکه درباره کلاس و اینتفریس هستند، در یک تاپیک مطرح نکنید. الان چندین و چند سوال با موضوعات مختلف در این تاپیک مطرح شدند، و انسجام تاپیک را به هم زدند.

[Modifier]

در ضمن، لطفا همه سوالات خودتان را به صرف اینکه درباره کلاس و اینتفریس هستند، در یک تاپیک مطرح نکنید. الان چندین و چند سوال با موضوعات مختلف در این تاپیک مطرح شدند، و انسجام تاپیک را به هم زدند.
چشم، حتما جناب کشاورز...
راستش من قصد داشتم که توی این تاپیک یکسری مباحث کلی در مورد پیاده سازی کلاس یا بهتر بگم شئی گرایی در دلفی بیان بشه و یاد بگیرم. در ابتدای کار خب به معنای واقعی چیزی نمیدونستم و به کمک شما و دوستان یکسری اطلاعات کلی بخصوص در مورد پیاده سازی چند لایه کسب کردم.
در مرحله دوم سعی داشتم و دارم که مباحث کلی در مورد نوشتن Interface و بعد از آن پیاده سازی آن بیان بشه که این موضوع هم به کمک شما تا حد زیادی حل شد. و سعی کردم موضوع از این دو بخش خارج نشه.
و میخوام این دو بخش رو البته بصورت کلی به هم ربط بدم (البته اگه شد) تا بحث تموم بشه.

هر یونیتی که از داده هایش استفاده کردید.

نه منظورم یونیت های ساخته شده ی خودم نیست، بلکه منظورم یونیت های استاندارد دلفیه که در ابتدای کار باید باشند، یعنی کدوم از اون یونیت های استاندارد قبل از همه باید use بشند که خواه نا خواه ازش استفاده خواهد شد یا باید استفاده بشه ؟

این سوال برای من مفهوم نیست. property یک داده مرتبط با کلاس یا شی هست که یا مستقیما با یک فیلد متناظر در اون کلاس یا شی کار میکنه، یا اینکه برای خواندن و نوشتن خودش از توابعی در کلاس یا شی استفاده میکنه.

ممنونم متوجه شدم :لبخندساده:
ولی اینکه میگین "..کلاس یا شی.." یعنی چی؟ خب ما و قتی داریم برنامه مینویسیم از Class یک نمونه میسازیم و استفاده میکنیم پس در اصل ما از شی استفاده میکنیم؟ درست میگم ؟

[vcldeveloper]

نه منظورم یونیت های ساخته شده ی خودم نیست، بلکه منظورم یونیت های استاندارد دلفیه که در ابتدای کار باید باشند، یعنی کدوم از اون یونیت های استاندارد قبل از همه باید use بشند که خواه نا خواه ازش استفاده خواهد شد یا باید استفاده بشه ؟
نیاز به استفاده از یونیتی نیست، چون اینها جزو امکانات پایه ایی دلفی هستند و در یونیت System تعریف شدند. هیچ برنامه یا یونیتی نیاز نداره که یونیت System را use کنه، چون به طور پیش فرض این یونیت در دسترس همه یونیت ها هست.


ولی اینکه میگین "..کلاس یا شی.." یعنی چی؟ خب ما و قتی داریم برنامه مینویسیم از Class یک نمونه میسازیم و استفاده میکنیم پس در اصل ما از شی استفاده میکنیم؟ درست میگم ؟
در اون جمله منظور از داده مرتبط با کلاس، داده هایی هست که به صورت class var تعریف میشند، و منظور از داده های مرتبط با شی هم داده هایی هست که به صورت عادی به عنوان فیلد در داخل یک کلاس تعریف می کنید، و اصطلاحا به آنها instance field گفته میشه. برای استفاده از class var ها نیازی به create کردن یک شی از اون کلاس نیست، در حالی که برای استفاده از instance field ها باید قبلش یک شی از کلاس مربوطه بسازید.