دسترسی نامحدود
برای کاربرانی که ثبت نام کرده اند
برای ارتباط با ما می توانید از طریق شماره موبایل زیر از طریق تماس و پیامک با ما در ارتباط باشید
در صورت عدم پاسخ گویی از طریق پیامک با پشتیبان در ارتباط باشید
برای کاربرانی که ثبت نام کرده اند
درصورت عدم همخوانی توضیحات با کتاب
از ساعت 7 صبح تا 10 شب
دسته بندی: برنامه نويسي ویرایش: 1st نویسندگان: Karl Lieberherr سری: ISBN (شابک) : 9780534946029, 053494602X ناشر: Pws Pub Co سال نشر: 1995 تعداد صفحات: 651 زبان: English فرمت فایل : DJVU (درصورت درخواست کاربر به PDF، EPUB یا AZW3 تبدیل می شود) حجم فایل: 3 مگابایت
در صورت تبدیل فایل کتاب Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns: The Demeter Method with Propagation Patterns به فرمت های PDF، EPUB، AZW3، MOBI و یا DJVU می توانید به پشتیبان اطلاع دهید تا فایل مورد نظر را تبدیل نمایند.
توجه داشته باشید کتاب نرم افزار Object Oriented نرم افزاری: روش Demeter با الگوهای انتشار: روش Demeter با الگوهای انتشار نسخه زبان اصلی می باشد و کتاب ترجمه شده به فارسی نمی باشد. وبسایت اینترنشنال لایبرری ارائه دهنده کتاب های زبان اصلی می باشد و هیچ گونه کتاب ترجمه شده یا نوشته شده به فارسی را ارائه نمی دهد.
قانون Demeter مدتهاست که به عنوان یک روش اثبات شده برای افزایش قابلیت اطمینان و نگهداری کد پذیرفته شده است. این کتاب ایدههای قانون را بسیار کاملتر توسعه میدهد، آنها را در ابزارهایی که مکمل C++ هستند، کدگذاری میکند، و آنها را به عنوان یک کتاب درسی برای دوره پیشرفته OO یا مهندسی نرمافزار ارائه میکند. ایده تطبیقی به دو مشکل بومی نرم افزار OO می پردازد. اولین مشکل شکنندگی نرم افزار است. نویسندگان "نشت" ساختاری را به عنوان دلیل اصلی این مشکل - گسترش دانش ساختار یک طبقه به طبقات اطراف آن معرفی می کنند. این تغییر را خطرناکتر و دشوارتر میکند، زیرا هر تغییری در برخی کلاسها احتمال نیاز به تغییرات تطبیقی با سایر ماژولها را دارد، در یک ریپلی که همیشه در حال گسترش است. دومین مشکلی که به آن پرداخته شد در تلاش برای رفع مشکل اول بوجود می آید. یک ماژول بهجای افشای اجزای داخلی خود، میتواند روشهایی را صادر کند که درخواستهای سرویس را به اشیاء محتوی ارسال میکنند، در زنجیرههایی که میتوانند به اندازهای طولانی شوند که بر عملکرد تأثیر بگذارند. دستههایی از این روشهای کوچک، کلاسهایی را که حاوی آنها هستند پر میکنند، و همچنین انواع پیمایشهای ساختار داده ممکن را محدود میکنند. سازگاری با \"فرهنگ لغت کلاس\" شروع میشود، نقشه کلاسها در یک برنامه با روابط جمعآوری و طبقهبندی فرعی بین آنها، که در نمادهای قبل از UML نشان داده شده است. این پایگاههای اطلاعاتی شبکهگرای CODASYL را که قبل از انقلاب رابطهای در دهه 1980 بود، به یاد میآورد. این مدل به خوبی با الگوی طراحی بازدیدکننده هماهنگ است، اما امکان بسیاری از انواع پیمایش های زیرمجموعه های وابسته به پیوند را با الهام از معناشناسی غنی پرس و جوهای پایگاه داده CODASYL اضافه می کند. الگوی بازدیدکننده مستلزم این است که هر کلاس در پیمایش درونیهای خود واسطه شود، که بهطور بالقوه در هر کلاس برای هر نوع جدید پیمایش تغییر میکند. نرم افزار تطبیقی یک زبان پرس و جو را به کد اضافه می کند (که می توانست در یک چارچوب بازتابی انجام شود). این نه تنها هر نوع پیمایش را متمرکز میکند، بلکه قوانین و محدودیتهای ضمنی را اضافه میکند که از نیاز به نامگذاری هر کلاس در هر پیمایش اجتناب میکند. در نتیجه، یک قانون پیمایش حتی زمانی که تغییرات عظیم شکل شبکه دادهای را که در حال عبور است تغییر میدهد، به کار خود ادامه میدهد. اشیاء بازدیدکننده، قطعات کدی که در هر گره در شبکه اجرا میشوند، در تعاریف پیمایش ظاهر میشوند، نه در خود اشیاء داده - به عبارت دیگر، اشیاء داده نیازی به پیادهسازی پاسخ برای هر سؤالی که ممکن است از آنها باشد، ندارند. با توجه به چند نمونه ابتدایی سطح پایین در هر شی داده، درخواست های سرویس تقریباً به عنوان خود اشیا تشکیل می شوند. این به کدهای تطبیقی طعم جنبه گرا می دهد. تفاوت بزرگ این است که برش های متقاطع جنبه گرا معمولاً به نقاط ورودی سرویس در هر شی می پردازند. در مقابل، کد تطبیقی برش های متقاطع خود را در اتصالات بین اشیا ایجاد می کند. این امر به جای پرداختن به نقاط ورودی منفرد، حساسیت زمینه اشیاء فرعی را به سایرین خاص یا به پیمایشهای وحشیانه شبکههای شی اضافه میکند - یک بهبود واقعی در قدرت بیان. نرم افزار تطبیقی چند بار به صورت تجاری آزمایش شده است، با نتایج ظاهراً خوبی، اما موفق نشده است. کمی \"آن بیرون\" مفاهیم جدید زیادی را به کد اضافه می کند و احتمالاً محدودیت های زیادی را برای راحتی بیشتر برنامه نویسان OO تحمیل می کند - حتی اگر این محدودیت ها عملکردهای کد را بهبود بخشد. اثرات گسترده پرس و جوهای تطبیقی نیز بر خلاف روش چابک آزمایش واحدهای جدا شده عمل می کند، زیرا تطبیق ذاتاً شبکه های گسترده و مشخصی از اشیاء را کنترل می کند. ابزارهای تطبیقی به جای شگفتی های تحقیقاتی، تحولات ماجراجویانه و انحصاری ایده های منفرد باقی می مانند. پذیرش گستردهتر مستلزم این است که ایدهها به شکل بلوک ساختمانی ظاهر شوند تا بتوان آنها را در جریانهای توسعه نرمافزار پیچیدهای که حول ابزارهای بهطور گستردهای پذیرفته شدهاند، ادغام کرد. بسیاری از مفاهیم مفید به نظر می رسند. احتمالاً آنها را با انواع پیمایش بازتابی سلسله مراتب اشیا تطبیق خواهم داد. با این حال، در کل، من روش شناسی تطبیقی را در کابینه کنجکاوی های مهندسی نرم افزار ثبت خواهم کرد. - عجیب و غریب
The Law of Demeter has long been accepted as a proven way of increasing code's reliability and maintainability. This book develops the Law's ideas far more fully, codifies them in tools that supplement C++, and presents them as a textbook for an advance OO or software engineering course. The Adaptive idea addresses two problems endemic to OO software. The first problem is software's brittleness. The authors identify structural "leakage" as a major cause of this problem - the spread of knowledge of one class's structure into the classes around it. That makes change riskier and more difficult, since any change within some class has some chance of requiring matching changes to other modules, in an ever-expanding ripple. The second problem addressed arises in trying to fix the first. Rather than expose its internals, a module can export methods that dispatch service requests to contained objects, in chains that can become long enough to affect performance. Flocks of these mini-methods bloat the classes that contain them, and also constrain the kinds of data structure traversals possible. Adaptiveness starts with the "class dictionary," the map of classes in a program with the aggregation and subclassing relationships between them, represented in pre-UML notations. This brings to mind the CODASYL network-oriented databases that preceded the Relational revolution in the 1980s. That model meshes nicely with the Visitor design pattern, but adds the possibility of many link-dependent kinds of traversals of traversals of subsets inspired by the rich semantics of CODASYL database queries. The Visitor pattern requires each class to mediate traversal of its own internals, implying changes to potentially every class for each new kind of traversal. Adaptive software adds a query language to the code (which could have been done in a reflective framework). This not only centralizes each kind of traversal, but adds implicit rules and constraints that avoid the need to name every class in every traversal. As a result, one traversal rule keeps working even when massive changes alter the shape of the data network being traversed. The Visitor objects, code fragments that execute at each node in the network, appear in the traversal definitions, not in the data objects themselves - in other words, data objects need not implement answers to every question that might be asked of them. Given a few low-level primitives in each data object, service requests are composed almost as objects themselves. This gives the Aspect-oriented flavor of Adaptive code. The big difference is that Aspect-oriented cross-cuts typically address the service entry points in each object. In contrast, Adaptive code makes its cross-cuts at the connections between objects. Instead of addressing just individual entry points, this adds the context sensitivity of objects subsidiary to specific others, or to wild-carded traversals of object networks - a real improvement in expressive power. Adaptive software has been tried a few times commercially, with supposedly good results, but has not caught on. It's a bit "out there," would add too many new concepts to code, and would probably impose too many restrictions for most OO programmers' comfort - even if those restriction improve the -ilities of the code. Adaptive queries' wide-ranging effects also work against the Agile practice of testing isolated units, since Adaptiveness inherently handles broad and loosely-specified networks of objects. The Adaptive tools remain research oddities, adventurous and exclusive developments of single ideas rather. Wider acceptance would require the ideas to appear in building-block form so they could be incorporated into complex software development flows built around widely accepted tools. Many of the concepts appear useful; I'll probably adapt them to some kinds of reflective traversals of object hierarchies. On the whole, however, I'll file Adaptive methodology in the cabinet of software engineering curiosities. -- wiredweird