گفتگو هایی در باب سی شارپ

[SajjadKhati]

ادامه ی پست قبل :

    namespace MyClasses
    {
        public class Comparable : IComparable, IName
        {
            public string Name { get; set; }  // اینترفیس IName بخاطر این پیاده سازی شد که در جنریک ها _کلاس Sortable<Type> _ شی ای از نوع جنریک _ مثلا شی this[0] در همون کلاس_ قابلیت تبدیل به کلاس ها رو ندارن و جنریک ها فقط میتونن به اینترفیس ها تبدیل بشن و بخاطر همین اگه خواستیم به پروپرتی Name از طریق شی جنریک ها دسترسی پیدا کنیم ، مشکلی نداشته باشیم
            public Comparable(string name)
            {
                this.Name = name;
            }
            public int CompareTo(object obj)
            {
                Comparable destinationStr = obj as Comparable;
                if (destinationStr != null)
                {
                    return this.Name.CompareTo(destinationStr.Name);
                }
                return 0;
            }
        }

        public class Sortable<Type>
        {
            private Type[] TypeInstance;
            private int CurrentIndex;
            private int Length;
            public Type this[int index]
            {
                get
                {
                    if (index < this.TypeInstance.Length)
                    {
                        this.CurrentIndex = index;
                        return this.TypeInstance[index];
                    }

                    return default(Type);
                }
                set
                {
                    if (index < this.TypeInstance.Length)
                    {
                        //this.index = index;
                        this.TypeInstance[index] = value;
                    }

                }
            }
            public Sortable(int length)
            {
                this.CurrentIndex = -1;
                this.Length = length;
                this.TypeInstance = new Type[length];
            }
            public void Sort()
            {
                if (this[0] is IComparable)
                {
                    for (int curIndex = 0; curIndex < this.Length; curIndex++)
                    {
                        IComparable iComp = this[curIndex] as IComparable;  // شی از نوع MyClasses.Comparable بهش داده میشه یعنی this[curIndex] از نوع MyClasses.Comparable پس شی iComp هم شی MyClasses.Comparable هست
                        if (iComp != null)
                        {
                            for (int allIndex = 0; allIndex < this.Length; allIndex++)
                            {
                                if (allIndex > curIndex)  // اگر عضو مقایسه شونده از مقایسه کننده بزرگتر بود ، چون اگه کوچکتر باشه یعنی در حلقه ای که دفعات قبل تکرار شد ، مقایسه شد و اگه مساوی باشه که یعنی خودش رو با خودش میخواد مقایسه کنه
                                {
                                    int sortedNumber = iComp.CompareTo(this[allIndex]);  // پس متد CompareTo از کلاس MyClasses.Comparable رو اجرا میکنه چون متغییر iComp شی ای از کلاس MyClasses.Comparable رو داره
                                    if (sortedNumber > 0)  // اگر شی iComp بزرگتر از شی this[allIndex] هست ، پس یعنی باید جاشون عوض شه
                                    {
                                        // الگوریتم جابجایی و ترتیب ایندکسر همین کلاس
                                        Type temp = this[allIndex];
                                        this[allIndex] = this[curIndex];
                                        this[curIndex] = temp;
                                     
                                        this.Sort(); // دوباره این متد رو اجرا کن (متد بازگشتی) تا از اول برای مرتب بودن چک کنه تا شامل اعضایی که تازه جابجا شدن هم بشن
                                        return;  // متدهای قبلی ای که در سلسله مراتب توابع بازگشتی اجرا شدن ، دیگه لازم نیست ادامه شون رو اجرا کنن چون آخرین متد بازگشتی ، همه چیز رو چک کرده و اگه همه ی اعضا مرتب باشن ، تموم میشه
                                    }
                                }
                            }
                        }
                    }
                }
            }

        }
  
        public interface IName
        {
            string Name { get; set; }
        }
    }

و در رویدادی در فرم :

        private void btnInterface6_Click(object sender, EventArgs e)
        {
            Page2Class.Sortable<Page2Class.Comparable> first = new Page2Class.Sortable<Page2Class.Comparable>(3);
            first[0] = new Page2Class.Comparable("ahmad");
            first[1] = new Page2Class.Comparable("saber");
            first[2] = new Page2Class.Comparable("mohammad!");

            Page2Class.Sortable<Page2Class.Comparable> secand = new Page2Class.Sortable<Page2Class.Comparable>(3);
            secand[0] = new Page2Class.Comparable("akbar 3");
            secand[1] = new Page2Class.Comparable("mahmood");
            secand[2] = new Page2Class.Comparable("ali");

            first.Sort();
            secand.Sort();

            for (int i = 0; i < 3; i++)
            {
                MessageBox.Show(first[i].Name);
            }

            for (int i = 0; i < 3; i++)
            {
                MessageBox.Show(secand[i].Name);
            }

        }

نکته ی مهم ای که درباره ی جنریک ها فهمیدم این بود که شی جنریک (مثلا Type در کلاس Sortable<Type> مثل شی this[0] در بالا) ، نمیتونه به یک کلاس تبدیل بشه و جنریک ها فقط میتونن به اینترفیس ها تبدیل بشن . دلیل اش بخاطر این میتونه باشه که نوع جنریک در زمان نوشتن کد و کمپایل ، مشخص نیست و کمپایلر نمیتونه متوجه بشه (که طبیعی هم هست) و زمان اجرا ، برای هر شی جنریک ، نوع اش مشخص میشه؟ درسته؟ ولی میتونه به اینترفیس تبدیل بشه چون پیاده سازی نداره . درسته؟
پس میشه گفت یکی از کاربرد اینترفیس ها ، توی جنریک هاست . درسته؟

چیزی لازم نیست از کاربر دریافت کنه، شما یه مجموعه داخل List دارید که باید مرتب بشه، از هر الگوریتم مرتب سازی ای هم استفاده کنه یه مقایسه داره بین a و b که هر دو اعضاء ای از همون لیست هستند،
با a.CompareTo(b) مقایسه انجام میشه دیگه. چه چیزی لازم داره که در اختیار نداشته باشه؟ مجموعه رو و متد مقایسه رو لازم داره که هر دو رو هم داره.
چه ربطی داره. T یک نوع داده نامشخص برای List که الزاما هم Sort شدنی نیست. یعنی ممکنه از قابلیت Sort اصلا استفاده نشه. اصلا الزامی وجود نداره که T اینترفیس خاصی رو پیاده سازی کرده باشه.

بله
چیزی که گفتم ، غلط بود یعنی در بدنه متد Sort ، پیش فرضش این نیست که در کلاس نوع جنریک (مثلا در کلاس Dog) ، اینترفیسی رو پیاده سازی کرده باشه
دوم اینکه طبق نکته ی بالا ، شی جنریک ها اصلا نمیتونن به کلاس تبدیل بشن

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

ممنون

