💻 آخرین فرصت یادگیری برنامه‌نویسی با آفر ویژه قبل از افزایش قیمت در ۱۵ آذر ماه (🎁 به همراه یک هدیه ارزشمند )
۰ ثانیه
۰ دقیقه
۰ ساعت
۵ علی
چرا باید propertyهای یک کلاس رو private قرار بدیم؟
جامعه پی اچ پی ایجاد شده در ۲۹ اسفند ۱۳۹۹

سلام و خسته نباشد

 

 

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

 

حالا سوال من اینه که چرا property‌های شی رو باید پنهان کنیم؟ آیا دلیل پنهان کردن property‌ها هم مثل متد هاست ؟ یا برای محافظت از داده هامون باید اینکارو انجام بدیم؟

 

درواقع این اصطلاح رو که برای محافظت از دادهمون میاییم property‌های کلاس رو private تعریف میکنم  رو درک نمیکنم 

 

یا بهتره اینطوری سوالمو بیان کنم چه چیزی داده‌های مارو تهدید میکنه که باید داده هامونو ازش پنهان کنیم ؟ دسترسی غیر مجاز به یک property به چه شکل میتونه باشه؟

سلام و احترام

به طور کلی ما همه property‌ها رو private تعریف نمیکنیم  و بستگی داره داریم چیکار میکنیم، بزارید که مثال بزنم براتون.

فرض کنید شما یه کلاس دارید که میخواید باهاش یه notification ارسال کنید (مثلا یه sms به یه کاربری)

کلاس notification یه api key داره که سرویس دهنده شما (مثلا سرویس kavenegar) به شما داده و خب این یه api key مخصوص برای شماست تا بتونین sms رو ارسال کنید.

حالا شما این api key رو میای توی یه property ذخیره میکنید، برای شما خیلی مهمه که این api key تغییر نکنه چون اگه بی اجازه بهش دسترسی داشته باشن و تغییرش بدن سرویس sms شما کار نمیکنه

حالا ما باید چی کار کنیم؟ 

اون property رو طبق نیازی که داریم private یا protected قرار میدیم و تا کسی از بیرون بهش دسترسی نداشته باشه و اگه هم بخوایم تغییرش بدیم میام براش یه متد setter درست میکنیم و زمانی اگر کسی اومد متد setter ما رو صدا زد باید داخل اون متد بررسی کنیم ببینیم کاربر اصلا دسترسی داره که این api key رو تغییر بده یا ن. اگه داشت عوض میکنه اگه نداشت بهش اجازه نمیدیم

امیر صالحی ۲۹ اسفند ۱۳۹۹، ۱۸:۳۳

ممنون از پاسخ شما

 

یعنی ما از property هایی که مقدارشون بر عملکرد کلی شی تاثیر میزاره محافظت می‌کنیم تا مقدار نامعتبری نگیرن ؟

 

مثلا

class Animals
{
	//property
    private $name;
    private $voice;
    // methods
    public function __construct($name,$voice)
    {
        $this->name = $name;
        $this->voice = $voice;
    }
    public function speak()
    {
        echo $this->voice;
    }
};
$cat = new Animals('cat','meow');
$dog = new Animals('dog','hap hap');

در کد بالا برای اینکه حیواناتی که ساختیم عملکرد صحیحی داشته باشن سطح دسترسی  property‌ها رو private تعریف کردیم تا هر کسی ( # منظور از این کسی چیه دقیقا؟؟) نتونه پس از ایجاد شی مقدار property‌ها اون رو به صورت مستقیم تغییر بده (البته میشه با استفاده از متدهای setter و getter به کسایی که مجاز هستن اجاز دسترسی بدیم)

 

# منظور از این کسی چیه دقیقا؟؟ منظور اشیا دیگه هست؟ یعنی اشیاء دیگه نتونن به صورت مستقیم property‌های شی مارو تغییر بدن و فقط به اشیاء که مجاز هستن اجازه دسترسی میدیم

علی ۲۹ اسفند ۱۳۹۹، ۲۰:۳۹

سلام.

پیشاپیش عیدتون مبارک.

بصورت کلی مبحث OOP میاد یک ساختار میده به کدهامون و تمام مفاهیمی که در این راستا اضافه میشن برای تکمیل شدن این مدل برنامه نویسی مطرح میشن تا برنامه نویسان پروژه رو مجبور به کدنویسی در همون ساختار کنن و بنظر من واقعا نمیشه گفت بطور مستقیم برای بحث امنیتی و محافظت از داده مطرح شده باشند. درسته در مباحثی مثل Encapsulation شما میتونید برنامه رو جوری بنویسید که کنترل بیشتری روی داده‌های ورودی داشته باشید ولی اصل موضوع همون ساختار و مدل برنامه نویسی است چون همین کنترل داده هم به تنهایی نمیتونه امنیت ایجاد کنه ضمن اینکه داخل کد هر چقدر هم این تکنیک‌ها زیاد‌تر بشه و دچار پیچیدگی بشه، خود این پیچیدگی هم میتونه باعث ناامنی بشه. برای مثال از Encapsulation میتونین برای پیاده سازی الگوی ActiveRecord بهره ببرید.

 

سال خوبیرو واسه همه برنامه نویسان و بچه‌های سون لرن آرزومندم.

 

محسن موحد ۳۰ اسفند ۱۳۹۹، ۰۳:۱۰

بزارید من هم یه مثال بزنم که تکمیل کننده پاسخ آقای موحد باشه

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

شاید شما داخل دستگاه رو باز کنید و مثلا یه مهره ازش بر دارید اون دستگاه دیگه کار نکنه و به خاطره همین که اون مهره رو private کردن. چون اون متد یا اون پراپرتی به تنهایی نتونه کاری انجام بده و در نهایت دارند همین دیگر رو کامل میکنند تا بتونن یه کار مشخص رو انجام بدن

 

سال خوبی رو برای همه شما عزیزان آرزومندم

امیر صالحی ۳۰ اسفند ۱۳۹۹، ۰۵:۳۰

من کاملا با حرفای اقا محسن موافقم. شما فرض کن source code ما بیوفته تو دست یک هکر آیا اون موقع میشه امنیت این source code رو فراهم کرد ؟ عملا هکر هر بلایی بخواد میتونه سر source code ما بیاره

 

اما آقا محسن اون طور که من متوجه شدم دلیل private کردن property هارو ربط دادن به ساختارهایی و مفاهیمی که تو برنامه نویسی شی گرا حاکمه که بنظرم درست نمیاد

 

از نظر من مخفی کردن property‌های باعث کاهش وابستگی بین اعضا مختلف برنامه میشه و به همین دلیل هم توصیه میشه تا جای ممکن سطح دسترسی property هارو private تعریف کنیم شما فرض کن وقتی می‌خواهی با خودپرداز کار کنی مجبور بودی property‌های مختلفی رو هم به صورت دستی set میکردی! (اینکار باعث افزایش وابستگی بین شی علی و شی خودپرداز میشه)

 

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

 

نظر شما چیه؟؟

علی ۳۰ اسفند ۱۳۹۹، ۰۵:۴۹