اصول OOP

در گروه منتشر شد
سلام! آیا تا به حال به این فکر کرده اید که چرا جاوا اینگونه طراحی شده است؟ به این معنا که شما کلاس ها را بر اساس آنها ایجاد می کنید - اشیا، کلاس ها متدها و غیره دارند. اما چرا ساختار زبان به گونه ای است که برنامه ها از کلاس ها و اشیاء تشکیل شده اند و نه از چیز دیگری؟ چرا مفهوم «شیء» ابداع شد و در خط مقدم قرار گرفت؟ آیا همه زبان ها به این شکل کار می کنند و اگر نه، چه مزایایی به جاوا می دهد؟ همانطور که می بینید، سوالات زیادی وجود دارد :) بیایید سعی کنیم در سخنرانی امروز به هر یک از آنها پاسخ دهیم.

اصول OOP:

  1. وراثت
  2. انتزاع - مفهوم - برداشت
  3. کپسوله سازی
  4. پلی مورفیسم

برنامه نویسی شی گرا (OOP) چیست؟

البته جاوا به دلایلی از اشیا و کلاس ها تشکیل شده است. این یک هوی و هوس سازندگان آن و یا حتی اختراع آنها نیست. بسیاری از زبان های دیگر وجود دارند که بر اساس اشیا هستند. اولین چنین زبانی سیمولا نام داشت و در دهه 1960 در نروژ اختراع شد. از جمله، سیمولا مفاهیم « کلاس » و « متد » را معرفی کرد. اصول برنامه نویسی شی گرا - 2
کریستن نایگارد و اوله یوهان دال - خالقان سیمولا
به نظر می رسد که سیمولا از نظر استانداردهای برنامه نویسی یک زبان باستانی است، اما ارتباط "خانوادگی" آنها با جاوا با چشم غیر مسلح قابل مشاهده است. به احتمال زیاد می توانید به راحتی کد نوشته شده روی آن را بخوانید و به طور کلی توضیح دهید که چه کاری انجام می دهد :)
Begin
  Class Rectangle (Width, Height); Real Width, Height;

   Begin
      Real Area, Perimeter;

      Procedure Update;
      Begin
        Area := Width * Height;
              OutText("Rectangle is updating, Area = "); OutFix(Area,2,8); OutImage;
        Perimeter := 2*(Width + Height);
              OutText("Rectangle is updating, Perimeter = "); OutFix(Perimeter,2,8); OutImage;
      End of Update;

      Update;
      OutText("Rectangle created: "); OutFix(Width,2,6);
      OutFix(Height,2,6); OutImage;
   End of Rectangle;

       Rectangle Class ColouredRectangle (Color); Text Color;

  Begin
      OutText("ColouredRectangle created, color = "); OutText(Color);
      OutImage;
        End of ColouredRectangle;


         Ref(Rectangle) Cr;
   Cr :- New ColouredRectangle(10, 20, "Green");
End;
نمونه کد از مقاله Simula - 50 years of OOP گرفته شده است . همانطور که می بینید، جاوا و اجداد آن چندان متفاوت از یکدیگر نیستند :) این به این دلیل است که ظاهر Simula تولد یک مفهوم جدید - برنامه نویسی شی گرا را نشان داد. ویکی‌پدیا تعریف زیر را از OOP ارائه می‌کند: برنامه‌نویسی شی‌گرا (OOP) یک روش برنامه‌نویسی است که مبتنی بر نمایش یک برنامه به‌عنوان مجموعه‌ای از اشیاء است که هر کدام نمونه‌ای از یک کلاس خاص هستند و کلاس‌ها یک سلسله مراتب ارثی را تشکیل می‌دهند. به نظر من بسیار موفق است. شما اخیراً شروع به یادگیری جاوا کرده اید، اما به ندرت کلماتی در آن وجود دارد که برای شما ناآشنا باشد :) امروزه، OOP رایج ترین متدولوژی برنامه نویسی است. علاوه بر جاوا، اصول OOP در بسیاری از زبان های محبوبی که ممکن است نام آنها را شنیده باشید استفاده می شود. اینها عبارتند از C++ (به طور فعال توسط توسعه دهندگان بازی های رایانه ای استفاده می شود)، Objective-C و Swift (آنها برای دستگاه های اپل برنامه می نویسند)، Python (در یادگیری ماشینی بیشترین تقاضا را دارد)، PHP (یکی از محبوب ترین زبان های توسعه وب)، جاوا اسکریپت (ساده تر بگوییم چه کاری روی آن انجام نمی دهند) و بسیاری دیگر. در واقع، این "اصول" OOP چیست؟ بیایید با جزئیات بیشتر به شما بگوییم.

