Mixin: Difference between revisions
m minor grammar typo |
No edit summary |
||
Line 4: | Line 4: | ||
A mixin can also be viewed as an interface with implemented methods. When a class includes a mixin, the class implements the interface and includes, not inherits, all the mixin's attributes and methods. They become part of the class during compilation. Interestingly enough mixins don't need to implement an interface. The advantage of implementing an interface is obvious so that the class may be passed to methods requiring that interface. |
A mixin can also be viewed as an interface with implemented methods. When a class includes a mixin, the class implements the interface and includes, not inherits, all the mixin's attributes and methods. They become part of the class during compilation. Interestingly enough mixins don't need to implement an interface. The advantage of implementing an interface is obvious so that the class may be passed to methods requiring that interface. |
||
A mixin can defer definition and binding of methods until runtime, though attributes and instantiation parameters are still defined at compile time. This differs from the most widely-used approach, which originated in the programming language [[Simula]], of defining all attributes, methods and initialization at compile time. |
A mixin can defer definition and binding of methods until [[runtime]], though attributes and instantiation parameters are still defined at [[compile time]]. This differs from the most widely-used approach, which originated in the programming language [[Simula]], of defining all attributes, methods and initialization at compile time. |
||
Mixins were first used in [[Flavors (computer science)|Flavors]], which was an approach to object-orientation used in [[Lisp Machine Lisp]]. The advantage of mixins is that they encourage [[code reuse]] and avoid well-known pathologies associated with [[multiple inheritance]]. However, mixins introduce their own set of compromises. |
Mixins were first used in [[Flavors (computer science)|Flavors]], which was an approach to object-orientation used in [[Lisp Machine Lisp]]. The advantage of mixins is that they encourage [[code reuse]] and avoid well-known pathologies associated with [[multiple inheritance]]. However, mixins introduce their own set of compromises. |
Revision as of 15:28, 8 February 2008
This article provides insufficient context for those unfamiliar with the subject. |
In object-oriented programming languages, a mixin is a class that provides a certain functionality to be inherited by a subclass, but is not meant to stand alone. Inheriting from a mixin is not a form of specialization but is rather a means to collect functionality. A subclass may even choose to inherit most or all of its functionality by inheriting from one or more mixins through multiple inheritance.
A mixin can also be viewed as an interface with implemented methods. When a class includes a mixin, the class implements the interface and includes, not inherits, all the mixin's attributes and methods. They become part of the class during compilation. Interestingly enough mixins don't need to implement an interface. The advantage of implementing an interface is obvious so that the class may be passed to methods requiring that interface.
A mixin can defer definition and binding of methods until runtime, though attributes and instantiation parameters are still defined at compile time. This differs from the most widely-used approach, which originated in the programming language Simula, of defining all attributes, methods and initialization at compile time.
Mixins were first used in Flavors, which was an approach to object-orientation used in Lisp Machine Lisp. The advantage of mixins is that they encourage code reuse and avoid well-known pathologies associated with multiple inheritance. However, mixins introduce their own set of compromises.
Definition and implementation
In Simula, classes are defined in a block in which attributes, methods and class initialization are all defined together; thus all the methods that can be invoked on a class are defined together, and the definition of the class is complete.
With mixins the class definition defines only the attributes and parameters associated with that class; methods are left to be defined elsewhere, as in Flavors and CLOS, and are called "generic functions". These generic functions are functions which are defined in multiple cases by type dispatch.
Other than Flavors and CLOS, some languages that use mixins are:
- D (called "template mixins")
- Dylan
- Perl
- Python
- Ruby
- Scala
- Strongtalk
- XOTcl (an object system for Tcl)
Some languages like ECMAScript (commonly referred to as JavaScript) do not support mixins on the language level, but can easily mimic them by copying methods from one object to another at runtime, thereby "borrowing" the mixin's methods. Note that this is not possible with statically typed languages, where an object's signature is fixed at compile time.
Example
In Python, the SocketServer module has both a UDPServer and TCPServer class that act as a server for UDP and TCP socket servers. Normally, all new connections are handled within the same process. Additionally, there are two mixin classes: ForkingMixIn and ThreadingMixIn. By extending TCPServer with the ThreadingMixIn like this
class ThreadingTCPServer(ThreadingMixIn, TCPServer): pass
the ThreadingMixIn class adds functionality to the TCP server such that each new connection creates a new thread. Alternatively, using the ForkingMixIn would cause the process to be forked for each new connection. Clearly, the functionality to create a new thread or fork a process is not terribly useful as a stand-alone class.
In this usage example, the mixins provide alternative underlying functionality without affecting the functionality as a socket server.
Commentary
Some of the functionality of mixins is provided by interfaces in popular languages like Java and C#. However, since an interface only specifies what the class must support and cannot provide an implementation, it is only useful for providing polymorphism. Another class, providing an implementation and dependent with the interface, is useful for refactoring common behavior into a single place.
Interfaces combined with aspect-oriented programming can produce full fledged mixins in languages that support such features, such as C# or Java.
Mixins first appeared in the Symbolics' object-oriented Flavors system, and the name was inspired by Steve's Ice Cream Parlor in Somerville, Massachusetts. [1] The ice cream shop owner offered a basic flavor of ice cream (vanilla, chocolate, etc.) and blended in a combination of extra items (nuts, cookies, fudge, etc.) and called the item a "Mix-In", his own trademarked term at the time. [2]
See also
References
External links
- Wiki entry at Cunningham & Cunningham, Inc.
- Mixins in ActionScript.
- Scala Overview: Mixin Class Composition - a step-by-step example in Scala
- The Common Lisp Object System: An Overview by Richard P. Gabriel and Linda DeMichiel provides a good introduction to the motivation for defining classes by means of generic functions.