Object-Oriented Reengineering Patterns

Β· Β·
Β· Elsevier
αžŸαŸ€αžœαž—αŸ…β€‹αž’αŸαž‘αž·αž…αžαŸ’αžšαžΌαž“αž·αž…
282
αž‘αŸ†αž–αŸαžš
αž˜αžΆαž“αžŸαž·αž‘αŸ’αž’αž·
αž€αžΆαžšαžœαžΆαž™αžαž˜αŸ’αž›αŸƒ αž“αž·αž„αž˜αžαž·αžœαžΆαž™αžαž˜αŸ’αž›αŸƒαž˜αž·αž“αžαŸ’αžšαžΌαžœαž”αžΆαž“αž•αŸ’αž‘αŸ€αž„αž•αŸ’αž‘αžΆαžαŸ‹αž‘αŸ αžŸαŸ’αžœαŸ‚αž„αž™αž›αŸ‹αž”αž“αŸ’αžαŸ‚αž˜

αž’αŸ†αž–αžΈαžŸαŸ€αžœαž—αŸ…β€‹αž’αŸαž‘αž·αž…αžαŸ’αžšαžΌαž“αž·αž€αž“αŸαŸ‡

The documentation is missing or obsolete, and the original developers have departed. Your team has limited understanding of the system, and unit tests are missing for many, if not all, of the components. When you fix a bug in one place, another bug pops up somewhere else in the system. Long rebuild times make any change difficult. All of these are signs of software that is close to the breaking point.Many systems can be upgraded or simply thrown away if they no longer serve their purpose. Legacy software, however, is crucial for operations and needs to be continually available and upgraded. How can you reduce the complexity of a legacy system sufficiently so that it can continue to be used and adapted at acceptable cost?Based on the authors' industrial experiences, this book is a guide on how to reverse engineer legacy systems to understand their problems, and then reengineer those systems to meet new demands. Patterns are used to clarify and explain the process of understanding large code bases, hence transforming them to meet new requirements. The key insight is that the right design and organization of your system is not something that can be evident from the initial requirements alone, but rather as a consequence of understanding how these requirements evolve.* Describes how to reverse engineer a monolithic system to understand how it really works and how to identify potential problems.* Includes reengineering patterns that tackle well-known reengineering techniques often encountered in object-oriented programming, such as introducing polymorphism, factoring out common behavior, detecting duplicated code, and understanding design.* Shows how to build a culture of continuous reengineering for achieving flexible and maintainable object-oriented systems.

αž’αŸ†αž–αžΈβ€‹αž’αŸ’αž“αž€αž“αž·αž–αž“αŸ’αž’

Serge Demeyer is a Professor in the Department of Mathematics and Computer Science at the University of Antwerp in Belgium. He also serves as a technical leader of the FAMOOS esprit project; a project whose goal is to come up with a set of reengineering techniques and tools to support the development of object-oriented frameworks. He has been involved in the organization of several workshops (at ECOOP and ESEC) and one tutorial concerning object-oriented reengineering.StΓ©phane Ducasse is a post doctoral researcher in the Software Composition Group in Berne, serving as technical leaders of the FAMOOS esprit project; a project whose goal it is to come up with a set of reengineering techniques and tools to support the development of object-oriented frameworks. He has been involved in the organization of several workshops (at ECOOP and ESEC) and one tutorial concerning object-oriented reengineering.Oscar Nierstrasz is a Professor of Computer Science at the University of Berne, where he leads the Software Composition Group. He has been active in the object-oriented research community for many years, serving on program committees of among others, ECOOP, OOPSLA and ESEC. He gave several tutorials and invited talks on object-oriented technology at various international conferences and workshops.

αžœαžΆαž™αžαž˜αŸ’αž›αŸƒαžŸαŸ€αžœαž—αŸ…β€‹αž’αŸαž‘αž·αž…αžαŸ’αžšαžΌαž“αž·αž€αž“αŸαŸ‡

αž”αŸ’αžšαžΆαž”αŸ‹αž™αžΎαž„αž’αŸ†αž–αžΈαž€αžΆαžšαž™αž›αŸ‹αžƒαžΎαž‰αžšαž”αžŸαŸ‹αž’αŸ’αž“αž€αŸ”

αž’αžΆαž“β€‹αž–αŸαžαŸŒαž˜αžΆαž“