اون همه در موردشون صحبت کردیم، بازم آخرش حرف اشتباه اولیه خودتون رو می زنید. حافظه شیء در هر صورت توسط GC مدیریت میشه و ربطی به IDisposable و Dispose هم نداره. چه پیاده سازی شون بکنید و چه نکنید مسئول حافظه شیء GC ئه و وقتی دیگه بهش دسترسی وجود نداشت و با تاخیر GC حافظه شو آزاد می کنه. این مساله هیچ ربطی به Dispose نداره. حافظه این همه کلاس و شیء که Disposable رو پیاده سازی نکرده اند رو کی آزاد می کنه؟ هر چند بار هم Dispose رو اجرا کنید شیء به خودی خود سر جاشه و حافظه اش هم همینطور. Dispose هیچ موقع حافظه خود شیء رو نمیتونه آزاد کنه، خودش متدی از شیء ئه. در این مورد قبلا خیلی صحبت کردیم. اون Heap رو هم من نگفتم، بهتره جایی هم عنوانش نکنید چون هیچ تضمینی وجود نداره که Heap باشه. من نه تاییدش می کنم و نه ذکر کردنش رو توصیه می کنم. اگه شما طراح GC بودید و پیاده سازیش با شما بوده، حرفی نیست، وگرنه دلیلی نداره در مورد موضوعی صحبت بشه که نه معتبر ئه و نه برای کد نویس زبان #C اطلاعاتش مفید و موثر ئه. اینکه حافظه GC از نظر داخلی از چه ساختاری ئه مثل اینه که بخواهید در داروخانه فرمول شیمیایی دارو رو برای بیمار تشریح کنید، چیزی رو بگید که مفید باشه و بدرد بخوره. حالا اطلاعات اشتباه باشه یا نباشه بماند.

والا من قاتی کردم
توی یه جا میبینیم ، برای متد Dispos ، کدی میدن (سایت استک اورفلو و مایکروسافت) که شی Managed رو رها میکنه . برای قسمت کدهای Unmanaged هم میدن . بعد توی توضیحاتش یکی میگه برای Managed کار نمیکنه و برای Unmagaed کار میکنه . یکی دیگه ، یه چیز دیگه میگه
اصلا متد Dispos رو ولش کنیم
حافظه ی Heap که دیگه اسنادش تو مایکروسافت فکر کنم باشه . خیلی جاهام درباره اش بحث کردن

هر چی I توی Framework ئه مهم ئه، اگه مهم و پر استفاده نبود که داخل Framework نمیذاشتن. کلا ماهیت Framework با کتابخانه های دیگه فرق اش در همینه که چیزهایی که وجودشون ضروری ئه یا پر استفاده و مرسوم ئه داخلش قرار میگیره. اینکه کدوم بیشتر استفاده میشه به موضوع پروژه و البته تسلط برنامه نویس بستگی داره. هر چقدر برنامه نویس به امکانات موجود بیشتر مسلط باشه و بشناستشون بیشتر ازشون استفاده می کنه.

منظورم مثلا 20 تا از مهمترین و کاربردی ترین اینترفیس هان
اون اینترفیس هایی که نوشتم نمیدونم درباره ی چه قضیه ای هستن ، درباره شون توضیح میدین؟

 

[the_king]

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

System.Reflection اصلا کاری با #C و کد برنامه نویسی نداره.جزئی از Framework ئه و همانطور که قبلا هم گفتم Framework مختص هیچ زبان خاصی نیست. System.Reflection با اسمبلی کامپایل شده در ارتباطه و ربطی به کد نویسی نداره. ویژوال استدیو کد برنامه #C رو بصورت فایل متنی می نویسه، این مساله که سطری بهش اضافه بکنه یا متغیری تعریف کنه ربطی به System.Reflection نداره. اون کد اول باید کامپایل بشه.

من نمیدونم چرا متوجه ی ربط سئوال و جواب نمیشم
دلیلش میتونه این باشه که چون کلاس های استاتیک ، از هیچ کلاسی جز object نمیتونن ارث بری کنن (البته جد هیچ کلاسی هم نمیشن) ، ولی استراکچرها نیز دارن فرزند کلاس System.ValueType ها بشن پس به همین دلیل ، یک استراکچر نمیتونه استاتیک باشه؟ دلیلش درسته؟

نه، دلیلش این نیست. اما منطق مشابهی داره. یعنی اگه براتون قابل درک ئه که یک کلاس استاتیک نباید وارث هیچ کلاسی باشه پس باید براتون قابل درک باشه که struct هم نمیتونه static باشه. اینکه یک کلاس وارث کلاس دیگه ای باشه ولی در عین حال static باشه همانقدر بی معنا است که struct ای بسازیم ولی بخواهیم static باشه.

آها اینترفیس فرزند نداره ؛ فقط پیاده سازی داره
بازم من دقیق متوجه نشدم
خوب حالا گیرم که اینترفیس ها ، سطح دسترسی ندارن . واسه همین ، موقع پیاده سازی بصورت explicitly ، اونجا هم سطح دسترسی رو مشخص نمیکنیم ولی با این حال من هنوز متوجه نشدم چرا موقع پیاده سازی بصورت implicitly ، مجبوریم سطح دسترسی شو public بگیریم؟!! چرا نمیذاره مثلا internal بگیریم؟

چون فقط و فقط متد هایی بصورت ضمنی به اینترفیس ارتباط پیدا می کنند که public باشند. جزء قواعد و اصول زبان #C ئه. اون متد ضمنی ممکنه با چندین اینترفیس جور دربیاد که یکی شون public باشه و یکی شون internal. چک کردن کردن اینکه حالا باید public باشه یا نباشه مساله رو پیچیده می کنه. یک قاعده کلی تعریف کرده اند و کار رو ساده کردند.
باید public باشه چون در کل جلوی کار اینترفیس رو میگیره. چه زمانی این public یا internal بودن تفاوت ایجاد می کنه؟ یا به عبارت بهتر چه زمانی فرقی بین internal و public بودن رو حس می کنید و این public بودن برای شما قابل قبول نیست؟ وقتی که شما اینترفیس و کلاس تون هر دو public باشند و بگید متد پیاده سازی شده میخوام internal باشه. برای interface همچین چیزی قابل قبول نیست که بگید این کلاس تعریف من رو پیاده سازی کرده و به شیء هم دسترسی دارم ولی نمیذارم متد رو اجرا کنی. همچین چیزی قابل قبول نیست، با ماهیت interface اصلا جور در نمیاد که هم به اینترفیس دسترسی داره و هم به شیء ولی اجازه اجرا کردن متد داده نمیشه.

شما وقتی داخل یک کلاس کلاس دیگه ای رو به عنوان nested class با دسترسی private تعریف می کنید از بیرون کلاس که دیگه nested class قابل دسترسی نیست. داخل کلاس private nested class هر فیلد و متدی رو هم با هر دسترسی ای تعریف کنید فرقی بحالش نمی کنه و یکجور میشه. فقط فرقش اینه که در مورد nested class دیگه کامپایلر نمیخواد مجبورتون کنه همه چیز رو private یا public تعریف کنید. اینم که در پیاده سازی متد اینترفیس دسترسی public یا internal باشه مثل همین قضیه فیلد های کلاس private ئه. اینکه زبان مجبورتون می کنه public تعریف کنید، اصلا محدودیت برای شما نیست، شما کلاس تون رو internal تعریف کنید و خیالتون راحت باشه که از بیرون از اسمبلی کسی نمی تونه متد public رو فراخوانی کنه. اون public هیچ دسترسی زورکی ایجاد نمی کنه، اون public اجباری صرفا برای کاهش پیچیدگی های پیاده سازی های چندین اینترفیس ئه که کامپایلر رو به دردسر می اندازه.

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

