یک تعریف عملی از شیء گرایی و مزایای آن

[eshpilen]

شاید شما هم با بنده هم نظر باشید که باوجود قدیمی بودن این بحث و منابع زیادی که سعی کردن شیء گرایی رو تعریف و بخصوص مزایای اون رو بیان و اثبات و با روشهای دیگر برنامه نویسی مقایسه کنن، بیشتر این مطالب برای خیلی مبتدی ها و حتی حرفه ایها دارای ابهام و دوری از نمودهای عینی هستن. نمیدونم چرا اینطوره! شاید توضیح بعضی چیزها مشکله و شاید اغراق و افراط باعث این امر میشه و شاید موقع توضیح دادن که میشه یادشون میره!!
ولی تازگی توضیحاتی بنظرم رسید که فکر میکنم مفید باشن. هرکس دیگر هم توضیحی داره میتونه بگه تا روشن بشیم.

خب شیء گرایی بنظر من یک چیز ساده و خیلی عینی هست. نیازی نیست مدام توضیح بدیم که بله شیء مثل اشیاء جهان خارجی که مثلا یک میز یا اتومبیل هست و پایه و چرخ داره و گاز و دنده غیره و غیره!! بنظرم این اسم شیء و شیء گرایی فکر آدم رو یخورده زیادی منحرف میکنن و باعث میشن بیهوده به مثالهایی که ذهن شنوندگان رو کم و بیش منحرف میکنن رو بیاریم.

بنظر بنده اساس شیء در برنامه نویسی درواقع مفهومی به این سادگی هست که ما میایم و تمام متغییرها و توابعی رو که مربوط به یک کار خاص یا یکسری کارهای مشابه/هم‌خانواده و وابسته هستن در یک واحد برنامه نویسی که خودش تقریبا میتونه تاحدودی شبیه یک برنامهء مستقل و ایزوله از بقیهء برنامه تصور بشه، بنام کلاس، جمع میکنیم تا کدها تر و تمیز و خوانا بشه و از تداخل اسم متغییرها و توابع بخشها و کارهای دیگر برنامه با هم جلوگیری بشه و مثلا نگران نباشیم اگر از یک متغییر بنام counter در یک الگوریتم برنامه استفاده میکنیم، متغییر دیگری با همون نام در جای دیگری در برنامه که چیز دیگری رو میشماره وجود داشته باشه (درواقع کلاسها بنوعی نقش فضاهای نامی رو هم در سطح دسته بندی واحدهای کاری مختلف عضو یک برنامه ایفا میکنن). شیء گرایی یه چیزایی در همین حد ساده و عینی هست! یک نوع دسته بندی و بصورت قطعه های مجزا درآوردن. ماجولار کردن بخشهای مختلف کدهای برنامه.
موقعی که آدم روی یک کلاس کار میکنه، دیگه با تعداد زیادی از متغییرها و توابع دیگری که مستقیما به عملیات جاری مربوط نیستن در لابلای کدها و الگوریتم و کاربرد مورد مطالعه برخورد نمیکنه و این به تمرکز و سرعت برنامه نویس خیلی کمک میکنه و خیلی کمتر نیاز به جهش های مداوم از روی کدها و متغییرهای نامربوط و جستجو برای موارد مرتبط با موضوع درمیان کدهای برنامه داره. ضمنا یک کلاس رو میشه داد برنامه نویس دیگری بنویسه، و میشه در یک فایل مستقل ذخیره کرد.

این ویژگیها باوجود اینکه بنظر کوچک میان اما بخاطر نیازها و حساسیت و ظرفیت انسان، در عمل خیلی تاثیر گذار هستن.

یکسری ویژگیهای پیشرفته تر هم به کلاسها اضافه شدن که خودشون جای بحث دارن. مثلا اینکه اصول طراحی صحیح اینترفیس کلاسها چیه و Public و Private و غیره چین. اما اینا مسائل بعدی و فرعی هستن. مثل قواعد نامگذاری استاندارد و بدون تداخل قفسه ها و پرونده ها یا کتابها در یک بایگانی یا کتابخانه.

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

فرق زبانهای شیء گرا با زبانهای تابعی (ساخت یافته) فقط در این هست که زبانهای شیء گرا، امکانات فنی لازم برای تسهیل و بهینه سازی فرایند این ماجولار و طبقه بندی کردن کدهای برنامه رو توسط سینتاکس خودشون در اختیار برنامه نویس میذارن. وگرنه ما در یک زبان تابعی هم میتونیم فرضا با استفاده از جمع کردن متغییرها و توابع مستقیما مرتبط، در یک بخش از کد و قرار دادن هرکدوم از این قطعه کدها در یک فایل مجزا و احتمالا همچنین استفاده از قواعد نامگذاری طبقه بندی شده، چیزی کم و بیش با کارایی پایهء برنامه نویسی شیء گرا رو ایجاد کنیم.

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

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