اصول OOP

این اصول اولیه است. 4 ویژگی اصلی که با هم پارادایم برنامه نویسی شی گرا را تشکیل می دهند. درک آنها کلید تبدیل شدن به یک برنامه نویس موفق است. اصول برنامه نویسی شی گرا - 3

اصل 1. ارث

خبر خوب این است که شما قبلاً با برخی از اصول OOP آشنا هستید! :) ما قبلاً چند بار در سخنرانی ها با وراثت مواجه شده ایم و وقت داشته ایم که با آن کار کنیم. وراثت مکانیزمی است که به شما امکان می دهد یک کلاس جدید را بر اساس کلاس موجود (والد) توصیف کنید. در این حالت، ویژگی ها و عملکرد کلاس والد توسط کلاس جدید قرض گرفته می شود. چرا ارث لازم است و چه فوایدی دارد؟ اول از همه، استفاده مجدد از کد. فیلدها و متدهای توصیف شده در کلاس های والد را می توان در کلاس های فرعی استفاده کرد. اگر همه انواع خودروها دارای 10 فیلد مشترک و 5 روش یکسان هستند، فقط باید آنها را در کلاس والد قرار دهید Auto. می توانید بدون هیچ مشکلی از آنها در کلاس های decendant استفاده کنید. مزایای ثابت: هم از نظر کمی (کد کمتر) و هم در نتیجه از نظر کیفی (کلاس ها بسیار ساده تر می شوند). در عین حال، مکانیسم وراثت بسیار انعطاف‌پذیر است و می‌توانید عملکردهای گمشده را به طور جداگانه در فرزندان اضافه کنید (برخی فیلدها یا رفتارهای خاص برای یک کلاس خاص). به طور کلی، مانند زندگی معمولی: همه ما از جهاتی شبیه والدین خود هستیم، اما از جهاتی با آنها متفاوت هستیم :)

اصل 2. انتزاع

این یک اصل بسیار ساده است. انتزاع به معنای برجسته کردن اصلی ترین و مهم ترین ویژگی های یک شی است و بالعکس - دور انداختن ویژگی های ثانویه و بی اهمیت. بیایید چرخ را دوباره اختراع نکنیم و مثالی از یک سخنرانی قدیمی در مورد کلاس ها را به خاطر بسپاریم. فرض کنید در حال ایجاد یک کابینت پرونده از کارکنان شرکت هستیم. برای ایجاد اشیاء کارمند، یک کلاس نوشتیم Employee. چه ویژگی هایی برای شرح آنها در پرونده شرکت مهم است؟ نام کامل، تاریخ تولد، شماره تامین اجتماعی، شماره شناسایی مالیاتی. اما بعید است که در کارتی از این نوع به قد، رنگ چشم و موهای او نیاز داشته باشیم. شرکت به این اطلاعات در مورد کارمند نیاز ندارد. بنابراین، برای کلاس ، Employeeمتغیرهای، و و را تنظیم می کنیم String nameو اطلاعاتی را که برای ما غیر ضروری است، مانند رنگ چشم، کنار می گذاریم و آن را انتزاع می کنیم int age. اما اگر یک کاتالوگ از مدل های عکس برای آژانس ایجاد کنیم، وضعیت به طرز چشمگیری تغییر می کند. برای توصیف یک مدل مد، قد، رنگ چشم و رنگ مو برای ما بسیار مهم است، اما به شماره TIN نیازی نیست. بنابراین، در کلاس متغیرهای , , را ایجاد می کنیم . int socialInsuranceNumberint taxNumberModelString heightString hairString eyes