αž‘αžΌαžšαžŸαž–αŸ’αž‘αž†αŸ’αž›αžΆαžαžœαŸƒ αž“αž·αž„β€‹αžαŸαž”αŸ’αž›αŸαž
αžŠαŸ†αž‘αžΎαž„αž€αž˜αŸ’αž˜αžœαž·αž’αžΈ Google Play Books αžŸαž˜αŸ’αžšαžΆαž”αŸ‹ Android αž“αž·αž„ iPad/iPhone αŸ” αžœαžΆβ€‹αž’αŸ’αžœαžΎαžŸαž˜αž€αžΆαž›αž€αž˜αŸ’αž˜β€‹αžŠαŸ„αž™αžŸαŸ’αžœαŸαž™αž”αŸ’αžšαžœαžαŸ’αžαž·αž‡αžΆαž˜αž½αž™β€‹αž‚αžŽαž“αžΈβ€‹αžšαž”αžŸαŸ‹αž’αŸ’αž“αž€β€‹ αž“αž·αž„β€‹αž’αž“αž»αž‰αŸ’αž‰αžΆαžαž±αŸ’αž™β€‹αž’αŸ’αž“αž€αž’αžΆαž“αž–αŸαž›β€‹αž˜αžΆαž“αž’αŸŠαžΈαž“αž’αžΊαžŽαž·αž αž¬αž‚αŸ’αž˜αžΆαž“β€‹αž’αŸŠαžΈαž“αž’αžΊαžŽαž·αžβ€‹αž“αŸ…αž‚αŸ’αžšαž”αŸ‹αž‘αžΈαž€αž“αŸ’αž›αŸ‚αž„αŸ”
αž€αž»αŸ†αž–αŸ’αž™αžΌαž‘αŸαžšβ€‹αž™αž½αžšαžŠαŸƒ αž“αž·αž„αž€αž»αŸ†αž–αŸ’αž™αžΌαž‘αŸαžš
αž’αŸ’αž“αž€αž’αžΆαž…αžŸαŸ’αžŠαžΆαž”αŸ‹αžŸαŸ€αžœαž—αŸ…αž‡αžΆαžŸαŸ†αž‘αŸαž„αžŠαŸ‚αž›αž”αžΆαž“αž‘αž·αž‰αž“αŸ…αž€αŸ’αž“αž»αž„ Google Play αžŠαŸ„αž™αž”αŸ’αžšαžΎαž€αž˜αŸ’αž˜αžœαž·αž’αžΈαžšαž»αž€αžšαž€αžαžΆαž˜αž’αŸŠαžΈαž“αž’αžΊαžŽαž·αžαž€αŸ’αž“αž»αž„αž€αž»αŸ†αž–αŸ’αž™αžΌαž‘αŸαžšαžšαž”αžŸαŸ‹αž’αŸ’αž“αž€αŸ”
eReaders αž“αž·αž„β€‹αž§αž”αž€αžšαžŽαŸβ€‹αž•αŸ’αžŸαŸαž„β€‹αž‘αŸ€αž
αžŠαžΎαž˜αŸ’αž”αžΈαž’αžΆαž“αž“αŸ…αž›αžΎβ€‹αž§αž”αž€αžšαžŽαŸ e-ink αžŠαžΌαž…αž‡αžΆβ€‹αž§αž”αž€αžšαžŽαŸαž’αžΆαž“β€‹αžŸαŸ€αžœαž—αŸ…αž’αŸαž‘αž·αž…αžαŸ’αžšαžΌαž“αž·αž€ Kobo αž’αŸ’αž“αž€αž“αžΉαž„αžαŸ’αžšαžΌαžœβ€‹αž‘αžΆαž‰αž™αž€β€‹αž―αž€αžŸαžΆαžš αž αžΎαž™β€‹αž•αŸ’αž‘αŸαžšαžœαžΆαž‘αŸ…β€‹αž§αž”αž€αžšαžŽαŸβ€‹αžšαž”αžŸαŸ‹αž’αŸ’αž“αž€αŸ” αžŸαžΌαž˜αž’αž“αž»αžœαžαŸ’αžαžαžΆαž˜β€‹αž€αžΆαžšαžŽαŸ‚αž“αžΆαŸ†αž›αž˜αŸ’αž’αž·αžαžšαž”αžŸαŸ‹αž˜αž‡αŸ’αžˆαž˜αžŽαŸ’αžŒαž›αž‡αŸ†αž“αž½αž™ αžŠαžΎαž˜αŸ’αž”αžΈαž•αŸ’αž‘αŸαžšαž―αž€αžŸαžΆαžšβ€‹αž‘αŸ…αž§αž”αž€αžšαžŽαŸαž’αžΆαž“αžŸαŸ€αžœαž—αŸ…β€‹αž’αŸαž‘αž·αž…αžαŸ’αžšαžΌαž“αž·αž€αžŠαŸ‚αž›αžŸαŸ’αž‚αžΆαž›αŸ‹αŸ”