A modest proposal for curing the public field phobia
ACM SIGPLAN Notices
Proceedings of the 12th ACM SIGSOFT twelfth international symposium on Foundations of software engineering
Sometimes you need to see through walls: a field study of application programming interfaces
CSCW '04 Proceedings of the 2004 ACM conference on Computer supported cooperative work
Bridging the gap between technical and social dependencies with Ariadne
eclipse '05 Proceedings of the 2005 OOPSLA workshop on Eclipse technology eXchange
Proceedings of the 2007 international ACM conference on Supporting group work
On The Roles of APIs in the Coordination of Collaborative Software Development
Computer Supported Cooperative Work
A pattern-based verification approach for a multi-core system development
Proceedings of the 2011 ACM Symposium on Applied Computing
Recommending Adaptive Changes for Framework Evolution
ACM Transactions on Software Engineering and Methodology (TOSEM)
A field study of API learning obstacles
Empirical Software Engineering
Seeking the ground truth: a retroactive study on the evolution and migration of software libraries
Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering
Integrating semantic Web services ranking mechanisms using a common preference model
Knowledge-Based Systems
Visualizing protected variations in evolving software designs
Journal of Systems and Software
Hi-index | 0.00 |
The Pattern Almanac 2000 (Addison Wesley, 2000) lists around 500 software-related patterns, and given this reading list, the curious developer has no time to program! Of course, there are underlying, simplifying themes and principles to this pattern plethora that developers have long considered and discussed. One example is L. Constantine's (1974) coupling and cohesion guidelines. Yet, these principles must continually resurface to help each new generation of developers and architects cut through the apparent disparity in myriad design ideas and help them see the underlying and unifying forces. One such principle, which B. Meyer (1988) describes is the Open-Closed Principle (OCP): modules should be both open (for extension and adaptation) and closed (to avoid modification that affect clients). OCP is essentially equivalent to the Protected Variation (PV) pattern: identify points of predicted variation and create a stable interface around them. OCP and PV formalize and generalize a common and fundamental design principle described in many guises. OCP and PV are two expressions of the same principle: protection against change to the existing code and design at variation and evolution points, with minor differences in emphasis