ضمنا یک کلاس میتونه خودش کلاسهای دیگری رو در خودش داشته باشه. این کلاسها هم باوجود اینکه هرکدوم محتوی کدهای یک کار خاص هست ولی حتما در یک سطح بالاتر با هم ارتباط دارن و میتونن مشترکا کار کلی تری رو انجام بدن. مثل طبقه بندی، که مثلا پرونده های املاک منقول رو در یک بخش قفسه میذاریم و پروندهء املاک غیرمنقول رو در بخش دیگه. درواقع اون بخشهای قفسه هم یک کلاس و پروندهء سطح بالاتر محسوب میشن.

خودتون با توجه به این توضیحات قضاوت کنید؛ آیا نیازی به مقایسه با اشیاء جهان خارجی مثل میز و صندلی و اتومبیل بود؟ فکر میکنم اینطور مثالها اگر گمراه‌کننده نباشن، حداقل ضرورت و فایدهء خاصی هم ندارن.
چون اشیاء درون برنامه اغلب خیلی محدودتر و متفاوت تر از این اشیاء دنیای بیرونی هستن. اشیاء دنیای فیزیکی از ابتدا بصورت شیء وجود دارن و ما اونها رو بخاطر طبقه بندی ایجاد نکردیم، بلکه بر اساس وجود اونها و خواصی که دارن اونها رو توصیف و با روشهای دیگری طبقه بندی میکنیم، درحالیکه درمورد شیء گرایی در برنامه نویسی ما داریم عکس این عمل رو انجام میدیم؛ یعنی بخاطر طبقه بندی و دسته دسته کردن عناصر موجود، اشیایی رو ایجاد میکنیم. بنظر من این تفاوت در جهت و هدف، میتونه موجب سردرگمی افراد مبتدی بشه.
چون آدم فکر میکنه حتما صرف ایجاد چیزهایی مثل اشیاء دنیای فیزیکی، در برنامه نویسی هم خاصیت و معنایی ایجاد میکنه. نمیدونم خلاصه مثال مبهمی هست که مقایسه و تفکرهای انحرافی متعددی رو به ذهن متبادر میکنه و ما رو از اصل مطلب و موضوع به این سادگی که اصلا نیازی به چنین مثالهایی نداشت دور میکنه. همون مثال طبقه بندی و پرونده پرونده کردن و قفسه بندی بنظرم خیلی ساده تر و کاراتر هست.

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

[eshpilen]

البته یه مباحث پیشرفته تری در برنامه نویسی شیء گرا هست که بحثشون جداست و بنظرم همهء اونها رو میشه توسعه های شیء گرایی دونست یا امکانات جانبی. مثل ارث بری.

[JaguarXF]

بنظرم همهء اونها رو میشه توسعه های شیء گرایی دونست یا امکانات جانبی. مثل ارث بری.

نظر شخصی جایز نیست! تعریف علمیست
شی گرایی سه ستون دارد که عبارتند از
inheritance
encapsulation
polymorphism
بدون هر کدام از اینها ناقص است

[eshpilen]

