Abstraction principle (computer programming): Difference between revisions

Revision as of 15:22, 25 August 2009

Latest revision as of 21:28, 29 October 2023

(59 intermediate revisions by 29 users not shown)

Line 1:

In [[software engineering]] and [[programming language theory]], the '''abstraction principle''' (or the '''principle of abstraction''') is a basic [[dictum]] that aims to reduce duplication of information in a program (usually with emphasis on [[code duplication]]) whenever practical by making use of [[abstraction (computer science)|abstraction]]s provided by the programming language or [[software libraries]].<ref>{{Cite book |last=Mishra |first=Jibitesh |url=https://books.google.com/books?id=YnGz2ghKF-gC&q=%22principle+of+abstraction%22+%22software+engineering%22 |title=Software Engineering |date=2011 |publisher=Pearson Education India |isbn=978-81-317-5869-4 |language=en}}</ref> The principle is sometimes stated as a recommendation to the programmer, but sometimes stated as a requirement of the programming language, assuming it is self-understood why abstractions are desirable to use. The origins of the principle are uncertain; it has been reinvented a number of times, sometimes under a different name, with slight variations.

{{under construction}}

In [[software engineering]], the '''abstraction principle''' is a basic [[dictum]] that aims to reduce [[code duplication]] whenever practical. Its origins are uncertain; it has and reinvented a number of times, sometimes under a different name, with slight variations. A generalization of this principle is the "[[don't repeat yourself]]" principle, which recommends avoiding the duplication of information in general, and also avoiding the duplication of human effort involved in the software development process.

When read as recommendations to the programmer, the abstraction principle can be generalized as the "[[don't repeat yourself]]" (DRY) principle, which recommends avoiding the duplication of information in general, and also avoiding the duplication of human effort involved in the software development process.

== The principle ==

InAs a recommendation to the programmer, in its formulation by [[Benjamin C. Pierce]] in ''[[Types and Programming Languages]]'' (2002), the abstraction principle reads (emphasis in original):<ref>{{cite book|last=Pierce|first=Benjamin|title=Types and Programming Languages|publisher=MIT Press|year=2002|isbn=0-262-16209-1|page=339}}</ref>

{{cquote|Each significant piece of functionality in a program should be implemented in just one place in the source code. Where similar functions are carried out by distinct pieces of code, it is generally beneficial to combine them into one by ''abstracting out'' the varying parts.}}

As a requirement of the programming language, in its formulation by David A. Schmidt in ''The structure of typed programming languages'' (1994), the abstraction principle reads:.<ref>David A. Schmidt, ''The structure of typed programming languages'', MIT Press, 1994, {{ISBN|0-262-19349-3}}, p. 32</ref>

== History ==

{{cquote|The phrases of any semantically meaningful syntactic class may be named.}}

Under this very name, the abstraction principle appears into a long list of books. Here we give a necessarily incomplete list, together with the formulation:

== History and variations ==

The abstraction principle is mentioned in several books. Some of these, together with the formulation if it is succinct, are listed below.

* Alfred John Cole, Ronald Morrison (1982) ''An introduction to programming with S-algol'': "[Abstraction] when applied to language design is to define all the semantically meaningful syntactic categories in the language and allow an abstraction over them".<ref>Alfred John Cole, Ronald Morrison, ''An introduction to programming with S-algol'', CUP Archive, 1982, {{ISBN|0-521-25001-3}}, p. 150</ref>

* Bruce J. MacLennan (1983) ''Principles of programming languages: design, evaluation, and implementation'': "Avoid requiring something to be stated more than once; factor out the recurring pattern".<ref>Bruce J. MacLennan, ''Principles of programming languages: design, evaluation, and implementation'', Holt, Rinehart, and Winston, 1983, p. 53</ref>

* Jon Pearce (1998) ''Programming and Meta-Programming in Scheme'': "Structure and function should be independent".<ref>Jon Pearce, ''Programming and meta-programming in scheme'', Birkhäuser, 1998, {{ISBN 0387983201|0-387-98320-1}}, p. 40</ref>

* David A. Schmidt (1994) ''The structure of typed programming languages'': "The phrases of any semantically meaningful syntactic class may be named".<ref>David A. Schmidt, ''The structure of typed programming languages'', MIT Press, 1994, ISBN 0262193493, p. 32</ref> (This is referring to the facilities offered ''by'' the language ''to'' the programmer, hence "may".)

* Jon Pearce (1998) ''Programming and Meta-Programming in Scheme'': "Structure and function should be independent".<ref>Jon Pearce, ''Programming and meta-programming in scheme'', Birkhäuser, 1998, ISBN 0387983201, p. 40</ref>

The principle plays a central role in [[Design pattern (computer science)|design patterns]] in [[object-oriented programming]], although most writings on that topic do not give a name to the principle. The [[Design Patterns (book)|Design Patterns book]] by the Gang of Four, states: "The focus here is ''[[Encapsulation (object-oriented programming)|encapsulating]] the concept that varies'', a theme of many design patterns." This statement has been rephrased by other authors as "Find what varies and encapsulate it."<ref>Alan Shalloway, James Trott, ''Design patterns explained: a new perspective on object-oriented design'', Addison-Wesley, 2002, {{ISBN|0-201-71594-5}}, p. 115</ref><!-- these guys can't even phrase something this simple coherently; no wonder they have herd of cargo-cult programmers following them -->

More recently, the principle has been reinvented in [[extreme programming]] under the slogan "Once and Only Once". The definition of this principle was rather succinct in its first appearance: "no code duplication".<ref>Kent</ref>

In this century, the principle has been reinvented in [[extreme programming]] under the slogan "Once and Only Once". The definition of this principle was rather succinct in its first appearance: "no duplicate code".<ref>Kent Beck, ''Extreme programming explained: embrace change'', 2nd edition, Addison-Wesley, 2000, {{ISBN|0-201-61641-6}}, p. 61</ref> It has later been elaborated as applicable to other issues in software development: "Automate every process that's worth automating. If you find yourself performing a task many times, script it."<ref>Chromatic, ''Extreme programming pocket guide'', O'Reilly, 2003, {{ISBN|0-596-00485-0}}</ref>

== Implications ==

The abstraction principle is often stated in the context of some mechanism intended to facilitate abstraction. SuchThe basic mechanism of control abstraction is a function or [[subroutine]]. Data abstractions include various forms of [[type polymorphism]]. More elaborate mechanisms that may combine data and control abstractions include: [[abstract data type]]s, including [[typeClass polymorphism(computer science)|classes]], [[generic programmingPolymorphism_(computer_science)#Polytypism|polytypism]] etc. The quest for richer abstractions that allow less duplication in complex scenarios is one of the driving forces in programming language research and design.

Inexperienced programmers may be tempted to introduce too much abstraction in their program&mdash;abstraction that won't be used more than once. {{Citation needed|date=March 2013}} A complementary principle that emphasizes this issue is "[[You Ain't Gonna Need It]]" and, more generally, the [[KISS principle]].

Since code is usually subject to revisions, following the abstraction principle may entail [[refactoring]] code.{{Citation needed|date=August 2022}} The effort of rewriting a piece of code generically needs to be amortized against the estimated future benefits of an abstraction. A rule of thumb governing this was devised by [[Martin Fowler (software engineer)|Martin Fowler]], and popularized as [[Rule of three (programming)|the rule of three]]. It states that if a piece of code is copied more than twice, i.e. it would end up having three or more copies, then it needs to be abstracted out.

== Generalizations ==

"[[Don't repeat yourself]]", or the "DRY principle", is a generalization developed in the context of [[multi-tier architecture]]s, where related code is by necessity duplicated to some extent across tiers., Itusually isin intendeddifferent tolanguages. beIn obeyedpractical notterms, onlythe inrecommendation respecthere is to artifacts,rely suchon asautomated codetools, whichlike may[[Automatic needprogramming|code begenerators]] generatedand or[[data transformedtransformation]]s fromto aavoid singlerepetition.{{Citation masterNeeded|date=November source in this context.2018}}

== Hardware programming interfaces ==

In addition to optimizing code, a hierarchical/recursive meaning of Abstraction level in programming also refers to the interfaces between hardware communication layers, also called "abstraction levels" and "abstraction layers." In this case, level of abstraction often is synonymous with interface. For example, in examining shellcode and the interface between higher and lower level languages, the level of abstraction changes from operating system commands (for example, in C) to register and circuit level calls and commands (for example, in assembly and binary). In the case of that example, the boundary or interface between the abstraction levels is the stack.<ref>Koziol, ''The Shellcoders Handbook"'', Wiley, 2004, p. 10, {{ISBN|0-7645-4468-3}}</ref>

==References==

{{reflist}}

[[Category:Programming language topics]]

[[Category:Programming principles]]