private ئه، با Reflection ببینید میبینید که private ئه. اینکه نشونش نمیده بخاطر اینه که قابل دسترسی نیست. توقع دارید متدی رو که اسم معتبری برای فراخوانی کردن نداره رو با چه اسمی نشون بده؟ چیزی رو نشون میده که بتوانید فراخوانی کنید. اون لیست برای استفاده است، دکوری که نیست که بخواهید مورد غیر قابل استفاده رو لیست کنه. و قبلا هم گفتم، فراموش نکنید. همه موارد الزاما در لیست نمایش داده نمیشن.

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

بخاطر اینکه کلاس abstract و interface ماهیت کاملا متفاوتی دارند و مقایسه کردن قواعد شون اشتباهه. کلاس abstract یک کلاس با پیاده سازی ناقص ئه، هیچ ربطی به ماهیت اینترفیس نداره. شما می توانید در کلاس abstract فیلد و متد عادی تعریف کنید و پیاده سازی کنید، مانعی برای وجود پیاده سازی در داخل کلاس abstract نیست. ممکنه کلاس abstract ای بسازید که اصلا مورد پیاده سازی نشده نداشته باشه. شما همچنان با استنتاج تجربی دارید همون شیوه اشتباه قبلی رو ادامه می دید و بعد می گید متوجه نمیشم. هر ویژگی مشترکی در دو تا ماهیت متفاوت ببینید که دلیل نمیشه قواعد شون مشترک باشه. زبان #C رو آدم فضایی ها که ننوشته اند که دارید براش با علوم تجربی قواعد استخراج می کنید.

آها وقتی میگه شی ای از IComparer<int> رو بده ، یعنی شی ای از کلاسی که توی اون کلاس ، IComparer<int> رو پیاده سازی کردی رو بده نه اینکه فقط IComparer رو تنهایی پیاده سازی کرده باشه

کاملا مستقل ئه، IComparer یک پیاده سازی ای داره و <IComparer<T یک پیاده سازی دیگه.

میگم ، متد Sort (ای که هیچ آرگومان ورودی دریافت نمیکنه) در کلاس List ، تخمینا باید یه همچین پیاده سازی ای داشته باشه . درسته؟ :

اصلا چیزی تخمینی نداریم. کد و پیاده سازیش مشخصه، با ابزار Red Gate .NET Reflector می توانید کدش رو ببینید. قبلا هم گفتم. اصلا خود Sort درگیر مرتب سازی نمیشه. داخلش یه آرایه معمولی داره که مرتب سازی هم مربوط به اون آرایه است، اون Sort خودش کار خاصی نمی کنه.

 

[the_king]

ادامه ی پست قبل :
اینترفیس IName بخاطر این پیاده سازی شد که در جنریک ها _کلاس Sortable<Type> _ شی ای از نوع جنریک _ مثلا شی this[0] در همون کلاس_ قابلیت تبدیل به کلاس ها رو ندارن و جنریک ها فقط میتونن به اینترفیس ها تبدیل بشن و بخاطر همین اگه خواستیم به پروپرتی Name از طریق شی جنریک ها دسترسی پیدا کنیم ، مشکلی نداشته باشیم
نکته ی مهم ای که درباره ی جنریک ها فهمیدم این بود که شی جنریک (مثلا Type در کلاس Sortable<Type> مثل شی this[0] در بالا) ، نمیتونه به یک کلاس تبدیل بشه و جنریک ها فقط میتونن به اینترفیس ها تبدیل بشن .

سر در نمیارم از حرف تون. تبدیل بشه یعنی چی؟ T یک Type ئه، Type خودش یک کلاس ئه abstract ئه، و وارث MemberInfo ئه، MemberInfo هم خودش یک کلاسه. با همه اینها سازگار ئه. شی ای مثل this[0] هم شیء ای از نوع T است که Type اونه. توقع دارید به چه جور کلاس های دیگه ای تبدیل بشه؟

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

چون فرض تون اشتباهه نتیجه گیریتون هم اشتباه میشه دیگه. اگه ویژوال استدیو نتونه کد برنامه شما رو پردازش کنه که دیگه در حد Notepad میشه.

دوم اینکه طبق نکته ی بالا ، شی جنریک ها اصلا نمیتونن به کلاس تبدیل بشن

قواعدی که اختراع می کنید شخصی ئه، یه چیزی رو تجربه می کنید و بعد نتیجه گیری می کنید و بر اساسش قاعده اختراع می کنید. بعد هم که اشتباه بودنش معلوم شد میگید گیج شدم. اینها قواعد من درآوردی شما است؛ قواعد زبان #C نیست.

  public class GenericA<T>
  {
  public T[] Array = new T[10];

  public void Test()
  {
  var b = Array[0] as Control;
  if (b != null)
  {
  MessageBox.Show(b.Text);
  }
  }
  }

            var g = new GenericA<Button>();
            g.Array[0] = new Button() {Text = Application.ProductName};
            g.Test();

توی یه جا میبینیم ، برای متد Dispos ، کدی میدن (سایت استک اورفلو و مایکروسافت) که شی Managed رو رها میکنه . برای قسمت کدهای Unmanaged هم میدن . بعد توی توضیحاتش یکی میگه برای Managed کار نمیکنه و برای Unmagaed کار میکنه . یکی دیگه ، یه چیز دیگه میگه

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

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

اسناد مایکروسافت در مورد پیاده سازی GC در CLR ئه، جزئی از ماشین مجازی که NET. رو اجرا می کنه. اصلا در مورد زبان #C و NET. نیست. اینکه GC با چه ساختار حافظه ای پیاده سازی بشه ربطی به زبان #C نداره، همین الان هم GC در Mono با ساختار های متفاوتی پیاده سازی شده که ربطی به مستندات مایکروسافت هم نداره. بحث زبان #C رو با این موارد نامربوط قاطی نکنید.

منظورم مثلا 20 تا از مهمترین و کاربردی ترین اینترفیس هان

رو چه مبنایی؟ بر چه اساسی اینها انتخاب شدن؟

اون اینترفیس هایی که نوشتم نمیدونم درباره ی چه قضیه ای هستن ، درباره شون توضیح میدین؟

توضیح شون که اندازه چند فصل کتابه، مناسب سوال و جواب نیست.
IQueryable برای اینه که یک نوع داده ای رو به شیوه دالخواه تون با کوئری های Linq سازگار کنید. Linq تا حدودی شبیه به کوئری های SQL ئه ولی داده هاش ارتباطی با پایگاه داده نداره.
INotifyPropertyChanged برای اینه که یک ساختار خارجی از تغییر یافتن مقدار یه پروپرتی با خبر بشه. این کاربرد رو داره که یک مجموعه که در حال نمایشه، مثلا یه DataRowView جایی در حال نمایشه، وقتی پروپرتی ای تغییر کرد باید یه رخدادی ایجاد بشه که نمایش دهنده بفهمه تغییری رخ داده. متوجه بشه که یک پروپرتی تغییر مقدار داده و باید حالت نمایشی فعلی Refresh بشه و مقدار جدید نمایش پیدا کنه.
IEquatable و IEqualityComparer مثل IComparable و IComparer هستند، ولی کاری به بزرگی و کوچیکی ندارند، فقط برابری رو چک می کنند

 

[SajjadKhati]

