تولید نرم افزار فرآیند پیچیده ایست.نرم افزار های بزرگ معمولا توسط تیمی متشکل از برنامه نویس ها-تحلیل گرها-تست کننده های نرم افزاری و ... ساخته می شَن. اینکه شما در این بزمِ عظیم، کدوم بخش دست تونه، میتونه وظایف تونو به مراتب، سنگین تر بکنه.اما همون طور که واسه ساخت خونه و مقبره و عبادتگاه ها از یه سری اصولِ معماری تبعیت میکنن، تولید نرم افزار هم از این تبعیت کردن ها و رعایت قوانینی که جواب خود را به خوبی پس داده اند، جدا نیست. میشه اسمشو گذاشت پیروی از نظرات اهل فن.استفاده از best practice ها و یا بهره گیری از متدولوژی.هر چند امروزه باب شده همه از روش هرچه پیش آید خوش آید، برای توسعه سیستم هاشون استفاده  میکنن.

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

همه اینا رو گفتم.که به چی برسم؟

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

خوب چه کنیم؟

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

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

سوالات زیر، بخش اول از مجموعه سوالات عمومی خواهد بود که بیشتر به حوزه های design pattern ها، روش های تولید نرم افزار،اصول اولیه برنامه نویسی شی گرا و مسایلی از این دست سَرَک کشیده.

پی نوشت:

ممکنه در برخی موارد، جواب ها ناقص و  یا نیازمند توضیحات کامل تر باشند.خوشحال میشم تجربه ها و راهنمایی هاتونو باهام به اشتراک بذارید.

پ.ن:تمامی سوالات برگرفته از وبلاگ آقای هنسلمن هست.البته به مرور سوالهای بیشتری رو اضافه خواهم کرد.

 آیا می‌دانید SOLID چیست؟

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

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

  • SRP(Single Responsibility Principle):برای تغییر یک کلاس، حتما باید دلیل قانع کننده ای وجود داشته باشد.بعبارت دیگر:"هر کلاس، فقط باید یک وظیفه داشته باشد."

A class should have one and only one reason to change, meaning that a class should have only one job.

  • OCP(Open/Closed Principle): اشیا نرم افزاری برای گسترش و توسعه(extension) باز بمانند، اما برای دخل و تصرف(modification) بسته.

Objects or entities should be open for extension, but closed for modification.

  • LSP(Liskov Substitution Principle):اشیا نرم افزاری باید بتوانند به نمونه های subtype خود جایگزین شوند، بدون اینکه به صحت برنامه لطمه ای وارد گردد.

objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

  • ISP(Interface Segration Principle):هر جز نرم افزاری نباید مجبور به پیاده سازی واسط هایی شود که بدان ها نیازمند نیست.بعبارت دیگر، به جای ساخت واسط های همه منظوره(general-purpose) برای تمامی اجزای نرم افزاری باید از واسط های خاص منظوره(client-specific) استفاده کرد.

A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.

  • DIP(Dependency Inversion Principle)از دو بخش زیر تشکیل شده است:
  1. ماژول های سطح بالا، نباید به ماژول های سطح پایین وابستگی داشته باشند.هر دوی این ماژول ها باید به انتزاعات(abstractions) وابسته باشند.
  2. انتزاعات نرم افزاری نباید به جزییات پیاده سازی وابسته باشند.بلکه برعکس، جزییات پیاده سازی ماژول ها باید به انتزاعات وابسته باشند.

 High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

یه تعریف دیگه از این اصل:

Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.

 آیا می‌دانید SRP مخفف چیست و چه اهمیتی دارد؟

سرنام واژه های SRP-Single Responsibility Principle است.هم چنین یکی از اصول پنج گانه تعریف شده توسط رابرت مارتین(برای ایجاد نرم افزارهایی مستحکم و قابل توسعه) است که به طور خلاصه چنین می گوید:

برای تغییر یک کلاس، حتما باید دلیل قانع کننده ای وجود داشته باشد.بعبارت دیگر:"هر کلاس، فقط و فقط باید یک وظیفه داشته باشد."

در مورد IOC یا Inversion of control چه می‌دانید؟ ارتباط آن با dependency injection چیست؟