فکر نمیکنم وجود همهء این خصوصیات برای اطلاق شیء گرایی ضروری باشه. جزو تعریف هسته ای نیستن احتمالا.
بطور مثال مقالهء ویکیپدیا درمورد OOP میگه:
Object-oriented programming (OOP) is a programming paradigm (http://en.wikipedia.org/wiki/Programming_paradigm) that uses "objects (http://en.wikipedia.org/wiki/Object_%28computer_science%29)" – data structures (http://en.wikipedia.org/wiki/Data_structure) consisting of data fields (http://en.wikipedia.org/wiki/Field_%28computer_science%29) and methods (http://en.wikipedia.org/wiki/Method_%28computer_science%29) together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction (http://en.wikipedia.org/wiki/Data_abstraction), encapsulation (http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29), modularity (http://en.wikipedia.org/wiki/Module_%28programming%29), polymorphism (http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming), and inheritance (http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29). Many modern programming languages (http://en.wikipedia.org/wiki/Programming_language) now support OOP.

یا مقالهء دیگه ای میگه:
In the domain of object-oriented programming (http://en.wikipedia.org/wiki/Object-oriented_programming) an object is usually taken to mean a compilation of attributes (object elements) and behaviors (methods or subroutines (http://en.wikipedia.org/wiki/Subroutine)) encapsulating (http://en.wikipedia.org/wiki/Information_hiding#Encapsulation) an entity.

در هیچکدام از اینها همهء اون ویژگیها ذکر و جزو ضروری تعریف شمرده نشدن. مثلا در متن اول اونها رو جزو ویژگیهای ممکن، و تکنیک برنامه نویسی، ذکر کرده.
معمولا در تعریف های دقیق و علمی اگر این ویژگیها ضروری باشن از جمله بندی و اصلا اشارات صریحی که به ضرورت اونها میشه کاملا مشخص هست.

[JaguarXF]

نه. همونه که در بالا نوشتم!:لبخند:

مقاله ویکی پدیا هم مشکلی نداره. داره میگه تکنیکهای برنامه نویسی شامل ویژگیهایی مانند موارد مذکور میگردد . ( خب بله میگردد). شامل خیلی چیزهای دیگر هم میگردد.

و اتفاقا تکنیکهای بسیار خوبی هم هستند. همین دیروز اگر نمیتوانستم به لطف همین تکنیکها یک کلاس جدید از Farpoint Spread ارث بری نکنم و ProcessCMdKey رو Override نکنم مشکل برنامه غیر قابل حل میشد.

pillars of object oriented رو گوگل کن برای یادگیری دقیقتر.

ا

[eshpilen]

مقاله ویکی پدیا هم مشکلی نداره.
ا
گفتم مشکل داره؟ :متفکر:


داره میگه تکنیکهای برنامه نویسی شامل ویژگیهایی مانند موارد مذکور میگردد . ( خب بله میگردد). شامل خیلی چیزهای دیگر هم میگردد.
از فعل May استفاده کرده که به معنای ممکن بودن و توانستن هست، نه ضرورت و همیشگی بودن.
به این جمله هم اگر خوب دقت کنیم: Programming techniques may include features بازم بیشتر این ابهام رو به ذهن میاره. جمله بندی کاملا نسبی و البته مبهم هست و در درجهء اول بنظر میرسه که میگه اینها «ویژگیهایی» هستن که «ممکنه/میتونن» بکار برن.
البته کلا برای خود منهم معناش خیلی مبهم هست و شاید نویسنده اصلا منظور دقیقی از جمله بندی نداشته؛ اما معمولا جمله بندی ها کاملا معنادار هستن (تا جایی که من دیدم مقاله های ویکیپدیا اکثرا کیفیت تخصصی بالایی دارن).

[MahmoudiNik]

سلام
اخیرا کتابی در مورد شیء گرایی مطلاعه می کنم Object Oriented Programming in 21 Days :لبخندساده: کتاب خوبیه ساده و روان البته من ترجمه میخونم شبه کد هاش جاواست البته من سی شارپ کار می کنم و به هم نزدیکند اما مهمتر از اون مفاهیم هستش این کتاب رو بهتون توصیه می کنم وقتی که پیش میرفتم واقعا به یک حقیقت پی می بردم که ما وقتی داریم با یک زبان شیء گرا کار میکنیم , شی گرا برنامه نمی نویسیم یعنی مساله هامون رو شی گرا حل نمی کنیم.شی گرایی توسعه یافته تر از این چیزی هستش که گفتین این مثال هایی که میزدین بیشتر به جنبه ی کپسوله سازی و دسته بندی مربوط می شد که یکی از اهداف برنامه نویسی oo هستش آخه oop باید محاسن برنامه نویسیه ماژولار رو داشته باشه اما مشکلاتش رو نه! امروزه اگر یک برنامه ی بزرگ و پیچیده به روش غیر شی گرا نوشته بشه بیشتر به یک ظرف ماکارونی شبیه میشه و وقتی یکی مثل من یا شما کدهاش رو نگاه کنه :عصبانی++:به این حقیقت که برنامه نویسی شی گرا نعمته پی میبره! oo اومد و با ارائه ی پلی مورفیسم و وراثت منطق بعدی برنامه نویسی رو ارائه کرد توجه کنید که : "نوشتن یک فهرست ترتیبی از فراخوانی رویه ها در روند اجرای برنامه دیگر جزیی از شی گرایی نیست"
هدف در برنامه نویسی شی گرا اینه که با مساله بصورت مدل شبیه سازی زنده ای از مساله در بیاد که حلش کنیم.
بحث در مورد شیء گرایی بیشتر از اینهاست که فکر می کنم باید در تالار مربوطه انجام بشه.
با تشکر:لبخندساده:

[eshpilen]

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

[eshpilen]

الان هر فروم برنامه نویسی بپرسی شیء گرایی یعنی چی و مزایاش چیه، در 99% موارد فقط همین مثالها و حرفها و اصطلاحات رو تکرار میکنن و میگن خوبه و اگر رعایت نکنی بد میبینی!! ولی هیچکس چنتا مثال واضح نمیذاره و مقایسهء عینی صورت نمیگیره. البته این کار یخورده زحمت داره، ولی بنظرم حداقل برای متون آموزشی باید این کار رو بکنن.

[MahmoudiNik]

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

[JaguarXF]

در مورد این هم باید تو یک مساله ی واقعی حلش کرد تا ازش لذت برد

بیا مساله چند روز قبل من رو حل کن. واقعی واقعی. یک spread sheet داریم . که با دیتا پر میشود. یکی از سلولهای آن از نوع کامبو باکس است. برنامه ای بنویسید! که وقتی روی دکمه آن کامبو باکس کلیک میکنیم لیست آیتمها رو باز کند. وقتی روی محیط ادیتور آن کامبوباکس کلیک میکنیم هیچ کاری نکند ( لیست آیتم ها رو باز نکند) . وقتی روی محیط ادیتور دبل کلیک میکنیم لیست آیتمها رو باز کند.