System.Reflection اصلا کاری با #C و کد برنامه نویسی نداره.جزئی از Framework ئه و همانطور که قبلا هم گفتم Framework مختص هیچ زبان خاصی نیست. System.Reflection با اسمبلی کامپایل شده در ارتباطه و ربطی به کد نویسی نداره. ویژوال استدیو کد برنامه #C رو بصورت فایل متنی می نویسه، این مساله که سطری بهش اضافه بکنه یا متغیری تعریف کنه ربطی به System.Reflection نداره. اون کد اول باید کامپایل بشه.

ممنون استاد علی
خوب منم نگفتم که System.Reflection جزئی از #C هه! میدونم مربوط به دات ت هه

نه، دلیلش این نیست. اما منطق مشابهی داره. یعنی اگه براتون قابل درک ئه که یک کلاس استاتیک نباید وارث هیچ کلاسی باشه پس باید براتون قابل درک باشه که struct هم نمیتونه static باشه. اینکه یک کلاس وارث کلاس دیگه ای باشه ولی در عین حال static باشه همانقدر بی معنا است که struct ای بسازیم ولی بخواهیم static باشه.

خوب این هم همون شد انگار دیگه
یعنی شما گفتین که "اگه براتون قابل درک ئه که یک کلاس استاتیک نباید وارث هیچ کلاسی باشه پس باید براتون قابل درک باشه که struct هم نمیتونه static باشه" چون استراکچر باید از کلاس System.ValueType هم ارث بری کنه دیگه

چون فقط و فقط متد هایی بصورت ضمنی به اینترفیس ارتباط پیدا می کنند که public باشند. جزء قواعد و اصول زبان #C ئه. اون متد ضمنی ممکنه با چندین اینترفیس جور دربیاد که یکی شون public باشه و یکی شون internal. چک کردن کردن اینکه حالا باید public باشه یا نباشه مساله رو پیچیده می کنه. یک قاعده کلی تعریف کرده اند و کار رو ساده کردند.
باید public باشه چون در کل جلوی کار اینترفیس رو میگیره. چه زمانی این public یا internal بودن تفاوت ایجاد می کنه؟ یا به عبارت بهتر چه زمانی فرقی بین internal و public بودن رو حس می کنید و این public بودن برای شما قابل قبول نیست؟ وقتی که شما اینترفیس و کلاس تون هر دو public باشند و بگید متد پیاده سازی شده میخوام internal باشه. برای interface همچین چیزی قابل قبول نیست که بگید این کلاس تعریف من رو پیاده سازی کرده و به شیء هم دسترسی دارم ولی نمیذارم متد رو اجرا کنی. همچین چیزی قابل قبول نیست، با ماهیت interface اصلا جور در نمیاد که هم به اینترفیس دسترسی داره و هم به شیء ولی اجازه اجرا کردن متد داده نمیشه.

شما وقتی داخل یک کلاس کلاس دیگه ای رو به عنوان nested class با دسترسی private تعریف می کنید از بیرون کلاس که دیگه nested class قابل دسترسی نیست. داخل کلاس private nested class هر فیلد و متدی رو هم با هر دسترسی ای تعریف کنید فرقی بحالش نمی کنه و یکجور میشه. فقط فرقش اینه که در مورد nested class دیگه کامپایلر نمیخواد مجبورتون کنه همه چیز رو private یا public تعریف کنید. اینم که در پیاده سازی متد اینترفیس دسترسی public یا internal باشه مثل همین قضیه فیلد های کلاس private ئه. اینکه زبان مجبورتون می کنه public تعریف کنید، اصلا محدودیت برای شما نیست، شما کلاس تون رو internal تعریف کنید و خیالتون راحت باشه که از بیرون از اسمبلی کسی نمی تونه متد public رو فراخوانی کنه. اون public هیچ دسترسی زورکی ایجاد نمی کنه، اون public اجباری صرفا برای کاهش پیچیدگی های پیاده سازی های چندین اینترفیس ئه که کامپایلر رو به دردسر می اندازه.

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

private ئه، با Reflection ببینید میبینید که private ئه. اینکه نشونش نمیده بخاطر اینه که قابل دسترسی نیست. توقع دارید متدی رو که اسم معتبری برای فراخوانی کردن نداره رو با چه اسمی نشون بده؟ چیزی رو نشون میده که بتوانید فراخوانی کنید. اون لیست برای استفاده است، دکوری که نیست که بخواهید مورد غیر قابل استفاده رو لیست کنه. و قبلا هم گفتم، فراموش نکنید. همه موارد الزاما در لیست نمایش داده نمیشن.

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

با Reflection که نمیشه اعضای private رو دید . راهنماشم ینو گفته . متغییر propName در کد زیر هم null هه و نمیشه ازش استعلام گرفت :

        public interface IName
        {
            string Name { get; set; }
        }

        public class Test_3 : IName
        {
            private string _name;
            string IName.Name
            {
                get
                {
                    return this._name;
                }
                set
                {
                    this._name = value;
                }
            }
        }

و

        private void btnInterface8_Click(object sender, EventArgs e)
        {
            Type testType = typeof(Page2Class.Test_3);
            System.Reflection.PropertyInfo propName = testType.GetProperty("IName.Name");

            if (propName != null)
            {
                MessageBox.Show("");
            }
        }

بخاطر اینکه کلاس abstract و interface ماهیت کاملا متفاوتی دارند و مقایسه کردن قواعد شون اشتباهه. کلاس abstract یک کلاس با پیاده سازی ناقص ئه، هیچ ربطی به ماهیت اینترفیس نداره. شما می توانید در کلاس abstract فیلد و متد عادی تعریف کنید و پیاده سازی کنید، مانعی برای وجود پیاده سازی در داخل کلاس abstract نیست. ممکنه کلاس abstract ای بسازید که اصلا مورد پیاده سازی نشده نداشته باشه. شما همچنان با استنتاج تجربی دارید همون شیوه اشتباه قبلی رو ادامه می دید و بعد می گید متوجه نمیشم. هر ویژگی مشترکی در دو تا ماهیت متفاوت ببینید که دلیل نمیشه قواعد شون مشترک باشه. زبان #C رو آدم فضایی ها که ننوشته اند که دارید براش با علوم تجربی قواعد استخراج می کنید.

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

کاملا مستقل ئه، IComparer یک پیاده سازی ای داره و <IComparer<T یک پیاده سازی دیگه.

اصلا چیزی تخمینی نداریم. کد و پیاده سازیش مشخصه، با ابزار Red Gate .NET Reflector می توانید کدش رو ببینید. قبلا هم گفتم. اصلا خود Sort درگیر مرتب سازی نمیشه. داخلش یه آرایه معمولی داره که مرتب سازی هم مربوط به اون آرایه است، اون Sort خودش کار خاصی نمی کنه.

خوب این ابزار Red Gate .NET Reflector رو زودتر میگفتین ها

 

[SajjadKhati]

سر در نمیارم از حرف تون. تبدیل بشه یعنی چی؟ T یک Type ئه، Type خودش یک کلاس ئه abstract ئه، و وارث MemberInfo ئه، MemberInfo هم خودش یک کلاسه. با همه اینها سازگار ئه. شی ای مثل this[0] هم شیء ای از نوع T است که Type اونه. توقع دارید به چه جور کلاس های دیگه ای تبدیل بشه؟

چون فرض تون اشتباهه نتیجه گیریتون هم اشتباه میشه دیگه. اگه ویژوال استدیو نتونه کد برنامه شما رو پردازش کنه که دیگه در حد Notepad میشه.


