Trait (computer programming): Difference between revisions

Content deleted Content added
I've started documenting some known limitations of traits. Sadly, the references to this are largely my communications with the trait researchers and years of personal experience.
Simplify the article by breaking out the "non-technical" (for programmers) explanation into a "Rationale" section.
Line 4:
In [[computer programming]], a '''trait''' is a concept used in [[object-oriented programming]] which represents a set of [[Method (computer programming)|methods]] that can be used to extend the functionality of a [[Class (computer science)|class]].<ref name="schaerli-ecoop-2003">{{cite journal | first1=Nathanael | last1=Schärli | first2=Stéphane | last2=Ducasse | first3=Oscar | last3=Nierstrasz | author-link3=Oscar Nierstrasz | first4=Andrew P. | last4=Black | url=http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf | title=Traits: Composable Units of Behaviour | journal=Proceedings of the European Conference on Object-Oriented Programming (ECOOP). | series=Lecture Notes in Computer Science | volume=2743 | year=2003 | pages=248–274 |publisher=Springer |doi=10.1007/978-3-540-45070-2_12 |isbn=978-3-540-45070-2 |citeseerx=10.1.1.1011.8}}</ref><ref>{{cite journal | first1=Stéphane | last1=Ducasse | first2=Oscar | last2=Nierstrasz | first3=Nathanael | last3=Schärli | first4=Roel | last4=Wuyts | first5=Andrew P. | last5=Black | title=Traits: A mechanism for fine-grained reuse. | journal= ACM Transactions on Programming Languages and Systems | volume=28 | issue=2 | pages=331–388 | date=March 2006 | doi=10.1145/1119479.1119483 |citeseerx=10.1.1.64.2480| s2cid=16434119 }}</ref>
 
==CharacteristicsRationale==
In object-oriented programming, we frequently encounter behavior shared by classes, even if those classes are not related to each other. For example, we may wish to beallow ablemany unrelated classes to [[Serialization|serialize]] themselves to [[JSON]] many unrelated classes for use in a [[Representational state transfer|REST API]]. Historically, there have been several approaches to solve this without duplicating the code in every class needing the behavior. Popular approaches have been [[multiple inheritance]] and [[mixin|mixins]], but the behavior of the code may unexpectedly change if you alter the order in which you inherit or "mix in" behavior. Behavior can also unexpectedly change if you add new methods to your parent classes or mixins. [[Delegation (computing)|Delegation]] is another approach, but if the object you're delegating to requires information from the class that contains the delegate, this can mean having to write additional code to handle this. Traits solve these problems by allowing classes to use the trait and get the desired behavior. If a class uses more than one trait, the order in which the traits are used does not matter and the methods provided by the traits have direct access to the data of the class.
 
[[Delegation (computing)|Delegation]] is another approach, but if the object you're delegating to requires information from the class that contains said object, this can mean having to write additional code to guarantee you send that data at the appropriate time, thus complicating the code.
 
Traits solve these problems by allowing classes to use the trait and get the desired behavior. If a class uses more than one trait, the order in which the traits are used does not matter and the methods provided by the traits have direct access to the data of the class.
 
==Characteristics==
Traits both provide a set of methods that implement behaviour to a class, and require that the class implement a set of methods that [[Parameter (computer programming)|parameterize]] the provided behaviour.