واگذاری مسیولیت(inversion of control):اصطلاحی ست که توسط مارتین فالر و رابرت مارتین عمومیت یافت و به طور کلی به یکی از اصول طراحی نرم افزار می پردازد و میگوید:

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

یا بعبارتی:

inversion of control is the principle where the control flow of a program is inverted: instead of the programmer controlling the flow of a program, the external sources (framework, services, other components) take control of it. It's like we plug something into something else

اهداف استفاده:

  1. قابلیت ماژولاریتی و توسعه پذیری نرم افزار را افزایش می دهد.
  2. اجرای یک وظیفه(task) را از پیاده سازی(implementation) آن جدا(decouple) می کند.
  3. ماژول های نرم افزاری، تنها به وظایفی که برایشان تعریف شده، تمرکز می کنند.
  4. برنامه را از اثرات جانبیِ(side effects) جایگزینیِ یک ماژول، آسوده خاطر می کند.

تزریق وابستگی(dependency injection):یکی از اصول طراحی نرم افزار است که وابستگی های یک شی از طریق روش های:

  1. ست کردن پراپرتی ها بوسیله setter متد ها
  2. استفاده از constructors ها

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

نکات:

  • عملکرد درست شی، به تزریق مناسب وابستگی، بستگی دارد.

  • هنگامی که از این اصل استفاده میکنیم بایستی توجه کنیم که شی نمیتواند مقادیرش را از طریق new کردن یا متد های استاتیک تامین کند.این کار ممنوع است.مقادیر و وابستگی ها باید از خارج به شی تزریق گردند. 
  • کلاینت ها اجازه ندارند کدهای injector را فراخوانی کنند.این وظیفه injector هاست که وابستگی ها را تامین کرده و در وقت مقتضی ‌آنها را به کلاینت ها تزریق کنند.

تزریق وابستگی از چهار نقش(role) تشکیل شده است.:

  1. سرویس های نرم افزاری(که قراره استفاده بشند.)
  2. کلاینت ها(که عملکردشون وابسته به استفاده از سرویس هاست.)
  3. واسط ها(interfaces)(که مشخص میکنن کلاینت ها چگونه از سرویس ها استفاده می کنند.)
  4. تزریق گر(injector)(مسیولیت ساخت سرویس ها و تزریق اونها به کلاینت ها رو بر عهده داره.)

 برنامه 2 tier با برنامه‌ی 3 tier چه تفاوتی دارد؟

معماری چند لایه:

در صنعت نرم افزار،معماری چند ردیفه(multitier architecture) یا چندلایه(multilayered architecture) همان معماری دولایه کلاینت/سروری ست(client/server architecture)که در آن، عملیات presentation,بیزینس نرم افزار(application processing) و مدیریت دیتا(data management) به صورت فیزیکی از هم تفکیک شده اند.شایع ترین استفاده از معماری چند لایه، معماری سه لایه است.

این معماری از لایه های عمده زیر تشکیل شده است:

  • Presentation layer (با نام های دیگری همچون:UI layer, view layer و  presentation tier در معماری چندتایر شناخته می شود.)
  • Application layer(یا service layer)
  • Business Layer(یا Business Logic Layer - BLL, Domain Layer)
  • Data Access Layer(یا persistence layer)

معماری دولایه:

این معماری شبیه معماری کلاینت/سروری ست.ارتباطات،مستقیماً بین کلاینت و سرور رخ می دهد.(واسطی بین این دو لایه وجود ندارد.)

دولایه آن بدین شرح است:۱-Data tier. و ۲-Client tier

مزایا:

فهم و نگهداری سیستم(Understanding and maintenances) در این معماری راحت تر است.

معایب:

کارایی سیستم(performance) پایین می آید.

معماری سه لایه:

آقای جان داناون در کمپانی OCE مبدع این معماری بود.در واقع این مدل، نوعی از مدل کلاینت/سروری ست که در آن لایه (UI(Presentation Layer برنامه،منطلق برنامه(business rules) و لایه دسترسی به داده ها، بعنوان ماژول هایی مجزا نگهداری و توسعه داده میشوند.

لایه های این معماری:

  • Presentation tier
  • Application tier
  • Data tier

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

چه زمانی از معماری دولایه استفاده کنیم؟

اگر بین لایه presentation و لایه بیزینس نرم افزار تمایزات فاحشی نباشد،می توان مدل سنتی کلاینت/سرور را پیاده سازی کرد.

فلسفه‌ی وجودی Interface چیست و چه اهمیتی دارد؟

تعریف:واسط ها، قراردادی ما بین خودشان و کلاس هایی هستند که آنها را پیاده سازی می کنند.

فرض کنید دو تیم A , B داریم که قرار است به صورت مشترک بر روی پروژه ای کار کنند.مسلما در توافقات و جلسات فی مابین، حرفی از پیاده سازی کامپوننت های سطح پایین زده نخواهد شد.صرفا کلیاتی بیان و نقشه راهی (blueprint) چیده خواهد شد. و این تیم های پیاده سازی و برنامه نویسان خواهند بود که پیاده سازی های منحصر بفرد خود را انجام می دهند.چیزی شبیه نقشه های جنگ که در قدیم برای تصرف کشوری کشیده میشد.مسلما جزییات حمله به مناطق،نو ع اسلحه هایی که در مناطق مختلف استفاده می شود و مواردی از این دست، در جلسه سران کشور بررسی نخواهد شد.آنها با لایه ای از انتزاع، نقشه جنگ را میکشند.

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

به طور خلاصه:

هر جا نیاز به انتزاع سازی مجموعه از رفتارها و ویژگی های سطح بالا داشته باشیم از interface ها استفاده میکنیم.جزییات پیاده سازی به کلاسهای مشتق شده، وابسته خواهد بود.

 الگوی Repository را شرح دهید. الگوی Factory‌ چیست؟ چرا الگوهای طراحی برنامه نویسی شیءگرا مهم هستند؟

Repository Pattern

در بسیاری از برنامه ها، لایه بیزینس برنامه(buisiness logic layer_BLL) به صورت مستقیم به دیتاسورس هایی از قبیل دیتابیس ها یا وب سرویس ها دسترسی دارند.عواقب چنین کاری ممکن است چنین باشد:

  • کدهای تکراری
  • احتمال برخورد به ارور های بیشتر در سطح برنامه
  • عدم تست لایه بیزینس برنامه به علت وابستگی هایی که به طور مستقیم به منابع خارجی دارد.

برای رفع این مشکل از الگویی به نام الگوی منبع(reposityo pattern) استفاده می شود.در واقع منبع، واسطی بین لایه data access layer و business layer‌ برنامه ایجاد می کند.اگر بر روی  دیتایی کویری بزنید این واسط، دیتاها را از دیتاسورس می گیرد و آنها را به انتیتی های لایه بیزینس(business entity) نگاشت می کند.این الگو، لایه بیزینیس را از دسترسی مستقیم با دیتاسورس ها و وب سرویس ها دور نگه میدارد.در زیر نمایی از این الگو را می بینید:

REPOSITYORY

Factory Pattern

یکی از معروف ترین الگو های طراحی است که در دسته الگوهای creational pattern  جای میگیرد.این الگو، روش هایی را برای ساخت اشیا در برنامه ارایه می دهد.در واقع برای ساخت اشیا، لازم نیست از جزییات پیاده سازی باخیر باشید.این الگو وظیفه ساخت اشیاهای آماده را برای لایه buisiness logic  ما بر عهده می گیرد.

چرا الگوهای طراحی مهم هستند؟

آنها روش های تست شده ای هستند که مسایل پرچالش و کاربردی را در دنیای واقعی به خوبی حل کرده اند.در واقع نقشه راه بسیار مناسبی برای ساخت برنامه های قدرتمند و مستحکم هستند.استفاده از آنها، به بهبود کیفیت اپلیکشین کمک شایانی کند.

Anti-patterns کدامند؟ توضیح دهید.

تعریف:

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

An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences

آنتی پترن ها نتیجه دانش کم برنامه نویسان و مدیران از وجود راه حل های بهتر است. و یا در نتیجه استفاده از یک پترن خوب در یک بستر نامناسب است.

مثالی از آنتی پترن ها رودخانه ی آتشفشانی(lava flows) یا کد مرده(Dead Code) است که در آن قسمت هایی از برنامه وجود دارند که بعلت های مختلف نمی توان آنها را حذف کرد.در واقع حذف این قسمت ها به قدری خطرناک است که ممکن است به سلامت برنامه آسیب برساند.از طرفی به علت نبود مستندات مناسب نمی توان از عملکرد درست آنها مطمین شد.

 آیا تابحال اسم Gang of Four به گوشتان خورده است؟ در چه موردی است؟

GOF یا دسته چهار، گروهی متشکل از: اریک گاما،ریچارد هِلم، رالف جانسون، جان ولیسایدز می باشد که در سال 1994 کتاب الگوهای طراحی را نوشتند.البته این کتاب حاصل طبقه بندی تفکراتی ست که پیش از آنها نیز وجود داشته است.از جمله روش هایی که کریستف الکساندر ارایه داده بود.اما با دسته بندی منظمی از طرف این گروه مواجه گشت.

 ارتباط الگوهای MVP ، MVC و MVVM در چیست؟ هر کدام از این الگوها در چه زمانی‌هایی بهتر است بکار گرفته شوند؟

این سه مدل طراحی از روش های رایجی برای ساخت برنامه های جداسازی (decouple) شده می باشند.با هم ببینیم مشخصه های هر کدام چه می باشد و برای چه سیستم هایی مناسب می باشند.

(mvc(Model View Controller:

  • Model: به عنوان مدلی برای داده ها کار میکند.
  • View: بخش بصری تشکیل دهنده نرم افزار شامل کامپوننت های ui است که به طور مستقیم با کاربر در تعامل است.
  • Controller: رابط بین مدل و ویو است.جایی که ویو،کنترلر را برای آپدیت مدل فراخوانی می کند.

مورد استفاده:

(mvp(Model View Presenter:

مشابه mvc ست.با این تفاوت که presenter جانشین controller شده است.اما بر خلاف کنترلر، در این الگوی طراحی، خود presenter مسیول مستقیم تغییرات در ویو است.(در mvc, مدل بود که ویو را آپدیت می کرد.)در این الگو، بین مدل و ویو ارتباط مستقیمی وجود ندارد.در عوض بین ویو و پرزنتر یک ارتباط یک به یک وجود دارد.یعنی هم ویو و هم presenter از وجود یکدیگر اطلاع دارند.هر گاه لازم باشد presener دیتاهای مورد نظر را از مدل گرفته و به ویوی متناظرش می دهد.

مورد استفاده:ویندوز فرم ها یکی از کاندیداهای استفاده این الگوی طراحی هستند.

(mvvm(Model View View-Model:

همچون mvc ست اما view-model در اینجا جایگزین کنترل شده است.از الگوی طراحی مشاهده کننده(observer pattern) تبعیت می کند.جایی که تغییرات در مدل به صورت آنی در ویو هم بازتاب پیدا می کند.(بوسیله VM) مثلا:اگر اسلایدری تغییر حالت دهد، نه تنها مدل تغییر میکند بلکه دیتایی که حاوی مقدار آن مدل بود نیز دستخوش تغییر می گردد.در اینجا با بایندینگ دو طرفه ای روبرو هستیم.

مورد استفاده:در پروژه هایی هم چون WPF استفاده می گردد.

پ.ن:همه موارد بالا جز الگوهای طراحی هستند.

مفهوم جداسازی وابستگی‌ها (Separation of Concerns) چیست. مزایا و معایب آن کدامند؟

جداسازی دغدغه های (مسایل،مشکلات )نرم افزاری که به اختصار SoC نامیده می شود، مفهومی در علم کامپیوتر است که مسایل را به بخش های مجزایی تفکیک و به حل هر کدام می پردازد.(هر زیر مسیله یا بخش، به موضوع و معضل واحدی اشاره می کند.)این مفهوم از یکی از اصول پنج گانه SOLID  به نام SRP‌ نشات گرفته است.(هر بخش/ماژول/جز مسیولیت یگانه ای را در طی چرخه حیات نرم افزار بر عهده دارد.)

به برنامه ای که سعی در پیاده سازی و تبعیت از  این اصل طراحی باشد، اصطلاحا برنامه ماژولار یا پیمانه ای می گویند.رسیدن به ماژولاریتی و به تبع آن اصل SoC در نتیجه کپسوله سازی برنامه به بلاک هایی از کدهاست.کپسوله سازی یکی از روش های پنهان سازی اطلاعات است.زبان های برنامه نویسی شی گرایی هم چون جاوا،سی شارپ و ... این اصل را از طریق مفهوم Object یا بوسیله الگوهای طراحی ای هم چون mvc , mvp  و ... برای کاربر به ارمغان می آورند.

مزایا:

  • ساده سازی توسعه نرم افزار(simplifying) و نگهداری راحت تر (maintenance)نرم افزار.
  • قابلیت استفاده مجدد ازکد افزایش  می یابد.
  • تغییر/توسعه/بهبود بخشی از نرم افزار بدون اطلاع از جزییات پیاده سازی قسمت های دیگر آن ممکن خواهد بود.

 سه ویژگی اصلی طراحی شیءگرا را نام برده و توضیح دهید.

  • Encapsulation یا کپسوله سازی:در زبان های برنامه نویسی، عموما به یکی از دو مفهوم زیر و یا ترکیبی از هر دو اشاره دارد:

مکانیزمی برای محدودیت دسترسی به برخی از اجزای یکی شی.

امکانی ست که داده ها را به همراه متدهایی برای دستکاری آن داده ها فراهم می آورد.

در واقع به کمک کپسوله سازی، تنها داده ها و متدهایی در خارج از کلاس در دسترس خواهند بود که مجوز دسترسی به آنها داده شده باشد.بقیه متدها و دادگان توسط اجزای داخلی خود کلاس قابل استفاده اند.این امر به ماژولاریتی شدن نرم افزار کمک شایانی می کند.

  • Inheritance یا وراثت:در ساده ترین تعریف به معنای استفاده مجدد از کدهای از قبل نوشته شده است.به کمک وراثت میتوان ویژگی های اصلی کلاس ها را در کلاس های مشترکی تعریف کرد و از این پس تمامی رفتارها را می توان از کلاس مشترک به ارث برد.این کار باعث کم شدن حجم کد و سهولت نگهداری نرم افزار می شود.بدیهی ست هر کلاس می تواند خصوصیات و رفتارهای منحصر به فرد خود را داشته باشد.
  • Polymorphism یا چند ریختی: در عالم برنامه نویسی، به فراهم کردن یک interface برای انواع مختلفی از انتیتی ها اشاره دارد.به زبان خیلی ساده:پیاده سازی متدهای interface توسط کلاس های به ارت برده شده، اما هر کدام به شیوه و منش خاصّ خود.سه شیوه عمده وجود دارد:

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

System.out.print(arg);

arg می توانید انواع مختلفی از جمله رشته یا عدد باشد و تنها به یک نوع خاص محدود نمی شود. این سربارگذاری تابع یا function overloading می باشد.

یا مثلا در جاوا عملگر + هم برای عدد بکار می رود و هم برای رشته که این oprator overloading می باشد که هر دوی اینها از نوع ad-hoc polymorphism می باشد.

۲-

parametric : در حقیقت در این نوع ما یک قالب آماده از کلاس را داریم که با دریافت پارامتر می توان به آن شکل داد. حس می کنم مطلب خود را خوب بیان نکردم!

افرادی که با برنامه نویسی شی گرا آشنایی دارند با مفهوم Generics سر و کار داشته اند. این مفهوم در اصل همان parametric polymorphism می باشد.

برای مثال می توان لیست ها در جاوا را نام برد. که در هنگام ایجاد پارامتر را به آن می دهیم.

List<JavabYabUser> users;

۳-subtype : در اینجا یک مثال ساده که این روز ها خیلی کلیشه ای شده است استفاده می کنم! 

کلاغ، گنجشک، لک لک و .. همه پرنده هستند و خصیصه های یکسانی داند، این مشترکات را می توان در یک super class به اسم bird داشت و این پرندگان همگی subtype آن باشند.

فرق abstract class و interface

Abstract class Interface
1) Abstract class can have abstract and non-abstract methods. Interface can have only abstract methods. Since Java 8, it can have default and static methods also.
2) Abstract class doesn't support multiple inheritance. Interface supports multiple inheritance.
3) Abstract class can have final, non-final, static and non-static variables. Interface has only static and final variables.
4) Abstract class can provide the implementation of interface. Interface can't provide the implementation of abstract class.
5) The abstract keyword is used to declare abstract class. The interface keyword is used to declare interface.
6) Example:
public abstract class Shape{
public abstract void draw();
}
Example:
public interface Drawable{
void draw();
}

Static Variables vs Static Methods vs Static Class

Static Variables:

هرگاه در جاوا متغیری را از نوع استاتیک تعریف کنیم بهش class variable می گوییم.یعنی بدون instance گرفتن، میشه از اون متغیر استفاده کرد.تمام instance ها، کپی مشابهی از آن متغیر را بین خودشون به اشتراک میذارند.اگر متغیری استاتیک نباشد، بهش instance variable می گوییم.و هر instance ای از کلاس، کپیِ منحصر بفرد خود را از آن متغیر دارد.

  • متغیرهای استاتیک به کلاس وابسته است نه به آبجکت.
  • متغیر های استاتیک، تنها یک بار مقداردهی اولیه می شوند.در شروع اجرا.و قبل از اینکه هر instance variable ای initialize شود.

Static Methods:

  • این متدها متعلق به کلاس هستند نه به آبجکت ها.(instance)
  • یک متد استاتیک تنها به متغیر های استاتیک دسترسی دارد و به instance variable ها نمی تواند دسترسی داشته باشد.(چون این متدها اصلا کاری به آبچکت ها ندارند.در سطح کلاس تعریف می شوند.)
  • این متدها را نمی توان override کرد.(زیرا override کردن متدها مستلرم داشتن instance‌است؛در صورتی که متدهای استاتیک با هیچ instance ای رابطه ندارد و به کلاس وابسته است.) اما می توان overload‌کرد.

Final Variable vs Final method vs Final Class

Final Variable: نمی تونیم مقادیرشون رو عوض کنیم.

final int distance=8;
distance = 7; // because of the final declaration this line is an error

Final method:نمی تونیم اون متد رو override کنیم.

public class A {
    final void LasVegas()
    {
    }
}

public class B extends A {
        final void LasVegas()  // because of the final declaration in A, this is illegal
        {
        }
    }

Final Class: نمیتوانیم از اون کلاس extend کنیم.( یا زیر کلاس ازش بسازیم.)

final class LasVegasClass {
}

class AnotherClass extends LasVegasClass { // illegal because LasVegasClass is final
}

extends vs implements

extends is for extending a class.
implements is for implementing an interface

چرا instance variable ها را نمی توان در متدهای استاتیک به کار برد؟

علت این امر به این خاطر است که کامپایلر موقع دیدن instance variable ها داخل متدهای استاتیک انتظار دارد که از قبل عملیات instantiate  انجام شده باشد.به کد زیر دقت کنید:

class Example {
int x;
static void example() {
x = 3; // ILLEGAL "non-static variable x cannot be referenced from a static context."
Example e = new Example();
e.x = 3; // OK

}
به این خاطر که کامپایلر واقعا نمی داند آیا x ای که در حال استفاده ست واقعا instansiate شده یا خیر.(اینستنسی وحود نداره که بخوایم x شو بگیریم:))

چه زمانی از متدهای استاتیک استفاده کنم؟

  1. زمانی که دارید کلاسهای utiliti یا helper classes می نویسید و انتظار دارید که در طی زمان تغییر نکنند.
  2. اگر عملیاتی که توسط متد صورت می گیرد، به هیچ اینسنتسی وابسته نیست.
  3. اگر تکه کدی توسط تمامی اینتسنتس ها قابلیت اشتراک گذاری دارد، آن را به صورت استاتیک تعریف کنید.
  4. اگر مطمین هستید که متدی که می نویسید در آینده ovrerride نخواهد شد.(زیرا متدهای استاتیک اورراید نمی شوند.)

مزایای استفاده از متدهای استاتیک

  1. نیازی به ساخت instanse برای استفاده از این متدها نیست.
  2. سربار ساخت شی و instance گرفتن از بین می رود و تنها سربار موجود، سربارِ کال کردن متد است.

سربارگذاری(overload) vs بازنویسی(override)