قواعدی که اختراع می کنید شخصی ئه، یه چیزی رو تجربه می کنید و بعد نتیجه گیری می کنید و بر اساسش قاعده اختراع می کنید. بعد هم که اشتباه بودنش معلوم شد میگید گیج شدم. اینها قواعد من درآوردی شما است؛ قواعد زبان #C نیست.

  public class GenericA<T>
  {
  public T[] Array = new T[10];

  public void Test()
  {
  var b = Array[0] as Control;
  if (b != null)
  {
  MessageBox.Show(b.Text);
  }
  }
  }

            var g = new GenericA<Button>();
            g.Array[0] = new Button() {Text = Application.ProductName};
            g.Test();

ممنون استاد علی
منم سر در نمیارم
منظورتون از Type ، کلاس System.Type که نیست؟!
پس بنابراین یعنی چی که گفتین abstract هست یا نیست؟!
Type رو به عنوان نوع جنریک گرفتم .
پس در کدی که در پست اول در همین صفحه دادم ، وقتی شی جنریک رو به مثلا Control تبدیل میکنم ، ارور زیر رو میده :



منظورش از Type در ارور در عکس بالا (یا در کد در پست اول) ، System.Type نیست . منظورش Type ای هست که به عنوان چنریک دادم

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


اسناد مایکروسافت در مورد پیاده سازی GC در CLR ئه، جزئی از ماشین مجازی که NET. رو اجرا می کنه. اصلا در مورد زبان #C و NET. نیست. اینکه GC با چه ساختار حافظه ای پیاده سازی بشه ربطی به زبان #C نداره، همین الان هم GC در Mono با ساختار های متفاوتی پیاده سازی شده که ربطی به مستندات مایکروسافت هم نداره. بحث زبان #C رو با این موارد نامربوط قاطی نکنید.

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

رو چه مبنایی؟ بر چه اساسی اینها انتخاب شدن؟

توضیح شون که اندازه چند فصل کتابه، مناسب سوال و جواب نیست.
IQueryable برای اینه که یک نوع داده ای رو به شیوه دالخواه تون با کوئری های Linq سازگار کنید. Linq تا حدودی شبیه به کوئری های SQL ئه ولی داده هاش ارتباطی با پایگاه داده نداره.
INotifyPropertyChanged برای اینه که یک ساختار خارجی از تغییر یافتن مقدار یه پروپرتی با خبر بشه. این کاربرد رو داره که یک مجموعه که در حال نمایشه، مثلا یه DataRowView جایی در حال نمایشه، وقتی پروپرتی ای تغییر کرد باید یه رخدادی ایجاد بشه که نمایش دهنده بفهمه تغییری رخ داده. متوجه بشه که یک پروپرتی تغییر مقدار داده و باید حالت نمایشی فعلی Refresh بشه و مقدار جدید نمایش پیدا کنه.
IEquatable و IEqualityComparer مثل IComparable و IComparer هستند، ولی کاری به بزرگی و کوچیکی ندارند، فقط برابری رو چک می کنند

همین جوری انتخاب شدن . کلا میخوام یه اطلاعات جزئی دستم باشه
کلا توضیحی مثل همین و در حد یه خط منظورم بود
ممنون

 

[the_king]

خوب این هم همون شد انگار دیگه
یعنی شما گفتین که "اگه براتون قابل درک ئه که یک کلاس استاتیک نباید وارث هیچ کلاسی باشه پس باید براتون قابل درک باشه که struct هم نمیتونه static باشه" چون استراکچر باید از کلاس System.ValueType هم ارث بری کنه دیگه

دیگه اینکه پیش خودتون چطور تحلیل می کنید که کلاس وقتی static ئه نباید وراثت داشته باشه رو اطلاعی ندارم. اون که ربطی به ValueType نداره.

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

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

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

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

با Reflection که نمیشه اعضای private رو دید . راهنماشم ینو گفته . متغییر propName در کد زیر هم null هه و نمیشه ازش استعلام گرفت :

راهنماش گفته؟ کد تون ایراد داره. باید دنبال اعضاء Instance | NonPublic بگردید. با GetProperty ای که پارامتری از نوع BindingFlags داره.

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

دقیقا ایراد در همین پس نتیجه گیری میشه شما است. یکبار این بحث استنتاج ها رو ببندیم بذاریم کنار. شما برای چندمین بار دارید استنتاج رو قاطی بحث قواعد زبان #C می کنید. اصلا این استنتاج تون غلطه، کاربردش اینجا نیست، روی هر موردی در قواعد برنامه نویسی استنتاج غلطه. نتیجه ای که می گیرید هم درست باشه، غلطه چون فرض اولیه اش غلطه.
این پس نتیجه گیری میشه رو از روی کدوم معیار میگید؟ دلیل اینکه پرنده ها پرواز می کنند مگه بال داشتن شون نیست؟ پس پنگوئن پرواز می کنه؟ شما تو هیچ کتاب برنامه نویسی همچین استدلال هایی رو نمی بینید که بگن قانون اول - هر چیزی که پیاده سازی نداره پس نباید دسترسی داشته باشه. فقط هم شما دنبال همچین قواعدی می گردید. قواعد تجربی و استدلال هایی که با استنتاج در بیارید تو برنامه نویسی به هیچ دردی نمی خورند. از کسی که 28 سال تجربه برنامه نویسی داره اینو بپذیرید. ابدا کاربردی ندارند. هیچ برنامه نویسی لازم نیست بدونه که چرا پیشفرض Int صفر ئه. فقط باید بدونه که صفر ئه. چرا وقت خودتون رو برای اختراع کردن قواعد بدرد نخور تلف می کنید؟ شما هزار تا قاعده برای زبان #C اختراع کنید یک سر سوزن فایده نداره.
وقت تون برای یادگیری برنامه نویسی بذارید. این چیزهایی که شما برای ارتباط دادن شون با هم وقت صرف می کنید ربطی بهم ندارند. چه کسی طراح زبان رو مجبور می کنه در interface همان قواعدی رو اجرا کنه که در abstract class هست؟ کدوم قوانین؟ نه مبنای ریاضی داره و نه جبر طبیعت روش موثره و نه پیرو احکام الهی ئه. فیل در تاریکی مثنوی معنوی رو خوندید؟ دارید با #C همون کار رو می کنید. خودتون انتخاب کنید، میخواهید برنامه نویسی یاد بگیرید یا برید دنبال استنتاج در فلسفه و منطق. دو تاش با هم جور در نمیاد.

 

[the_king]

ممنون استاد علی
منم سر در نمیارم
منظورتون از Type ، کلاس System.Type که نیست؟!

چرا دقیقا همونه. شما در اجرا جای اون Type مواردی مثل typeof(int) و typeof(double) و ... رو خواهید داشت.

پس بنابراین یعنی چی که گفتین abstract هست یا نیست؟!

abstract ئه، Type یک کلاس از نوع abstract ئه. یعنی شما هیچوقت شیء ای نخواهید دید که دقیقا نوع اش Type باشه، همیشه از نوع یک کلاس وارث Type ئه که البته سازگار با Type ئه.

Type رو به عنوان نوع جنریک گرفتم .
پس در کدی که در پست اول در همین صفحه دادم ، وقتی شی جنریک رو به مثلا Control تبدیل میکنم ، ارور زیر رو میده :
مشاهده پیوست 111969

