[ Pobierz całość w formacie PDF ]
.38 The full method-call EDP design space: similar method.From the Library of Santiago Itzcoatl Salinas Reyna104Chapter 4: Working with EDPsSiblingSimilarSubtypeSimilarDissimilarDissimilar 1054.5 Why You May Want to Read the Appendixwhen we considered EDPs with similar methods.These two diagrams are just theleft and right sides of the same constructed space.They show where each EDP sitsin the design space defined by the three similarity axes we started with: method,object, and object type.Each EDP is related to the EDPs surrounding it by explicitchanges along those axes.Describing those changes gives us the view in Figure 4.39, by building on whatwe showed in Figure 4.35.This lists the change required to transform each method-call EDP into another one, a single step at a time, to provide the atomic refactoringsintroduced in the previous section.This diagram will be useful as the requirementsof a system change.You can better predict what the resulting system will look likeif you know where you will need to end up in this EDP space.The figure on the leftcorresponds to Figure 4.37, with the dissimilar methods, and the figure on the rightmatches up with Figure 4.38, with the similar methods.If the method similarityproperty of an EDP changes, you shift from the left to the right, or vice versa.For instance, if you implemented an instance of Recursion but need to breakup the task among multiple objects, the arrow labeled different object points youdirectly to Redirected Recursion.If instead you find that the Recursion needs to bebroken up into distinct subtasks, then you will be introducing new methods, andyou know that you will no longer retain the method similarity.In that case, the largearrow in the middle labeled dissimilar method indicates you should slide left to thecorresponding location on that tree, and you end up at Conglomeration.Each deci-sion point that you have at your disposal will lead you to the proper, related concept.When applying other refactoring actions, such as those from Fowler [19] andKerievsky [24], you will find those actions moving your design elements along theseroutes.By knowing ahead of time how the EDPs will change and shift, you canbetter predict where your design will end up and manage potential problems.These four diagrams are the conceptual core for understanding how theindividual EDPs relate to each other and how they provide possibilities for designalterations.As you read the following catalogs, you might want to refer back tothese figures to keep the larger picture in mind.While each design pattern is aself-contained concept, distinct relationships exist between them that form a richersystem for working with and reasoning about them as a group.4.5 Why You May Want to Read the AppendixOkay, so I m cheating a bit.I said that you didn t have to understand any of themathematics behind the EDPs to understand or use them.At this point, though,I m going to offer a couple of claims based on the formalisms, and you can eitherFrom the Library of Santiago Itzcoatl Salinas Reyna Revert Method Extend Methodsuper type self type self type super typedifferent object different objectConglomeration Recursiondifferent objectsame objectsame object different objectsimilar methodDelegated Conglomeration Redirected Recursiondifferent typesame type different type same typedissimilar methodsame type super typesuper type same typeDelegation Redirectioncreateremove create removesame objecttrustedtrusted trusted trusted same objectgroupgroup group groupTrusted Delegation Trusted Redirectionrelax trusted group restrict trusted group relax trusted grouprestrict trusted groupDeputized Delegation Deputized RedirectionFigure 4.39 Method-call EDP refactoring relations.From the Library of Santiago Itzcoatl Salinas Reyna106Chapter 4: Working with EDPs 1074.5 Why You May Want to Read the Appendixtake them on faith or you can go read the appendix to convince yourself of theirvalidity.I hope you re skeptical and dive in.First off, taken as a whole, the formal body of EDPs provides complete cover-age of the possible designs of object-oriented programming.Remember, this booktouches on only one-quarter, at best, of the possible EDPs that exist.It is simplyimpossible to write an object-oriented program without using the EDPs.Yes, Iknow that s a bold claim.Please read the formal tidbits for the full explanation.Hint: we established in Chapter 2 that binary relationships are the smallest rela-tionships we can form.Given a finite number of things between which we can formrelationships, there must be a finite number of possible relationships.Consideringwe re starting with only objects, methods, fields, and types, how small do you thinkthis set can get? If your answer is about the size of the Elemental Design Patterns, give yourself a cookie.That s precisely what the EDPs are: a project to describe all ofthe possible smallest relationships in object-oriented programming in human termsso that we can share, understand, and use them more effectively.This book is a start;I hope you join in for the remainder of the discussion.Second, the formalisms defined by the Á-calculus are fundamentally where theEDPs come from.Most design patterns are created by finding repeating solutionsby inspecting existing software systems.This approach lets us describe what we vedone before, which is critical, but EDPs are unique in that they are definable fromfirst principles, not just after the fact.To be sure, they are ubiquitously presentin existing systems, and those instances are what we use to discern the intent ofand write the specification for the EDP, just as with any other design pattern.TheEDP design spaces defined by our orthogonal axes of context, however, provide aframework for filling in gaps we didn t realize we had and for establishing exactlyhow the EDPs relate to one another.The difference is akin to that between early mechanical engineers sharingblueprints for creations that they designed through trial and error and modern engi-neers able to simulate a complete design before ever fabricating a single part.Theformer is a description of what was tried; the latter prediction is based on formalreasoning and modeling.EDPs enable us to describe systems precisely and pre-dict what impact even the smallest changes will have.Furthermore, as you saw withthe reconstruction of Decorator, EDPs let us work with large abstractions at vary-ing levels of granularity based on the needs of the moment.EDPs also enable usto describe new design patterns as they are found, composing their definitions interms of existing abstractions.There s really no end to the possibilities [ Pobierz caÅ‚ość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl odbijak.htw.pl
.38 The full method-call EDP design space: similar method.From the Library of Santiago Itzcoatl Salinas Reyna104Chapter 4: Working with EDPsSiblingSimilarSubtypeSimilarDissimilarDissimilar 1054.5 Why You May Want to Read the Appendixwhen we considered EDPs with similar methods.These two diagrams are just theleft and right sides of the same constructed space.They show where each EDP sitsin the design space defined by the three similarity axes we started with: method,object, and object type.Each EDP is related to the EDPs surrounding it by explicitchanges along those axes.Describing those changes gives us the view in Figure 4.39, by building on whatwe showed in Figure 4.35.This lists the change required to transform each method-call EDP into another one, a single step at a time, to provide the atomic refactoringsintroduced in the previous section.This diagram will be useful as the requirementsof a system change.You can better predict what the resulting system will look likeif you know where you will need to end up in this EDP space.The figure on the leftcorresponds to Figure 4.37, with the dissimilar methods, and the figure on the rightmatches up with Figure 4.38, with the similar methods.If the method similarityproperty of an EDP changes, you shift from the left to the right, or vice versa.For instance, if you implemented an instance of Recursion but need to breakup the task among multiple objects, the arrow labeled different object points youdirectly to Redirected Recursion.If instead you find that the Recursion needs to bebroken up into distinct subtasks, then you will be introducing new methods, andyou know that you will no longer retain the method similarity.In that case, the largearrow in the middle labeled dissimilar method indicates you should slide left to thecorresponding location on that tree, and you end up at Conglomeration.Each deci-sion point that you have at your disposal will lead you to the proper, related concept.When applying other refactoring actions, such as those from Fowler [19] andKerievsky [24], you will find those actions moving your design elements along theseroutes.By knowing ahead of time how the EDPs will change and shift, you canbetter predict where your design will end up and manage potential problems.These four diagrams are the conceptual core for understanding how theindividual EDPs relate to each other and how they provide possibilities for designalterations.As you read the following catalogs, you might want to refer back tothese figures to keep the larger picture in mind.While each design pattern is aself-contained concept, distinct relationships exist between them that form a richersystem for working with and reasoning about them as a group.4.5 Why You May Want to Read the AppendixOkay, so I m cheating a bit.I said that you didn t have to understand any of themathematics behind the EDPs to understand or use them.At this point, though,I m going to offer a couple of claims based on the formalisms, and you can eitherFrom the Library of Santiago Itzcoatl Salinas Reyna Revert Method Extend Methodsuper type self type self type super typedifferent object different objectConglomeration Recursiondifferent objectsame objectsame object different objectsimilar methodDelegated Conglomeration Redirected Recursiondifferent typesame type different type same typedissimilar methodsame type super typesuper type same typeDelegation Redirectioncreateremove create removesame objecttrustedtrusted trusted trusted same objectgroupgroup group groupTrusted Delegation Trusted Redirectionrelax trusted group restrict trusted group relax trusted grouprestrict trusted groupDeputized Delegation Deputized RedirectionFigure 4.39 Method-call EDP refactoring relations.From the Library of Santiago Itzcoatl Salinas Reyna106Chapter 4: Working with EDPs 1074.5 Why You May Want to Read the Appendixtake them on faith or you can go read the appendix to convince yourself of theirvalidity.I hope you re skeptical and dive in.First off, taken as a whole, the formal body of EDPs provides complete cover-age of the possible designs of object-oriented programming.Remember, this booktouches on only one-quarter, at best, of the possible EDPs that exist.It is simplyimpossible to write an object-oriented program without using the EDPs.Yes, Iknow that s a bold claim.Please read the formal tidbits for the full explanation.Hint: we established in Chapter 2 that binary relationships are the smallest rela-tionships we can form.Given a finite number of things between which we can formrelationships, there must be a finite number of possible relationships.Consideringwe re starting with only objects, methods, fields, and types, how small do you thinkthis set can get? If your answer is about the size of the Elemental Design Patterns, give yourself a cookie.That s precisely what the EDPs are: a project to describe all ofthe possible smallest relationships in object-oriented programming in human termsso that we can share, understand, and use them more effectively.This book is a start;I hope you join in for the remainder of the discussion.Second, the formalisms defined by the Á-calculus are fundamentally where theEDPs come from.Most design patterns are created by finding repeating solutionsby inspecting existing software systems.This approach lets us describe what we vedone before, which is critical, but EDPs are unique in that they are definable fromfirst principles, not just after the fact.To be sure, they are ubiquitously presentin existing systems, and those instances are what we use to discern the intent ofand write the specification for the EDP, just as with any other design pattern.TheEDP design spaces defined by our orthogonal axes of context, however, provide aframework for filling in gaps we didn t realize we had and for establishing exactlyhow the EDPs relate to one another.The difference is akin to that between early mechanical engineers sharingblueprints for creations that they designed through trial and error and modern engi-neers able to simulate a complete design before ever fabricating a single part.Theformer is a description of what was tried; the latter prediction is based on formalreasoning and modeling.EDPs enable us to describe systems precisely and pre-dict what impact even the smallest changes will have.Furthermore, as you saw withthe reconstruction of Decorator, EDPs let us work with large abstractions at vary-ing levels of granularity based on the needs of the moment.EDPs also enable usto describe new design patterns as they are found, composing their definitions interms of existing abstractions.There s really no end to the possibilities [ Pobierz caÅ‚ość w formacie PDF ]