گیرنده / تنظیم کننده. شر. و دوره

مقاله توسط Egor Bugaenko 19 سپتامبر 2014 | نوشته شده در: Core Java این بحث قدیمی توسط آلن هولوب در مقاله معروف خود در سال 2003 آغاز شد، چرا روش های گیرنده و تنظیم کننده بد هستند - گیرنده ها/ تنظیم کننده ها ضد الگو هستند و آیا باید از آنها اجتناب کنیم، یا این چیزی است که ما می کنیم. آیا در برنامه نویسی شی گرا مورد نیاز است. من دو سنت خود را به این بحث اضافه می کنم. اصل متن زیر این است: گیرنده ها و ستترها عمل بدی هستند؛ کسانی که از آنها استفاده می کنند هیچ بهانه ای ندارند. اما مجدداً، برای جلوگیری از سوء تفاهم، من به هیچ وجه پیشنهاد نمی کنم که از استفاده از get/set تا جایی که ممکن است اجتناب شود. خیر میگم حتی نگذاشتی کدت رو نزدیک کنن . نظر شما در مورد این بیانیه چیست؟ ارزش توجه شما را دارد؟ آیا به مدت 15 سال از الگوی get/set استفاده می کنید و آیا شما یک معمار محترم جاوا هستید؟ و شما حتی نمی خواهید به این مزخرفات یک غریبه گوش دهید؟ خوب ... من احساس شما را درک می کنم. من همین احساس را داشتم تا اینکه با کتاب «تفکر شیء» دیوید وست مواجه شدم - این بهترین کتابی است که در زمینه برنامه نویسی شی گرا خوانده ام. پس لطفا. آرام باشید و سعی کنید آنچه را که می خواهم توضیح دهم را بفهمید. موضوع مناقشه در جهان شی گرا، استدلال های متعددی علیه «اکسسسورها» (نام دیگری برای دریافت کننده ها و تنظیم کننده ها) وجود دارد. و همه آنها استدلال های بسیار درستی هستند. بیایید نگاهی گذرا به آنها بیندازیم. بپرس، نگو : آلن هولوب می‌گوید: «اطلاعاتی را که برای انجام یک کار به آن نیاز دارید نپرسید؛ «از نهادی که آن اطلاعات را دارد بخواهید کار را برای شما انجام دهد». اصل کپسولاسیون نقض شده : یک شی را می توان توسط اشیاء دیگر جدا کرد زیرا آنها می توانند هر داده ای را از طریق تنظیم کننده ها در شی جاسازی کنند. یک شی به سادگی نمی تواند حالت خود را به اندازه کافی ایمن محصور کند زیرا هر کسی می تواند آن حالت را تغییر دهد. جزئیات پیاده‌سازی آشکار شد : اگر می‌توانید یک شی را از یک شی دیگر دریافت کنید، پس ما بیش از حد به جزئیات پیاده‌سازی شی اول تکیه می‌کنیم. اگر فردا تغییر کرد (مثلاً نوع نتیجه)، پس باید کد را تغییر دهیم. همه توجیهات فوق قطعا منطقی هستند، اما این مهم ترین نکته را از دست می دهد. تصور غلط اساسی اکثر برنامه نویسان معتقدند که یک شی یک ساختار داده با روش است. من مقاله بوژیدار بوژانوف را نقل می کنم: گترها و ستترها شر نیستند. اما اکثر اشیایی که دریافت کننده ها و تنظیم کننده ها برای آنها ساخته شده اند به سادگی حاوی داده هستند. این تصور غلط نتیجه یک سوء تفاهم بزرگ است! اشیاء "فقط داده ها را ذخیره نمی کنند." اشیا ساختار داده ای نیستند که متدهای آن پیوست شده باشد. این مفهوم «ذخیره‌سازی داده» از برنامه‌نویسی شی‌گرا و زبان‌های رویه‌ای، به‌ویژه C و COBOL آمده است. دوباره تکرار می کنم: یک شی فقط مجموعه ای از عناصر داده و توابع نیست که آنها را دستکاری می کند. یک شی یک شی داده نیست. بعدش چی شد؟ توپ و سگ در برنامه نویسی شی گرا واقعی، اشیا موجوداتی زنده هستند، درست مثل من و شما. آنها موجودات زنده ای هستند که رفتار، خواص و چرخه زندگی خود را دارند. آیا موجود زنده می تواند ستتر داشته باشد؟ آیا می توانید یک توپ را به سگ وصل کنید ("تنظیم" کنید؟ فکر نکن اما این دقیقاً همان کاری است که قطعه کد زیر انجام می دهد:

Dog dog = new Dog();
dog.setBall(new Ball());

پس چگونه آن را دوست دارید؟ آیا می توانید توپ را از سگ خارج کنید ("دریافت")؟ خوب، بیایید فرض کنیم می توانید. اگر خورده باشد و شما او را جراحی کرده باشید. در این صورت، بله، شما قادر خواهید بود توپ را از سگ بگیرید ("دریافت" کنید). این دقیقاً همان چیزی است که من در مورد آن صحبت می کنم:

Dog dog = new Dog();
Ball ball = dog.getBall();

یا مثال مضحک تر:

Dog dog = new Dog();
dog.setWeight("23kg");

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

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

حالا ما با سگ به عنوان یک حیوان واقعی رفتار می کنیم که می تواند توپ را از ما بگیرد و اگر بخواهیم می تواند آن را پس بدهد. فقط در مورد، من توجه داشته باشید که سگ نمی تواند NULL را برگرداند. سگ ها فقط نمی دانند NULL چیست! تفکر عینی (تفکر) بلافاصله ارجاعات NULL را از کد شما حذف می کند. ماهی به نام واندا (1988) اثر چارلز کرایتون علاوه بر این، تفکر عینی منجر به تغییر ناپذیری یک شی، مانند "وزن سگ" در مثال ما می شود. شما می توانید کد را چیزی شبیه به این بازنویسی کنید:

Dog dog = new Dog("23kg");
int weight = dog.weight();

سگ یک موجود زنده غیرقابل تغییر است که به کسی اجازه نمی دهد وزن، اندازه، یا نام و غیره خود را تغییر دهد. او می تواند در صورت درخواست، وزن یا نام خود را "بگوید". هیچ اشکالی در روش‌های عمومی وجود ندارد که پرس‌و‌جوهایی را برای ویژگی‌های «داخلی» یک شی نشان می‌دهند. اما این روش‌ها «گیرنده» نیستند و هرگز نباید پیشوند «دریافت» را دریافت کنند. ما "از سگ" بیرون نمی آییم. ما نام او را نمی دانیم از او می خواهیم نامش را به ما بگوید. آیا تفاوت را میبینید؟ ما در اینجا حتی در مورد معناشناسی صحبت نمی کنیم. ما رویکرد رویه ای به برنامه نویسی را از شی گرا متمایز می کنیم. در برنامه‌نویسی رویه‌ای، ما با داده‌ها کار می‌کنیم، آن‌ها را دستکاری می‌کنیم، آن‌ها را دریافت می‌کنیم، تنظیم می‌کنیم و در صورت لزوم حذف می‌کنیم. ما مسئول هستیم و داده ها صرفاً یک جزء غیرفعال هستند. سگ برای ما چیزی نیست - فقط "حاوی داده ها" است. او زندگی خود را ندارد. ما می توانیم آزادانه هر آنچه را که نیاز داریم از آن دریافت کنیم (دریافت کنیم) و هر داده ای را در آن قرار دهیم. اینگونه است که C، COBOL، Pascal و سایر زبانهای رویه ای کار می کنند (کار می کنند). و وضعیت در دنیای شی گرا کاملا برعکس است. در اینجا ما اشیاء را به عنوان موجودات زنده، با تاریخ تولد و لحظه مرگ، با شخصیت و عادات خود، اگر دوست دارید، در نظر می گیریم. می توانیم از سگ بخواهیم که یک داده (مثلاً وزنش) به ما بدهد و او بتواند اطلاعات را به ما برگرداند. اما همیشه به یاد داشته باشید که سگ جزء فعال است. او تصمیم می گیرد بعد از درخواست چه اتفاقی بیفتد. و به همین دلیل است که شروع متدهای یک شی با set یا get کاملاً اشتباه است. و این حتی در مورد نقض کپسولاسیون نیست، همانطور که بسیاری از مردم فکر می کنند. این در مورد این واقعیت است که یا شما مانند یک شی فکر می کنید یا هنوز در حال نوشتن COBOL با نحو جاوا هستید. PS _ و بله، ممکن است بپرسید: "در مورد JavaBeans، JPA، JAXB و بسیاری دیگر از APIهای جاوا که به get/set بستگی دارند، چطور؟" در مورد عملکرد داخلی در Ruby که ایجاد دسترسی‌ها را آسان‌تر می‌کند، چطور؟ خب چی بهت بگم... شانست نیست. ماندن در دنیای بدوی COBOL رویه ای بسیار ساده تر از درک و در آغوش گرفتن دنیای شگفت انگیز اشیاء واقعی است. P.P.S. _ فراموش کردم بگویم، بله، درج وابستگی ها از طریق ستر نیز یک ضد الگوی وحشتناک است. اما بیشتر در مورد آن در پست بعدی! مقاله اصلی