منظورش از Type در ارور در عکس بالا (یا در کد در پست اول) ، System.Type نیست . منظورش Type ای هست که به عنوان چنریک دادم

شما با اون کد دارید به کامپایلر میگید که بهت دروغ گفتم، گفتم Generic ئه اما الان میگم Generic نیست و Control ئه. نمیشه که هم Generic باشه و هم Control باشه. شما باید به کامپایلر اجازه بدید که چک کنه نوع داده سازگار با Control هست یا خیر. نه اینکه بگید حتما سازگاره. اون as Control خاصیتش همینه که الزامی نیست که سازگار باشه. اگر باشه تبدیل می کنه و اگه نباشه null بر میگردونه. برای همین باید از as Control استفاده کنید، نه اینکه همینطوری قطعی و چشم بسته (Control) فرض اش کنید. من اگه به کلاس شما یک Type ناسازگار با Control بدم کدتون چطور باید باهاش کنار بیاد؟

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

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

 

[SajjadKhati]

دیگه اینکه پیش خودتون چطور تحلیل می کنید که کلاس وقتی static ئه نباید وراثت داشته باشه رو اطلاعی ندارم. اون که ربطی به ValueType نداره.

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

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

راهنماش گفته؟ کد تون ایراد داره. باید دنبال اعضاء Instance | NonPublic بگردید. با GetProperty ای که پارامتری از نوع BindingFlags داره.

ممنون استاد علی
درباره ی Reflection برای اعضایی مثل پروپرتی private ، من که نتونستم پیدا کنم چیزی . پارامتر BindingFlags هم چند مقدارشو تست کردم ولی متوجه نشدم و نتیجه نگرفتم

چرا دقیقا همونه. شما در اجرا جای اون Type مواردی مثل typeof(int) و typeof(double) و ... رو خواهید داشت.


abstract ئه، Type یک کلاس از نوع abstract ئه. یعنی شما هیچوقت شیء ای نخواهید دید که دقیقا نوع اش Type باشه، همیشه از نوع یک کلاس وارث Type ئه که البته سازگار با Type ئه.


شما با اون کد دارید به کامپایلر میگید که بهت دروغ گفتم، گفتم Generic ئه اما الان میگم Generic نیست و Control ئه. نمیشه که هم Generic باشه و هم Control باشه. شما باید به کامپایلر اجازه بدید که چک کنه نوع داده سازگار با Control هست یا خیر. نه اینکه بگید حتما سازگاره. اون as Control خاصیتش همینه که الزامی نیست که سازگار باشه. اگر باشه تبدیل می کنه و اگه نباشه null بر میگردونه. برای همین باید از as Control استفاده کنید، نه اینکه همینطوری قطعی و چشم بسته (Control) فرض اش کنید. من اگه به کلاس شما یک Type ناسازگار با Control بدم کدتون چطور باید باهاش کنار بیاد؟

آها
تازه فرق تبدیل با as رو فهمیدم
as اول چک میکنه و در صورت دررست بودن ، تبدیل میکنه؟
واسه همین ارور میداد

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

دقیقا ایراد در همین پس نتیجه گیری میشه شما است. یکبار این بحث استنتاج ها رو ببندیم بذاریم کنار. شما برای چندمین بار دارید استنتاج رو قاطی بحث قواعد زبان #C می کنید. اصلا این استنتاج تون غلطه، کاربردش اینجا نیست، روی هر موردی در قواعد برنامه نویسی استنتاج غلطه. نتیجه ای که می گیرید هم درست باشه، غلطه چون فرض اولیه اش غلطه.
این پس نتیجه گیری میشه رو از روی کدوم معیار میگید؟ دلیل اینکه پرنده ها پرواز می کنند مگه بال داشتن شون نیست؟ پس پنگوئن پرواز می کنه؟ شما تو هیچ کتاب برنامه نویسی همچین استدلال هایی رو نمی بینید که بگن قانون اول - هر چیزی که پیاده سازی نداره پس نباید دسترسی داشته باشه. فقط هم شما دنبال همچین قواعدی می گردید. قواعد تجربی و استدلال هایی که با استنتاج در بیارید تو برنامه نویسی به هیچ دردی نمی خورند. از کسی که 28 سال تجربه برنامه نویسی داره اینو بپذیرید. ابدا کاربردی ندارند. هیچ برنامه نویسی لازم نیست بدونه که چرا پیشفرض Int صفر ئه. فقط باید بدونه که صفر ئه. چرا وقت خودتون رو برای اختراع کردن قواعد بدرد نخور تلف می کنید؟ شما هزار تا قاعده برای زبان #C اختراع کنید یک سر سوزن فایده نداره.
وقت تون برای یادگیری برنامه نویسی بذارید. این چیزهایی که شما برای ارتباط دادن شون با هم وقت صرف می کنید ربطی بهم ندارند. چه کسی طراح زبان رو مجبور می کنه در interface همان قواعدی رو اجرا کنه که در abstract class هست؟ کدوم قوانین؟ نه مبنای ریاضی داره و نه جبر طبیعت روش موثره و نه پیرو احکام الهی ئه. فیل در تاریکی مثنوی معنوی رو خوندید؟ دارید با #C همون کار رو می کنید. خودتون انتخاب کنید، میخواهید برنامه نویسی یاد بگیرید یا برید دنبال استنتاج در فلسفه و منطق. دو تاش با هم جور در نمیاد.

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

 

[the_king]

ممنون استاد علی
درباره ی Reflection برای اعضایی مثل پروپرتی private ، من که نتونستم پیدا کنم چیزی . پارامتر BindingFlags هم چند مقدارشو تست کردم ولی متوجه نشدم و نتیجه نگرفتم

    public class Test
    {
        private int _x = 12;

        private int X
        {
            get
            {
                return _x;
            }
            set
            {
                _x = value;
            }
        }
    }

            var t = new Test();
            var prop = t.GetType().GetProperty("X", BindingFlags.Instance | BindingFlags.NonPublic);
            MessageBox.Show(prop.GetValue(t, null).ToString());

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

آها
تازه فرق تبدیل با as رو فهمیدم
as اول چک میکنه و در صورت دررست بودن ، تبدیل میکنه؟
واسه همین ارور میداد

بله، و البته as فقط برای مقادیری است که null پذیر باشند، x as int و i as Button و ... رو شامل نمیشه. در اون موارد می توانید فرضا اول با is چک کنید و بعد با Convert تبدیل کنید :

            if (Array[0] is int)
            {
                MessageBox.Show(Convert.ToInt32(Array[0]).ToString());
            }

 

[SajjadKhati]

    public class Test
    {
        private int _x = 12;

        private int X
        {
            get
            {
                return _x;
            }
            set
            {
                _x = value;
            }
        }
    }

            var t = new Test();
            var prop = t.GetType().GetProperty("X", BindingFlags.Instance | BindingFlags.NonPublic);
            MessageBox.Show(prop.GetValue(t, null).ToString());

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

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


بله، و البته as فقط برای مقادیری است که null پذیر باشند، x as int و i as Button و ... رو شامل نمیشه. در اون موارد می توانید فرضا اول با is چک کنید و بعد با Convert تبدیل کنید :

            if (Array[0] is int)
            {
                MessageBox.Show(Convert.ToInt32(Array[0]).ToString());
            }