اصل 3: کپسولاسیون

ما قبلا با آن مواجه شده ایم. کپسوله سازی در جاوا به معنای محدود کردن دسترسی به داده ها و امکان تغییر آن است. همانطور که می بینید، بر اساس کلمه "کپسول" ساخته شده است. در این "کپسول" ما برخی از داده های مهم را برای خود پنهان می کنیم که نمی خواهیم کسی آنها را تغییر دهد. یک مثال ساده از زندگی شما یک نام و نام خانوادگی دارید. همه کسانی که می شناسید آنها را می شناسند. اما آنها به تغییر نام و نام خانوادگی شما دسترسی ندارند. شاید بتوان گفت این فرآیند در اداره گذرنامه "کاپسوله" شده است: شما فقط می توانید نام و نام خانوادگی خود را در آنجا تغییر دهید و فقط شما می توانید این کار را انجام دهید. سایر "کاربران" به نام و نام خانوادگی شما فقط خواندنی دسترسی دارند :) مثال دیگر پول موجود در آپارتمان شما است. رها کردن آنها در دید ساده در وسط اتاق ایده خوبی نیست. هر «کاربر» (شخصی که به خانه شما می آید) می تواند تعداد پول شما را تغییر دهد، یعنی. انتخاب کنید آنها را. بهتر است آنها را در یک گاوصندوق محصور کنید. فقط شما و فقط با یک کد خاص دسترسی خواهید داشت. نمونه‌های آشکار کپسوله‌سازی که قبلاً با آن کار کرده‌اید، اصلاح‌کننده‌های دسترسی (و privateغیره public) و دریافت‌کننده‌ها هستند. اگر فیلد ageکلاس Catکپسوله نشده باشد، هر کسی می تواند بنویسد:
Cat.age = -1000;
و مکانیسم کپسولاسیون به ما اجازه می دهد تا ageبا روش تنظیم کننده از میدان محافظت کنیم، که در آن می توانیم بررسی کنیم که سن نمی تواند یک عدد منفی باشد.

اصل 4. چند شکلی

چند شکلی توانایی برخورد با چندین نوع است که گویی آنها یک نوع هستند. در این حالت، رفتار اشیا بسته به نوع آنها متفاوت خواهد بود. کمی پیچیده به نظر می رسد؟ حالا بیایید بفهمیم بیایید ساده ترین مثال را در نظر بگیریم - حیوانات. بیایید یک کلاس Animalبا یک متد - voice()و دو تا از فرزندان آن - Catو ایجاد کنیم Dog.
public class Animal {

   public void voice() {

       System.out.println("Voice!");
   }
}

public class Dog extends Animal {


   @Override
   public void voice() {
       System.out.println("Bow-wow!");
   }
}

public class Cat extends Animal {

   @Override
   public void voice() {
       System.out.println("Meow!");
   }
}
حالا بیایید سعی کنیم یک پیوند ایجاد کنیم Animalو به آن یک شی اختصاص دهیم Dog.
public class Main {

   public static void main(String[] args) {

       Animal dog = new Dog();
       dog.voice();
   }
}
به نظر شما کدام روش نامیده می شود؟ Animal.voice()یا Dog.voice()؟ متد کلاس نامیده می شود Dog: Woof-woof! ما یک مرجع ایجاد کردیم Animal، اما شی مانند رفتار می کند Dog. در صورت لزوم، او می تواند مانند یک گربه، اسب یا حیوانات دیگر رفتار کند. نکته اصلی این است که یک مرجع از نوع عمومی را Animalبه یک شی از یک کلاس نواد خاص اختصاص دهید. این منطقی است، زیرا همه سگ ها حیوان هستند. این همان چیزی است که ما گفتیم "اشیا بسته به نوع آنها رفتار متفاوتی خواهند داشت." اگر بخواهیم یک شی Cat− ایجاد کنیم
public static void main(String[] args) {

   Animal cat = new Cat();
   cat.voice();
}
این روش voice()خروجی "میو!" "توانایی کار با چندین نوع به عنوان یک نوع" به چه معناست؟ این نیز بسیار آسان است. بیایید تصور کنیم که در حال ایجاد یک آرایشگاه برای حیوانات هستیم. سالن موی ما باید بتواند همه حیوانات را کوتاه کند، بنابراین ما یک روش shear()("برش") با یک پارامتر ایجاد خواهیم کرد Animal- حیوانی که می خواهیم برش دهیم.
public class AnimalBarbershop {

