Event Library: An Object-Oriented Library for Event-Driven Design

Arslan, Volkan; Nienaltowski, Piotr; Arnout, Karine

doi:10.1007/978-3-540-45213-3_22

Cited by 5 publications

(1 citation statement)

References 1 publication

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our first pattern analysis, targeting the Observer pattern, led to successful componentization through the Event Library [6,28] covering the general idea of publishsubscribe and event-driven development. This provided the basis for the componentization of other patterns including Visitor [29], Composite, Factory as described below, and others all yielding reusable components in the Pattern Library.…”

Section: Overviewmentioning

confidence: 99%

Pattern Componentization: The Factory Example

Arnout

Meyer

2006

Innovations Syst Softw Eng

Self Cite

View full text Add to dashboard Cite

Can Design Patterns be turned into reusable components? To help answer this question, we have performed a systematic study of the standard design patterns. One of the most interesting is Abstract Factory, for which we were indeed able to build a reusable component fulfilling the same needs as the original pattern. This article presents the component's design and its lessons for the general issue of pattern componentization. Patterns and componentsIn hardly more than a decade, Design Patterns have established themselves as a major resource for effective software design. "Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to this problem" [17]. Thanks to the published catalogs of such solutions, starting with [17] itself, software designers can benefit from the wisdom and experience of their predecessors. The idea that we should avoid reinventing the wheel in software construction predates patterns by a long time; reuse is a running theme in standard discussions of software engineering. The idea of reuse is to provide software components covering standard needs and make them available through a standard API (Abstract Program Interface 1 ) to any program that experiences the corresponding needs.For all the benefits of design patterns, it is hard to ignore that the idea as usually expressed runs contrary to decades of advances in reuse, which have profoundly improved the state of software development. Pattern advocates themselves often sound skeptical about reuse. The preceding citation was actually truncated: the full sentence states that a pattern describes the core of the solution to the problem "in such a way that you can use this solution a million times over, without ever doing it the same way twice". The pattern literature frequently confirms this view that patterns are not reusable components; for example [20]: "Patterns are not, by definition, fully formalized descriptions. They can't appear as a deliverable".Why not? It is hard to accept that patterns, however useful, should force us to step back to pre-reuse times, when sorting an array required finding a solution outline in an algorithms textbook and then adapting it to your needs. Today we use library routines for such tasks. Patterns should provide similarly reusable solution at a higher level of granularity. Inexplicably, the pattern lit-1 The original expansion of "API", "Application Program Interface", apparently going back to old IBM software, is no longer meaningful. The acronym itself remains well-understood and relevant. We expand it as "Abstract Program Interface", which captures the idea precisely.

show abstract

Section: Overviewmentioning

confidence: 99%