ثبت مشخصات یک فرم در فرم دیگر

[اَرژنگ]

بر اساس کدام مستندات دسترسی به اعضای یک کلاس از طریق یک کلاس دیگه درست نیست ؟

اگر منظور شما Encapsulation بوده، خب درسته، حق با شماست، ولی به غیر از این، نیازمند مستنداتش هستم.
با تشکر

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

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

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

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

با تشکر از Linux