Software Engineering Research Roundup: The Composability of Design Patterns

DZone 's Guide to

Software Engineering Research Roundup: The Composability of Design Patterns

First in an ongoing series presenting recent practical and bleeding-edge industry and academic research in software engineering, computer science, and related fields.

· Java Zone ·
Free Resource

Software engineers make things work; software engineering researchers figure out how and why what developers do makes things work correctly.

So today we're starting a new series on DZone: the Software Engineering Research Roundup, a regular report on commercial and academic research that analyzes what developers are already doing, suggests new ways to tackle common software engineering problems, and previews some bleeding-edge systems that may reach production readiness in the next few years.

Target quantity: three papers reviewed every week. Will take a little spinup -- this week we'll start with just one. 

To start we'll be looking mainly at recently published IEEE and ACM journals, preprints in the arxiv.org Computing Research Repository, and papers from Google, Microsoft, and Facebook research. The first batch will be a little random (more to know that can ever be known arrggh) but we'll build some focus in response to your feedback. We'll expand our sources list (and time-scale) over the next few months. Feel free to email me with any projects or research areas you find particularly exciting.

Disclaimer: I still sling code but haven't done so full-time in a while, and I'm not an academic software engineering researcher by any stretch. But I find this stuff fascinating and actually very useful -- either to sharpen current practices or to peek at what's coming down the compsci and softeng road. We'll steer as your feedback indicates.

1. On the Composability of Design Patterns

Hong Zhu; Bayley, I., "On the Composability of Design Patterns," in Software Engineering, IEEE Transactions on , vol.41, no.11, pp.1138-1152, Nov. 1 2015

Somewhere on the concreteness spectrum between best practices and state machines are [often but not always object-oriented] design patterns — reusable solutions to common problems, but non-specific enough to help in diverse contexts with some modification. 

Each design pattern is simple by design. Need to respond to user interaction? Define abstract Subject and Observer interfaces, instantiate on buttons, form fields, scroll bars, whatever. But of course no design pattern stands alone. Corner stores are simple; the ways corner stores make money, affect nearby supermarkets, respond to car traffic patterns, are complex. Design patterns can be dangerous in their simplicity. We love not to re-invent the wheel; we love re-usable solutions; so it's tempting to try to fit a square problem in a round pattern hole.

But which design patterns fit together how, and how do you know how they fit before scattershotting your Gamma, Johnson, and Helm?

Well, if you squint a little, 'how design patterns fit together' is just the higher-level composability analogate of program correctness. Turns out a lot of such squinting has been done before, but nothing quite as practical as this paper published a month ago.

The first five sections present a pretty dry formalism: define design pattern composition and instantiation (including notions of feature, semantics, and soundness preservation narrowed to this formalization), focusing on component overlap across composed patterns; verify validity of pattern compositions using this formalism.

The case study (section 7, p1146) is where things get interesting. Zhu and Bayley suggest an informal-and-seems-reasonable design for a simple request responder that stitches several common OO design patterns together (in a diagram that looks like any other boxes-and-arrows picture). The break that their formal validity test locates is subtle but could easily prevent the rollback that the Memento pattern is trying to accomplish (the role of state creator switches silently from Originator to Caretaker).

If you don't foresee an automated theorem prover to check your design pattern compositions for validity, then you don't need to understand the formalism in detail -- just read section 7.

That's all for our first edition -- looking forward to your thoughts. What subtle problems have you run into when stitching design patterns together? Would an automated way to check pattern composition validity help much?

And at a meta-level for this series as a whole: do you prefer more detail, less background, more context, different topics..? Or more broadly: what kind of research would help you most?

research ,software engineering ,design patterns

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}