255:
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.
59:. 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.
254:
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.
166:
under the slogan "Once and Only Once". The definition of this principle was rather succinct in its first appearance: "no duplicate code". It has later been elaborated as applicable to other issues in software development: "Automate every process that's worth automating. If you find yourself
88:
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
198:
Inexperienced programmers may be tempted to introduce too much abstraction in their program—abstraction that won't be used more than once. A complementary principle that emphasizes this issue is
238:, where related code is by necessity duplicated to some extent across tiers, usually in different languages. In practical terms, the recommendation here is to rely on automated tools, like
66:" (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.
214:
code. 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
175:
The abstraction principle is often stated in the context of some mechanism intended to facilitate abstraction. The basic mechanism of control abstraction is a function or
195:
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.
154:
122:: " when applied to language design is to define all the semantically meaningful syntactic categories in the language and allow an abstraction over them".
222:. 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.
273:
283:
488:
114:
The abstraction principle is mentioned in several books. Some of these, together with the formulation if it is succinct, are listed below.
470:
450:
429:
408:
387:
353:
332:
308:
215:
141:
159:, a theme of many design patterns." This statement has been rephrased by other authors as "Find what varies and encapsulate it."
493:
192:
80:
52:
219:
145:
32:
200:
188:
231:
63:
235:
149:
239:
62:
When read as recommendations to the programmer, the abstraction principle can be generalized as the "
28:
243:
163:
17:
184:
75:
56:
466:
446:
425:
404:
383:
349:
328:
304:
279:
180:
129:: "Avoid requiring something to be stated more than once; factor out the recurring pattern".
48:
210:
Since code is usually subject to revisions, following the abstraction principle may entail
97:
As a requirement of the programming language, in its formulation by David A. Schmidt in
204:
47:
that aims to reduce duplication of information in a program (usually with emphasis on
482:
183:. More elaborate mechanisms that may combine data and control abstractions include:
211:
148:, although most writings on that topic do not give a name to the principle. The
176:
367:
Principles of programming languages: design, evaluation, and implementation
234:", or the "DRY principle", is a generalization developed in the context of
127:
Principles of programming languages: design, evaluation, and implementation
105:
The phrases of any semantically meaningful syntactic class may be named.
401:
Design patterns explained: a new perspective on object-oriented design
44:
84:(2002), the abstraction principle reads (emphasis in original):
74:
As a recommendation to the programmer, in its formulation by
162:
In this century, the principle has been reinvented in
136:: "Structure and function should be independent".
152:by the Gang of Four, states: "The focus here is
103:
86:
422:Extreme programming explained: embrace change
179:. Data abstractions include various forms of
8:
325:The structure of typed programming languages
99:The structure of typed programming languages
346:An introduction to programming with S-algol
120:An introduction to programming with S-algol
380:Programming and meta-programming in scheme
369:, Holt, Rinehart, and Winston, 1983, p. 53
167:performing a task many times, script it."
134:Programming and Meta-Programming in Scheme
101:(1994), the abstraction principle reads:.
118:Alfred John Cole, Ronald Morrison (1982)
55:provided by the programming language or
264:
140:The principle plays a central role in
51:) whenever practical by making use of
424:, 2nd edition, Addison-Wesley, 2000,
7:
344:Alfred John Cole, Ronald Morrison,
18:Abstraction principle (programming)
25:
443:Extreme programming pocket guide
301:Types and Programming Languages
250:Hardware programming interfaces
81:Types and Programming Languages
1:
399:Alan Shalloway, James Trott,
489:Programming language topics
278:. Pearson Education India.
203:" and, more generally, the
146:object-oriented programming
33:programming language theory
510:
303:. MIT Press. p. 339.
125:Bruce J. MacLennan (1983)
463:The Shellcoders Handbook"
299:Pierce, Benjamin (2002).
272:Mishra, Jibitesh (2011).
403:, Addison-Wesley, 2002,
236:multi-tier architectures
41:principle of abstraction
201:You Ain't Gonna Need It
157:the concept that varies
494:Programming principles
465:, Wiley, 2004, p. 10,
110:History and variations
107:
95:
348:, CUP Archive, 1982,
246:to avoid repetition.
232:Don't repeat yourself
218:, and popularized as
64:don't repeat yourself
37:abstraction principle
382:, Birkhäuser, 1998,
365:Bruce J. MacLennan,
275:Software Engineering
244:data transformations
150:Design Patterns book
29:software engineering
327:, MIT Press, 1994,
185:abstract data types
164:extreme programming
445:, O'Reilly, 2003,
323:David A. Schmidt,
132:Jon Pearce (1998)
93:the varying parts.
76:Benjamin C. Pierce
57:software libraries
285:978-81-317-5869-4
220:the rule of three
181:type polymorphism
16:(Redirected from
501:
473:
459:
453:
439:
433:
418:
412:
397:
391:
376:
370:
363:
357:
342:
336:
321:
315:
314:
296:
290:
289:
269:
49:code duplication
21:
509:
508:
504:
503:
502:
500:
499:
498:
479:
478:
477:
476:
460:
456:
440:
436:
419:
415:
398:
394:
377:
373:
364:
360:
343:
339:
322:
318:
311:
298:
297:
293:
286:
271:
270:
266:
261:
252:
240:code generators
228:
226:Generalizations
173:
142:design patterns
112:
91:abstracting out
72:
23:
22:
15:
12:
11:
5:
507:
505:
497:
496:
491:
481:
480:
475:
474:
454:
434:
413:
392:
371:
358:
337:
316:
309:
291:
284:
263:
262:
260:
257:
251:
248:
227:
224:
205:KISS principle
172:
169:
138:
137:
130:
123:
111:
108:
71:
68:
24:
14:
13:
10:
9:
6:
4:
3:
2:
506:
495:
492:
490:
487:
486:
484:
472:
471:0-7645-4468-3
468:
464:
458:
455:
452:
451:0-596-00485-0
448:
444:
438:
435:
431:
430:0-201-61641-6
427:
423:
417:
414:
410:
409:0-201-71594-5
406:
402:
396:
393:
389:
388:0-387-98320-1
385:
381:
375:
372:
368:
362:
359:
355:
354:0-521-25001-3
351:
347:
341:
338:
334:
333:0-262-19349-3
330:
326:
320:
317:
312:
310:0-262-16209-1
306:
302:
295:
292:
287:
281:
277:
276:
268:
265:
258:
256:
249:
247:
245:
241:
237:
233:
225:
223:
221:
217:
216:Martin Fowler
213:
208:
206:
202:
196:
194:
190:
186:
182:
178:
170:
168:
165:
160:
158:
156:
155:encapsulating
151:
147:
143:
135:
131:
128:
124:
121:
117:
116:
115:
109:
106:
102:
100:
94:
92:
85:
83:
82:
77:
70:The principle
69:
67:
65:
60:
58:
54:
50:
46:
43:) is a basic
42:
38:
34:
30:
19:
462:
457:
442:
437:
421:
416:
400:
395:
379:
378:Jon Pearce,
374:
366:
361:
345:
340:
324:
319:
300:
294:
274:
267:
253:
229:
209:
197:
187:, including
174:
171:Implications
161:
153:
139:
133:
126:
119:
113:
104:
98:
96:
90:
87:
79:
73:
61:
53:abstractions
40:
36:
26:
441:Chromatic,
420:Kent Beck,
212:refactoring
483:Categories
259:References
193:polytypism
177:subroutine
461:Koziol,
411:, p. 115
356:, p. 150
39:(or the
432:, p. 61
390:, p. 40
335:, p. 32
189:classes
469:
449:
428:
407:
386:
352:
331:
307:
282:
45:dictum
35:, the
467:ISBN
447:ISBN
426:ISBN
405:ISBN
384:ISBN
350:ISBN
329:ISBN
305:ISBN
280:ISBN
242:and
31:and
144:in
78:in
27:In
485::
207:.
191:,
313:.
288:.
230:"
199:"
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.