پس as در خودش ، ابتدا is رو داره
چرا گفتین که : "i as Button غلطه؟" اشتباه سهوی بوده؟ آخه گفتین که برای مقادیر null پذیر میاد . Button هم کلاس هه و کلاس ها هم null پذیرن

 

[the_king]

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

لابد هم explicit ئه و اسم اش رو هم درست وارد نمی کنین.
خودتون میدونید که IName.Name اسم پروپرتی نمیتونه باشه و میدونید که همچین پروپرتی explicit ای نمیتونه مستقل از IName وجود داشته باشه :

            System.Reflection.PropertyInfo propInfo = typeof(Page2Class.IName).GetProperty("Name");
            if (propInfo != null)
            {
                MessageBox.Show("");
            }

چرا گفتین که : "i as Button غلطه؟" اشتباه سهوی بوده؟ آخه گفتین که برای مقادیر null پذیر میاد . Button هم کلاس هه و کلاس ها هم null پذیرن

نه، اشتباه سهوی نیست، دو طرف as باید null پذیر باشند. فرض کنید ;int i = 5 رو دارید، i as Button اینجا اصلا قابل کامپایل نیست، اون i اصلا null پذیر نیست که بخواد خروجی as Button مقدار null بشه.

 

[SU-57]

آقا سجاد چند سوال:

1- این صفحه راهنما دقیقا اسمش چیه (انگلیسی و فارسی) شما گفتی اینتلایسنس همونی که مثلا وقتی message رو می زنیم لیست کلمات کلیدی رو میاره

2- به ++ گفتی پلاس پلاس. دو تا منفی -- گفتی ماینر ماینز. این ماینز ماینز درستش چیه (فارسی و انگلیسی)

3- شما به object گفتی نوع داده ای و یکجای دیگه گفتی کلاس. مگه می شه هم کلاس باشه و هم نوع داده ای (حالا بماند که هنوز به مبحث کلاس نرسیدیم و من نمی دونم چیه)

4- کدوم از کدهای زیر اصولی تره

MessageBox.Show("a is" + a);

MessageBox.Show("a is" + a.ToString());

 

[SajjadKhati]

آقا سجاد چند سوال:

1- این صفحه راهنما دقیقا اسمش چیه (انگلیسی و فارسی) شما گفتی اینتلایسنس همونی که مثلا وقتی message رو می زنیم لیست کلمات کلیدی رو میاره

2- به ++ گفتی پلاس پلاس. دو تا منفی -- گفتی ماینر ماینز. این ماینز ماینز درستش چیه (فارسی و انگلیسی)

3- شما به object گفتی نوع داده ای و یکجای دیگه گفتی کلاس. مگه می شه هم کلاس باشه و هم نوع داده ای (حالا بماند که هنوز به مبحث کلاس نرسیدیم و من نمی دونم چیه)

4- کدوم از کدهای زیر اصولی تره

MessageBox.Show("a is" + a);

MessageBox.Show("a is" + a.ToString());

سلام آقا رامین
1) بله . اسمش اینتل لایسنس هه . intellisense هه . بله همونه
2) plus plus و minus minus
3) بله . هم کلاس هه و هم نوع داده ای . نوع های داده ای کلا ایناهان :
Data Types (C# vs. Java)
ایناها هر کدوم برای خودشون کلاس یا استراکچر میتونن باشن (همونایی که اولش رو بزرگ وقتی مینویسین و سبز رنگ میشه)
البته همه ی کلاس ها و استراکچرها ، نوع داده ای نیستن ها
4) کدها رو توی تگ کد بنویسید . 4 تا آیکون بعد از آیکون شکلک ، سمت چپ، آیکونی هست که میشه تگ کد رو اضافه کرد . دومین کد اصولی تره :

MessageBox.Show("a is" + a.ToString());

 

[SajjadKhati]

سلامی مجدد استاد علی
یک سئوال عجیب غریب کنم ، دعوام نمیکنین؟
میگم موقع تعریف آرایه ، چرا توی قسمت ایندکس که عدد میذاریم ، نوعش رو اونجا نمینویسیم؟ یعنی چرا این جوری نمینویسیم؟ :

public string[int x] MyArray;

ولی موقع تعریف ایندکسر ، در قسمت ایندکس ، نوعش رو باید بنویسیم؟ :

public string this[int x]
            {
                set
                {

                }
            }

اگه ناراحت شدین یا میخواین بگین که چرا مسائل رو به هم مرتبط میکنم ، جواب ندین
دوم اینکه چرا میشه توی ایندکسرها ، نوع اندیس رو ref و out تعریف کرد؟

 

[the_king]

سلامی مجدد استاد علی
یک سئوال عجیب غریب کنم ، دعوام نمیکنین؟
میگم موقع تعریف آرایه ، چرا توی قسمت ایندکس که عدد میذاریم ، نوعش رو اونجا نمینویسیم؟ یعنی چرا این جوری نمینویسیم؟ :

public string[int x] MyArray;

ولی موقع تعریف ایندکسر ، در قسمت ایندکس ، نوعش رو باید بنویسیم؟ :

public string this[int x]
            {
                set
                {

                }
            }

دو تا چیز کاملا متفاوته، بجز اینکه هر دوشون [] دارند شباهتی به هم ندارند. با هم قاطی شون نکنید.
اولی تعریف کردن یک متغیر آرایه است که با Array در ارتباطه و دومی تعریف کردن یک اپراتور ایندکسر. در تعریف آرایه دست تون باز نیست که نوع پارامتر تعیین کنید، چون نحوه تعریف کردن آرایه در #C همونه و ثابته. جایی برای تغییر وجود نداره که برنامه نویس بخواد تعریف جدیدی از Array ارائه کنه. دلیلی نداره که بخواهید برای ایجاد کردن آرایه تعریف دیگه ای مشخص کنید چون آرایه در #C همونه.
اما دومی تعریف کردن یک Indexer ئه که پشت اش قرار نیست حتما یک آرایه باشه، قبلا هم ازش مثال دیدید. آرایه ها indexer دارند، هر چیزی هم که indexer داره یه تعریفی برای []this داره. دست تون هم در انتخاب نوع داده پارامترش بازه چون به هیچ ساختار خاصی وابسته نیست، هر طور که بخواهید از پارامترش استفاده می کنید و برای همین هر نوع پارامتری که بخواهید بکار می برید.

اگه ناراحت شدین یا میخواین بگین که چرا مسائل رو به هم مرتبط میکنم ، جواب ندین
دوم اینکه چرا میشه توی ایندکسرها ، نوع اندیس رو ref و out تعریف کرد؟

چون indexer تنها تفاوتش با پروپرتی هایی که به سلیقه خودتون می نویسید اینه که یک اپراتور [] ئه، نه وصله به اینترفیس خاصی که قالب ثابتی داشته باشه و نه نیاز به وراثت خاصی داره که پروتوتایپ اش ثابت باشه. محدودیت هاش باید در حدی باشه که با اپراتور [] استفاده بشه. به محدودیت بیشتری نیاز نداره. اینکه ref و out باشه و نباشه مشکلی برای استفاده اش در [] ایجاد نمی کنه. اما فرضا اگر تعریف آرایه بود دیگه نمیشد ref float باشه چون Array با ref float سازگاری نداره. Indexer و تعریف آرایه کاملا دو تا چیز متفاوته، کاراکتر هاشون شبیه ئه ولی عملکرد شون به کل فرق می کنه. همانطور که & (آدرس حافظه در کد های unsafe) با & (عملگر AND) به کلی فرق دارند. کاراکتر هر دوشون & ئه ولی هیچ شباهتی در کاربرد و معنی شون ندارند. همانطور که : هم در case ها هست و هم در وراثت و هم در اپراتور : ? ولی هیچکدوم شباهتی بهم ندارند.

 

