چرا باید propertyهای یک کلاس رو private قرار بدیم؟

پرسیده شده
فعالیت 1136 روز پیش
دیده شده 648 بار
0

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

 

 

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

 

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

 

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

 

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

فایل پیوست

علی.
علی.

29 اسفند 99

2
حذف شده

سلام و احترام

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

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

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

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

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

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

فایل پیوست

امیر صالحی

توسط

امیر صالحی

29 اسفند 99

حذف شده
سلام. عیدت پیشاپیش مبارک. اونطور که من از مثالت برداشت کردم شما دو تا موضوع کلاس و api رو با هم یکی کردید که مثال درستی نیست برای علت استفاده از پراپرتی ها!! یخورده بیشتر توضیح بده داخل یک پست تا متوجه مثالت بشم شاید برداشت من از این مثال اشتباهه. یه سؤالم دارم اینکه به api_key چه کسانی دسترسی دارن و از چه طریق که بتونن تغییرش بدن؟
محسن موحد

30 اسفند 99

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

30 اسفند 99

0
حذف شده

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

 

یعنی ما از 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 های شی مارو تغییر بدن و فقط به اشیاء که مجاز هستن اجازه دسترسی میدیم

فایل پیوست

علی.

توسط

علی.

29 اسفند 99

حذف شده
کسی که داره از کلاس یه object میسازه، شما دارید داخل کلاس یه کاراهایی انجام میدید و محافظت میکنید از دسترسی به اون متد ها و پراپرتی ها
امیر صالحی

29 اسفند 99

حذف شده
و فقط به چیز هایی دسترسی میدید که کاربر بهش نیاز داره
امیر صالحی

29 اسفند 99

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

29 اسفند 99

2
حذف شده

سلام.

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

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

 

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

 

فایل پیوست

محسن موحد

توسط

محسن موحد

30 اسفند 99

حذف شده
سلام عید شمام پیشاپیش مبارک منم با شما موافقم. اینکه صرفا واسه امنیت میاییم property هارو کپسوله می‌کنیم بنظرم درست نمی‌تونه باشه و بنظرم یک دلیل منطقی تری پشت این قضیه باید باشه.
علی.

30 اسفند 99

حذف شده
درسته.. اگرم نیاز داشتین میتونم چنتا مثال بیارم.برای مثال این ساختار برنامه نویسی ما مشخص میکنه چه چیزیرو پرایویت کنیم و چه چیزیو پابلیک، مثلا یک ساختار که بگه یک متد باید از داخل متد دیگه فراخوانی بشه و مستقیم از بیرون نباشه وگرنه کد به مشکل میخوره اون متدو میشه پرایویت کرد و اگر کمی همون ساختارو تغییر داد که بشه از بیرون هم صداش زد میشه همون متد رو پابلیکش کرد.
محسن موحد

30 اسفند 99

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

30 اسفند 99

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

30 اسفند 99

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

30 اسفند 99

حذف شده
*** سلام آقا محسن *** ## اینکه ما بیاییم جزییات غیر ضروری رو مخفی سازی کنیم و فقط functionality شی رو در معرض دید بزاریم مربوط به اصل abstraction میشه درسته؟
علی.

9 فروردین 00

حذف شده
?
علی.

9 فروردین 00

2
حذف شده

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

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

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

 

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

فایل پیوست

امیر صالحی

توسط

امیر صالحی

30 اسفند 99

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

30 اسفند 99

0
حذف شده

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

 

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

 

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

 

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

 

نظر شما چیه؟؟

فایل پیوست

علی.

توسط

علی.

30 اسفند 99

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

30 اسفند 99

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

30 اسفند 99

حذف شده
درواقع هدف اینه که بعد از ساخت شی دیگه زیاد درگیر set کردن مقدایر property ها نباشیم تا شی ای که ساختیم عملکرد درستی داشته باشه درواقع یجورایی تا جایی که امکان داره میخواهیم این فرایند رو خودکار کنیم
علی.

30 اسفند 99