   public void shear(Animal animal) {

       System.out.println("The haircut is ready!");
   }
}
shearو حالا می‌توانیم هم آبجکت‌ها Catو هم آبجکت‌ها را به متد ارسال کنیم Dog!
public static void main(String[] args) {

   Cat cat = new Cat();
   Dog dog = new Dog();

   AnimalBarbershop barbershop = new AnimalBarbershop();

   barbershop.shear(cat);
   barbershop.shear(dog);
}
در اینجا یک مثال واضح وجود دارد: کلاس AnimalBarbershopبا انواع کار می کند Catکه Dogگویی از همان نوع هستند. در عین حال، آنها رفتار Catمتفاوتی دارند Dog: آنها از صدای خود متفاوت استفاده می کنند.

دلایل ظهور OOP

چرا این مفهوم برنامه نویسی جدید - OOP - حتی بوجود آمد ؟ برنامه نویسان ابزارهایی داشتند که کار می کردند: برای مثال زبان های رویه ای. چه چیزی آنها را به اختراع چیزی اساساً جدید ترغیب کرد؟ اول از همه، پیچیدگی وظایفی که با آن روبرو بودند. اگر 60 سال پیش وظیفه یک برنامه نویس شبیه "محاسبه یک معادله ریاضی فلان و فلان" بود، اکنون ممکن است به نظر برسد "7 پایان مختلف برای بازی STALKER بسته به اینکه کاربر در لحظات A، B، C، D چه تصمیمی گرفته است، اجرا کند." ، E، F و ترکیبی از این محلول ها." وظایف، همانطور که می بینید، به وضوح در طول دهه های گذشته پیچیده تر شده اند. این بدان معنی است که انواع داده ها پیچیده تر شده اند. این دلیل دیگری برای ظهور OOP است. مثال با معادله را می توان به راحتی با استفاده از مقادیر اولیه معمولی حل کرد؛ در اینجا به هیچ شیئی نیاز نیست. اما حتی توصیف مشکل پایان های بازی بدون استفاده از کلاس هایی که شما اختراع کرده اید دشوار خواهد بود. اما در عین حال، توصیف آن در کلاس ها و اشیاء بسیار آسان است: بدیهی است که به کلاس Game، کلاس Stalker، کلاس Ending، کلاس Player’s Decision، کلاس Game Moment و غیره نیاز خواهیم داشت. یعنی حتی بدون شروع حل یک مشکل، به راحتی می‌توانیم «طرح‌هایی» از راه‌حل آن را در ذهن خود تصور کنیم. پیچیدگی روزافزون مشکلات، برنامه نویسان را مجبور کرده است تا مسئله را به بخش هایی تقسیم کنند. اما در برنامه نویسی رویه ای این کار چندان آسان نبود. و اغلب این برنامه یک "درخت" از شاخه های مختلف با تمام گزینه های ممکن برای عملکرد آن بود. بسته به شرایط خاص، برنامه در طول یک شاخه یا آن دیگر اجرا می شد. برای برنامه های کوچک این گزینه مناسب بود، اما تقسیم یک کار بزرگ به قسمت ها بسیار دشوار بود. این نیاز دلیل دیگری برای ظهور OOP شد. این مفهوم به برنامه نویسان این توانایی را می دهد که یک برنامه را به دسته ای از "ماژول ها" از کلاس ها تقسیم کنند، که هر کدام بخش مخصوص به خود را انجام می دهند. همه اشیا، در تعامل با یکدیگر، کار برنامه ما را تشکیل می دهند. علاوه بر این، کدهایی که می نویسیم را می توان در جای دیگری از برنامه مجددا استفاده کرد که در زمان زیادی نیز صرفه جویی می کند.
نظرات
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION