Editing Software design pattern (section)

=== [[Structural pattern]]s ===
{| class="wikitable"
|-
! Name
! Description
! In ''[[Design Patterns]]''
! In ''[[Code Complete]]''<ref name="McConnell2004" />
! Other
|-
| [[Adapter pattern|Adapter]], Wrapper, or Translator
| Convert the interface of a class into another interface clients expect. An adapter lets classes work together that could not otherwise because of incompatible interfaces. The enterprise integration pattern equivalent is the translator.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Bridge pattern|Bridge]]
| Decouple an abstraction from its implementation allowing the two to vary independently.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Composite pattern|Composite]]
| Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Decorator pattern|Decorator]]
| Attach additional responsibilities to an object dynamically keeping the same interface. Decorators provide a flexible alternative to subclassing for extending functionality.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Delegation pattern|Delegation]]
| Extend a class by composition instead of subclassing. The object handles a request by delegating to a second object (the delegate)
| {{yes}}
| {{yes}}
| {{yes}}
|-
| Extension object
| Adding functionality to a hierarchy without changing the hierarchy.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Facade pattern|Facade]]
| Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Flyweight pattern|Flyweight]]
| Use sharing to support large numbers of similar objects efficiently.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Front controller]]
| The pattern relates to the design of Web applications. It provides a centralized entry point for handling requests.
| {{yes}}
| {{yes}}
| {{yes|
{{abbr|J2EE Patterns|Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition)}}<ref name = "J2EE Patterns">
{{cite book
 | first1 = Deepak
 | last1 = Alur
 | first2 = John | last2 = Crupi | first3 = Dan | last3 = Malks
 | year = 2003
 | title = Core J2EE Patterns: Best Practices and Design Strategies
 | page = 166
 | publisher = [[Prentice Hall]]
 | isbn = 978-0-13-142246-9
 | url = http://www.corej2eepatterns.com
}}</ref>
{{abbr|PoEAA|Patterns of Enterprise Application Architecture}}<ref name = "PoEAA2">
{{cite book
 | first = Martin
 | last = Fowler
 | author-link = Martin Fowler (software engineer)
 | year = 2002
 | title = Patterns of Enterprise Application Architecture
 | page = 344
 | publisher = [[Addison-Wesley]]
 | isbn = 978-0-321-12742-6
 | url = http://martinfowler.com/books.html#eaa
}}</ref>}}
|-
| [[Marker interface pattern|Marker]]
| Empty interface to associate metadata with a class.
| {{yes}}
| {{yes}}
| {{yes|[[Joshua Bloch|Effective Java]]<ref name="EffectiveJava">
{{cite book
 | last = Bloch
 | first = Joshua
 | title = Effective Java
 | page = [https://archive.org/details/effectivejava00bloc_0/page/179 179]
 | chapter = Item 37: Use marker interfaces to define types
 | year = 2008
 | isbn = 978-0-321-35668-0
 | publisher = Addison-Wesley
 | chapter-url = https://archive.org/details/effectivejava00bloc_0/page/179
 | edition = Second
 }}</ref>}}
|-
| [[Module pattern|Module]]
| Group several related elements, such as classes, singletons, methods, globally used, into a single conceptual entity.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Proxy pattern|Proxy]]
| Provide a surrogate or placeholder for another object to control access to it.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Twin pattern|Twin]]<ref>{{cite web|url=http://www.ssw.jku.at/Research/Papers/Moe99/Paper.pdf |title=Twin – A Design Pattern for Modeling Multiple Inheritance }}</ref>
| Twin allows modeling of multiple inheritance in programming languages that do not support this feature.
| {{yes}}
| {{yes}}
| {{yes}}

|}