نمایش نتایج 1 تا 29 از 29

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

Threaded View

پست قبلی پست قبلی   پست بعدی پست بعدی
  1. #15

    نقل قول: ثبت مشخصات یک فرم در فرم دیگر

    نقل قول نوشته شده توسط hdv212 مشاهده تاپیک

    گفتم که این مشکل رو میشه با استفاده از Propertiesها حل کرد (پست شماره 15)، در ضمن هرکسی ناخود آگاه از این شیوه در کد نویسیش استفاده میکنه، مگه تا حالا از این کد استفاده نکردید :
    DataSet ds = new DataSet();
    ds.Tables["myTable"] = this.dt;

    چه زمانی شما خواستید از این کد استفاده کنید :
    ds.Tables["myTable"].Dispose();

    سلام
    شما به 2 تا نقش Class Creator و Class Consumer ، توجه ندارید..

    Class Creator به شخصی می گویند، که کلاس یا اون شی خاص را طراحی می کند. طراحی اعم از اینکه ، آن شی چه خصوصیاتی دارد؟ چه رفتار هایی دارد؟ چه قسمت هایی از اون شی بایستی برای استفاده کننده های آن (Class Consumer) مشخص باشند، چه چیز هایی نباید مشخص باشند. مصرف کننده کلاس شما چه دسترسی هایی باید داشته باشید، چه دسترسی هایی نباید داشته باشد و بسیاری مطالب دیگر ...

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


    در طراحی شی گرا، در هر لحظه شما باید، بدونید که در چه جایگاهی کد می نویسید، آیا Class Creator هستید؟ یا Class Consumer ؟ و یا هر دون آن ها؟ که غالبا اکثرا از نوع سوم هستند...

    MyTable ای که شما در کد بالا نوشتید،ربطی به Class Creator ندارد. هر کسی به عنوان مصرف کننده کلاس Data Set می تواند جداولی را به آن اضافه کند، و هر عملی که بخواهد با آن ها انجام دهد..

    این مثل این می ماند که من یک آبجکت از کلاس مثلا SqlConnection یا هر چیز دیگری بگیرم و پس از آنکه کارم با آن تمام شد، آن را Dispose کنم که عمل بسیار طبیعی است...

    اما Dispose کردن، Lable ای که در فرم 1 شما می باشد( از طریق فرم 2) ، کاری نادرست است. به این دلیل که ، ممکن است شما در جایی دیگر از فرم1 نیاز به Label1 داشته باشید..

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

    شما زمانی که فرم1 را طراحی می کنید، به عنوان Class Creator برای این فرم شناخته خواهید شد.
    اینکه شما، دستور Dsipose را از فرم2 برای label1 از فرم1 نمی نویسید، و در واقع فقط خاصیت text آن را تغییر می دهید، به این دلیل است که شما در این مثال علاوه بر اینکه Class Creator برای فرم1 می باشد به عنوان Consumer آن نیز در فرم2 می باشید.

    ولی اگر مصرف کننده فرم1 شما، شخصی غیر از خود شما باشد، آیا این تضمین باز هم وجود دارد که آن شخص هم به درستی از کلاس فرم1 و دسترسی هایی که به آن داید، استفاده کند؟

    آیا این درست است که ادمین یک شبکه، پسورد administrator را در اختیار همه کاربران سایتش قرار دهد؟

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

    پس باز هم به همین جمله ای خواهیم رسید که در یکی دو پست قبل بیان کردم:

    نقل قول نوشته شده توسط r.kiani مشاهده تاپیک
    یکی از اصول مهم شی گرایی میگه که ،به هر کسی به همان اندازه که نیاز دارد اطلاعات بدهید، نه بیشتر نه کمتر)
    وقتی فقط قراره text یک textbox از جای دیگری تغذیه شود، معنایی ندارد که backColor آن هم قابل دسترسی باشد..
    آخرین ویرایش به وسیله Mahdi.Kiani : جمعه 25 مرداد 1387 در 10:44 صبح دلیل: غلط املایی

    مجموعه آموزشی Asp.Net Core Mvc کاملا به زبان فارسی(21 ماژول و 15 ساعت فیلم آموزشی همراه با سورس کامل تمرینات و پروژه عملی انجام شده در طول آموزشی)
    مشاهده جزئیات در آدرس http://www.mkiani.ir/blog/content/53084


    وب سایت : http://www.mkiani.ir
    پست الکترونیک : mkiani3000@gmail.com

    موفق و پیروز باشید.
    مهدی کیانی


قوانین ایجاد تاپیک در تالار

  • شما نمی توانید تاپیک جدید ایجاد کنید
  • شما نمی توانید به تاپیک ها پاسخ دهید
  • شما نمی توانید ضمیمه ارسال کنید
  • شما نمی توانید پاسخ هایتان را ویرایش کنید
  •