[SU-57]

سلام

من فهمیدم که عملگرهای && و || فقط true و false رو قبول می کنن. و عملگرهای & و | مقادیر بیتی رو هم قبول می کنن.

int a = 10;
int b = 20;

if(a==10 || b==30)
{
MessageBox.Show("True");
}

مثال بالا حالت منطقی بود
حالا من یک مثال ساده از عملگرهای & و | می خوام که عملوند هاش به صورت بیتی باشن نه منطقی

*******

آقا سجاد عملگرهای & ، | ، && و || رو گفت منطقی ولی در بعضی از سایت ها که رفته بودم نوشته بود عملگر شرطی کدومش درسته

*****

اسم عملگرهای == و = چیه الان من میگم یک مساوی و دو مساوی که اشتباه نکنم آیا اسم خاصی دارن

*******

یک مثال کاربردی هم از متغیر F در تصویر زیر می خوام

لینک

*******


آقا سجاد دستت درد نکنه این قسمت 8 و 9 رو عالی درس دادی مخصوصا قسمت 9 چون یک ساعت و 20 دقیقه بود و فشار کمتری رو تحمل کردم

 

[SajjadKhati]

سلام

من فهمیدم که عملگرهای && و || فقط true و false رو قبول می کنن. و عملگرهای & و | مقادیر بیتی رو هم قبول می کنن.

سلام
درسته
البته بهتره بگین که مقادیر بیتی ، فقط برای عملگرهای & و | هست

int a = 10;
int b = 20;

if(a==10 || b==30)
{
MessageBox.Show("True");
}

مثال بالا حالت منطقی بود
حالا من یک مثال ساده از عملگرهای & و | می خوام که عملوند هاش به صورت بیتی باشن نه منطقی

مثال :

            int a = 10;
            int b = 20;
            int c = a | b;

*******

آقا سجاد عملگرهای & ، | ، && و || رو گفت منطقی ولی در بعضی از سایت ها که رفته بودم نوشته بود عملگر شرطی کدومش درسته

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

*****

اسم عملگرهای == و = چیه الان من میگم یک مساوی و دو مساوی که اشتباه نکنم آیا اسم خاصی دارن

*******

یک مثال کاربردی هم از متغیر F در تصویر زیر می خوام

لینک

*******


آقا سجاد دستت درد نکنه این قسمت 8 و 9 رو عالی درس دادی مخصوصا قسمت 9 چون یک ساعت و 20 دقیقه بود و فشار کمتری رو تحمل کردم

عملگر = مساوی و عملگر == مساوی مساوی هست (من که اینو میگم)
توی شرط ، بجای d ، متغییرf بذارین
خواهش میشود . چرا این جوری میبینین؟ هر قسمت ، هنوز مونده که خسته بشین (هنوز خسته نشده) ، همونجا ویدئو رو استوپ بدین و بذارین برای جلسه ی بعد (powerDvd این قابلیت رو داره که از آخرین لحظه ی هر ویدئو ، نشونه میذاره و براحتی متوجه میشین) . مثلا یه ویدئو که 2.5 ساعت هست رو به 2 قسمت 1 ساعت و 10 دقیقه یا 3 قسمت 50 دقیقه تقسیم کنین
بعد اینکه بهتره وقتی قسمت 11 رو دیدین ، نکات تکمیلی و اصلاحیه شو یعنی در قسمت 40 (دقیقه ی 53 به بعد) و مخصوصا قسمت 47 (دقیقه ی 47) رو پیشنهاد میکنم که نگاه کنین

 

[SU-57]

آقا سجاد من powerDVD رو دانلود کردم حالا چطوری علامت گذاری کنم

بعد اون کد بیتی که می خواستم داخل if می خواستم الان این کد رو من نوشتم خطا میده

int a = 10;
int b = 20;

if (a | b)
{
  MessageBox.Show("True");
  }

اینطوری هم می نویسم ارور نمیده ولی اجرا هم نمی شه. اگه true و false ای باشه اسونه ولی مثال برای بیتی نمی تونم در بیارم داخل if

int a = 10;
int b = 20;

if ((a | b) == 10)
{
  MessageBox.Show("True");
  }

*************

از قدیم گفتن که "هر که طاووس خواهد جور هندوستان کشد" ولی خوب هر یک ساعت تدریس شما برای ما 3 ساعت میگذره. (2 ساعت یادگیری اون یک ساعت + 1 ساعت تمرین و مثال زدن برای خودمون)

به همین خاطرآقا سجاد عزیز اینو گفتی نزدیک بود سرم رو بکوبم به دیوار

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

لینک

 

[SajjadKhati]

آقا سجاد من powerDVD رو دانلود کردم حالا چطوری علامت گذاری کنم

وقتی در حال دیدن فیلم (با نسخه ی 17 پاور دی وی دی) ، powerDVD رو ببندین ، و دوباره همون فیلم رو بالا بیارین ، آخرین جایی که دیدین رو نشونه گذاری میکنه

بعد اون کد بیتی که می خواستم داخل if می خواستم الان این کد رو من نوشتم خطا میده

int a = 10;
int b = 20;

if (a | b)
{
  MessageBox.Show("True");
  }

a و b از نوع عدد هستن (پس عملگر بین شون ، عملگر بیتی هست) و خروجی شون هم عدد میشه
اما داخل شرط (همونطور که از اسم اش هم پیداست) ، خروجی بولین میخواد که اگه true باشه ، بدنه اش اجرا بشه و اگه false باشه ، اجرا نشه

اینطوری هم می نویسم ارور نمیده ولی اجرا هم نمی شه. اگه true و false ای باشه اسونه ولی مثال برای بیتی نمی تونم در بیارم داخل if

int a = 10;
int b = 20;

if ((a | b) == 10)
{
  MessageBox.Show("True");
  }

خوب این درسته (از نظر کمپایلر)
خروجی (a | b) در شرط ، عدد میشه (دلیل شو گفتم) ، و دقیقا هم میشه 30 پس میشه :

if (30 == 10)

و چون 30 برابر 10 نیست ، false در خروجی این عبارت قرار میگیره و بدنه اجرا نمیشه

*************

از قدیم گفتن که "هر که طاووس خواهد جور هندوستان کشد" ولی خوب هر یک ساعت تدریس شما برای ما 3 ساعت میگذره. (2 ساعت یادگیری اون یک ساعت + 1 ساعت تمرین و مثال زدن برای خودمون)

به همین خاطرآقا سجاد عزیز اینو گفتی نزدیک بود سرم رو بکوبم به دیوار

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

لینک

خواهش میشود

 

[SU-57]

خوب اینو فهمیدم که نمی شه توی if از عملوند های بیتی استفاده کرد. خوب حالا می خوام همون مثال شما رو = فراخوانی کنه و نشون بده ولی به جای اینکه یا 10 رو نشون بده یا 20 رو عدد 30 رو نشون میده. جمع می زنه

int a = 10;
int b = 20;
int c = a | b;

MessageBox.Show(c.ToString());

آقا یه مثال ساده بیاری من رفتم قسمت 10