![Page 1: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/1.jpg)
Better Functional Design Through Test-Driven
DevelopmentPhil Calçado - SoundCloud
@pcalcadohttp://philcalcado.com
Thursday, March 8, 12
![Page 2: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/2.jpg)
ohai!
i’m phil.
Thursday, March 8, 12
![Page 3: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/3.jpg)
i work here:
Thursday, March 8, 12
![Page 4: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/4.jpg)
Thursday, March 8, 12
![Page 5: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/5.jpg)
and so should you.
Thursday, March 8, 12
![Page 6: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/6.jpg)
http://bit.ly/work-at-soundcloud
Thursday, March 8, 12
![Page 7: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/7.jpg)
Better Functional Design Through Test-Driven
DevelopmentPhil Calçado - SoundCloud
@pcalcadohttp://philcalcado.com
Thursday, March 8, 12
![Page 8: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/8.jpg)
Better Functional Design Through Test-Driven
DevelopmentPhil Calçado - SoundCloud
@pcalcadohttp://philcalcado.com
better? what’s good functional design,
to begin with?
Thursday, March 8, 12
![Page 9: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/9.jpg)
I have no idea.
Thursday, March 8, 12
![Page 10: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/10.jpg)
how I got started with objects
Thursday, March 8, 12
![Page 11: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/11.jpg)
Thursday, March 8, 12
![Page 12: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/12.jpg)
Thursday, March 8, 12
![Page 13: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/13.jpg)
Thursday, March 8, 12
![Page 14: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/14.jpg)
Thursday, March 8, 12
![Page 15: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/15.jpg)
Thursday, March 8, 12
![Page 16: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/16.jpg)
Thursday, March 8, 12
![Page 17: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/17.jpg)
Thursday, March 8, 12
![Page 18: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/18.jpg)
Thursday, March 8, 12
![Page 19: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/19.jpg)
Thursday, March 8, 12
![Page 20: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/20.jpg)
Thursday, March 8, 12
![Page 21: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/21.jpg)
,Q�DQ\�FDVH��ZRUNLQJ�WKH�&217(;7�0$3�LQWR�GLVFXVVLRQV�LV�HVVHQWLDO�LI�WKH�QDPHV�DUH�WR�HQWHU�WKH8%,48,7286�/$1*8$*(��'RQW�VD\��ಯ*HRUJHV�WHDPV�VWXII�LV�FKDQJLQJ��VR�ZHUH�JRLQJ�WR�KDYHWR�FKDQJH�RXU�VWXII�WKDW�WDONV�WR�LW�ರ�6D\�LQVWHDG��ಯ7KH�7UDQVSRUW�1HWZRUN�PRGHO�LV�FKDQJLQJ��VR�ZHUHJRLQJ�WR�KDYH�WR�FKDQJH�WKH�WUDQVODWRU�IRU�WKH�%RRNLQJ�FRQWH[W�ರ
Relationships Between BOUNDED CONTEXTS7KH�IROORZLQJ�SDWWHUQV�FRYHU�D�UDQJH�RI�VWUDWHJLHV�IRU�UHODWLQJ�WZR�PRGHOV�WKDW�FDQ�EH�FRPSRVHG�WRHQFRPSDVV�DQ�HQWLUH�HQWHUSULVH��7KHVH�SDWWHUQV�VHUYH�WKH�GXDO�SXUSRVH�RI�SURYLGLQJ�WDUJHWV� IRUVXFFHVVIXOO\�RUJDQL]LQJ�GHYHORSPHQW�ZRUN��DQG�VXSSO\LQJ�YRFDEXODU\� IRU�GHVFULELQJ� WKH�H[LVWLQJRUJDQL]DWLRQ�$Q�H[LVWLQJ�UHODWLRQVKLS�PD\��E\�FKDQFH�RU�E\�GHVLJQ��IDOO�QHDU�RQH�RI�WKHVH�SDWWHUQV��LQ�ZKLFK�FDVH\RX�FDQ�GHVFULEH�LW�XVLQJ�WKDW�WHUP��YDULDWLRQV�GXO\�QRWHG��7KHQ��ZLWK�HDFK�VPDOO�GHVLJQ�FKDQJH��WKHUHODWLRQVKLS�FDQ�EH�GUDZQ�FORVHU�WR�WKH�FKRVHQ�SDWWHUQ�2Q�WKH�RWKHU�KDQG��\RX�PD\�ILQG�WKDW�DQ�H[LVWLQJ�UHODWLRQVKLS�LV�PXGGOHG�RU�RYHUFRPSOLFDWHG��6RPHUHRUJDQL]DWLRQ�PLJKW�EH�QHFHVVDU\�MXVW�WR�PDNH�DQ�XQDPELJXRXV�&217(;7�0$3�SRVVLEOH��,Q�WKLVVLWXDWLRQ��RU�DQ\�VLWXDWLRQ� LQ�ZKLFK�\RX�DUH�FRQVLGHULQJ�UHRUJDQL]DWLRQ�� WKHVH�SDWWHUQV�SUHVHQW�DUDQJH�RI�FKRLFHV�WKDW�DUH�IDYRUHG�LQ�GLIIHUHQW�FLUFXPVWDQFHV��3URPLQHQW�YDULDEOHV�LQFOXGH�WKH�OHYHORI�FRQWURO�\RX�KDYH�RYHU�WKH�RWKHU�PRGHO��WKH�OHYHO�DQG�W\SH�RI�FRRSHUDWLRQ�EHWZHHQ�WHDPV��DQG�WKHGHJUHH�RI�LQWHJUDWLRQ�RI�IHDWXUHV�DQG�GDWD�7KH�IROORZLQJ�VHW�RI�SDWWHUQV�FRYHUV�VRPH�RI�WKH�PRVW�FRPPRQ�DQG�LPSRUWDQW�FDVHV��ZKLFK�VKRXOGJLYH�\RX�D�JRRG�LGHD�RI�KRZ�WR�DSSURDFK�RWKHU�FDVHV��$�FUDFN�WHDP�ZRUNLQJ�FORVHO\�RQ�D�WLJKWO\LQWHJUDWHG�SURGXFW�FDQ�GHSOR\�D�ODUJH�XQLILHG�PRGHO��7KH�QHHG�WR�VHUYH�GLIIHUHQW�XVHU�FRPPXQLWLHVRU�D�OLPLWDWLRQ�RQ�WKH�FRRUGLQDWLRQ�DELOLWLHV�RI�WKH�WHDP�PLJKW�OHDG�WR�D�6+$5('�.(51(/�RU�&86�720(5�6833/,(5�UHODWLRQVKLSV��6RPHWLPHV�D�JRRG�KDUG�ORRN�DW�WKH�UHTXLUHPHQWV�UHYHDOV�WKDWLQWHJUDWLRQ�LV�QRW�HVVHQWLDO�DQG�LW�LV�EHVW�IRU�V\VWHPV�WR�JR�WKHLU�6(3$5$7(�:$<6��$QG��RI�FRXUVH�PRVW�SURMHFWV�KDYH�WR�LQWHJUDWH�WR�VRPH�GHJUHH�ZLWK�OHJDF\�DQG�H[WHUQDO�V\VWHPV��ZKLFK�FDQ�OHDGWR�23(1�+267�6(59,&(6�RU�$17,&255837,21�/$<(56�
Shared Kernel
0DLQWDLQLQJ�0RGHO�,QWHJULW\ ���
'RPDLQ�'ULYHQ�'HVLJQ��7DFNOLQJ�&RPSOH[LW\�LQ�WKH�+HDUW�RI�6RIWZDUH��'RPDLQ�'ULYHQ�'HVLJQ��7DFNOLQJ�&RPSOH[LW\�LQ�WKH�+HDUW�RI�6RIWZDUH��,6%1���������������3UHSDUHG�IRU�SFDOFDGR#JPDLO�FRP��3KLOOLS�&DOoDGR&RS\ULJKW��������E\�(ULF�(YDQV��7KLV�3')�LV�PDGH�DYDLODEOH�IRU�SHUVRQDO�XVH�RQO\�GXULQJ�WKH�UHOHYDQW�VXEVFULSWLRQ�WHUP��VXEMHFW�WR�WKH�6DIDUL�7HUPV�RI�6HUYLFH��$Q\�RWKHU�XVH�UHTXLUHV�SULRUZULWWHQ�FRQVHQW�IURP�WKH�FRS\ULJKW�RZQHU��8QDXWKRUL]HG�XVH��UHSURGXFWLRQ�DQG�RU�GLVWULEXWLRQ�DUH�VWULFWO\�SURKLELWHG�DQG�YLRODWH�DSSOLFDEOH�ODZV��$OO�ULJKWV�UHVHUYHG�
Thursday, March 8, 12
![Page 22: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/22.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given
that copying
is by perm
ission of
the Association
for Com
puting Machinery.
To copy
othcrwisc, or
to republish.
requires B fee
and/or specific
pornlission. HOPL-11/4/93/M
A,USA o 1993
ACM 0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Thursday, March 8, 12
![Page 23: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/23.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given
that copying
is by perm
ission of
the Association
for Com
puting Machinery.
To copy
othcrwisc, or
to republish.
requires B fee
and/or specific
pornlission. HOPL-11/4/93/M
A,USA o 1993
ACM 0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Programming R. Morr is Techniques Edi tor
On the Criteria To Be Used in Decomposing Systems into Modules D.L. Parnas Carnegie-Mellon University
This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom- positions are discussed. The unconventional decomposi- tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
Key Words and Phrases: software, modules, modularity, software engineering, KWIC index, software design
CR Categories: 4.0
Introduction
A lucid s tatement o f the phi losophy of modula r p rogramming can be found in a 1970 tex tbook on the design of system programs by Gouth ie r and Pon t [1, ¶I0.23], which we quote below: 1
A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the in- tegrity of the module is tested independently; there are few sche- duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching.
Usual ly nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means o f examples, suggest some criteria which can be used in decompos ing a system into modules.
Copyright @ 1972, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part
of this material is granted, provided that reference is made to this publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Com- puting Machinery.
Author's address: Department of Computer Science, Carnegie- Mellon University, Pittsburgh, PA 15213.
1053
A Brief Status Report
The ma jo r advancement in the area o f modula r p rogramming has been the development o f coding techniques and assemblers which (l) allow one module to be written with little knowledge o f the code in another module, and (2) allow modules to be reas- sembled and replaced wi thout reassembly o f the whole system. This facility is extremely valuable for the product ion o f large pieces o f code, but the systems mos t often used as examples o f problem systems are highly- modular ized programs and make use o f the techniques ment ioned above.
1 Reprinted by permission of Prentice-Hall, Englewood Cliffs, N.J.
Communications December 1972 of Volume 15 the ACM Number 12
Thursday, March 8, 12
![Page 24: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/24.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given
that copying
is by perm
ission of
the Association
for Com
puting Machinery.
To copy
othcrwisc, or
to republish.
requires B fee
and/or specific
pornlission. HOPL-11/4/93/M
A,USA o 1993
ACM 0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Programming R. Morr is Techniques Edi tor
On the Criteria To Be Used in Decomposing Systems into Modules D.L. Parnas Carnegie-Mellon University
This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom- positions are discussed. The unconventional decomposi- tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
Key Words and Phrases: software, modules, modularity, software engineering, KWIC index, software design
CR Categories: 4.0
Introduction
A lucid s tatement o f the phi losophy of modula r p rogramming can be found in a 1970 tex tbook on the design of system programs by Gouth ie r and Pon t [1, ¶I0.23], which we quote below: 1
A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the in- tegrity of the module is tested independently; there are few sche- duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching.
Usual ly nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means o f examples, suggest some criteria which can be used in decompos ing a system into modules.
Copyright @ 1972, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part
of this material is granted, provided that reference is made to this publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Com- puting Machinery.
Author's address: Department of Computer Science, Carnegie- Mellon University, Pittsburgh, PA 15213.
1053
A Brief Status Report
The ma jo r advancement in the area o f modula r p rogramming has been the development o f coding techniques and assemblers which (l) allow one module to be written with little knowledge o f the code in another module, and (2) allow modules to be reas- sembled and replaced wi thout reassembly o f the whole system. This facility is extremely valuable for the product ion o f large pieces o f code, but the systems mos t often used as examples o f problem systems are highly- modular ized programs and make use o f the techniques ment ioned above.
1 Reprinted by permission of Prentice-Hall, Englewood Cliffs, N.J.
Communications December 1972 of Volume 15 the ACM Number 12
CRC Handbook of Computer Science and Engineering, 2nd Edition, Ch. 97, Wednesday, February 25, 2004, 8:00 pm. © CRC Press. 1
1 IntroductionThe fundamental purpose of a type system is to prevent the occurrence of execution errors dur-ing the running of a program. This informal statement motivates the study of type systems, butrequires clarification. Its accuracy depends, first of all, on the rather subtle issue of what consti-tutes an execution error, which we will discuss in detail. Even when that is settled, the absenceof execution errors is a nontrivial property. When such a property holds for all of the programruns that can be expressed within a programming language, we say that the language is typesound. It turns out that a fair amount of careful analysis is required to avoid false and embar-rassing claims of type soundness for programming languages. As a consequence, the classifica-tion, description, and study of type systems has emerged as a formal discipline.
The formalization of type systems requires the development of precise notations and defi-nitions, and the detailed proof of formal properties that give confidence in the appropriatenessof the definitions. Sometimes the discipline becomes rather abstract. One should always remem-ber, though, that the basic motivation is pragmatic: the abstractions have arisen out of necessityand can usually be related directly to concrete intuitions. Moreover, formal techniques need notbe applied in full in order to be useful and influential. A knowledge of the main principles oftype systems can help in avoiding obvious and not so obvious pitfalls, and can inspire regularityand orthogonality in language design.
When properly developed, type systems provide conceptual tools with which to judge theadequacy of important aspects of language definitions. Informal language descriptions often failto specify the type structure of a language in sufficient detail to allow unambiguous implemen-tation. It often happens that different compilers for the same language implement slightly dif-ferent type systems. Moreover, many language definitions have been found to be type unsound,allowing a program to crash even though it is judged acceptable by a typechecker. Ideally, for-mal type systems should be part of the definition of all typed programming languages. This way,typechecking algorithms could be measured unambiguously against precise specifications and,if at all possible and feasible, whole languages could be shown to be type sound.
In this introductory section we present an informal nomenclature for typing, execution er-rors, and related concepts. We discuss the expected properties and benefits of type systems, andwe review how type systems can be formalized. The terminology used in the introduction is notcompletely standard; this is due to the inherent inconsistency of standard terminology arisingfrom various sources. In general, we avoid the words type and typing when referring to run timeconcepts; for example we replace dynamic typing with dynamic checking and avoid commonbut ambiguous terms such as strong typing. The terminology is summarized in the DefiningTerms section.
Type Systems
Luca Cardelli
Microsoft Research
Thursday, March 8, 12
![Page 25: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/25.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given
that copying
is by perm
ission of
the Association
for Com
puting Machinery.
To copy
othcrwisc, or
to republish.
requires B fee
and/or specific
pornlission. HOPL-11/4/93/M
A,USA o 1993
ACM 0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Programming R. Morr is Techniques Edi tor
On the Criteria To Be Used in Decomposing Systems into Modules D.L. Parnas Carnegie-Mellon University
This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom- positions are discussed. The unconventional decomposi- tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
Key Words and Phrases: software, modules, modularity, software engineering, KWIC index, software design
CR Categories: 4.0
Introduction
A lucid s tatement o f the phi losophy of modula r p rogramming can be found in a 1970 tex tbook on the design of system programs by Gouth ie r and Pon t [1, ¶I0.23], which we quote below: 1
A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the in- tegrity of the module is tested independently; there are few sche- duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching.
Usual ly nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means o f examples, suggest some criteria which can be used in decompos ing a system into modules.
Copyright @ 1972, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part
of this material is granted, provided that reference is made to this publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Com- puting Machinery.
Author's address: Department of Computer Science, Carnegie- Mellon University, Pittsburgh, PA 15213.
1053
A Brief Status Report
The ma jo r advancement in the area o f modula r p rogramming has been the development o f coding techniques and assemblers which (l) allow one module to be written with little knowledge o f the code in another module, and (2) allow modules to be reas- sembled and replaced wi thout reassembly o f the whole system. This facility is extremely valuable for the product ion o f large pieces o f code, but the systems mos t often used as examples o f problem systems are highly- modular ized programs and make use o f the techniques ment ioned above.
1 Reprinted by permission of Prentice-Hall, Englewood Cliffs, N.J.
Communications December 1972 of Volume 15 the ACM Number 12
CRC Handbook of Computer Science and Engineering, 2nd Edition, Ch. 97, Wednesday, February 25, 2004, 8:00 pm. © CRC Press. 1
1 IntroductionThe fundamental purpose of a type system is to prevent the occurrence of execution errors dur-ing the running of a program. This informal statement motivates the study of type systems, butrequires clarification. Its accuracy depends, first of all, on the rather subtle issue of what consti-tutes an execution error, which we will discuss in detail. Even when that is settled, the absenceof execution errors is a nontrivial property. When such a property holds for all of the programruns that can be expressed within a programming language, we say that the language is typesound. It turns out that a fair amount of careful analysis is required to avoid false and embar-rassing claims of type soundness for programming languages. As a consequence, the classifica-tion, description, and study of type systems has emerged as a formal discipline.
The formalization of type systems requires the development of precise notations and defi-nitions, and the detailed proof of formal properties that give confidence in the appropriatenessof the definitions. Sometimes the discipline becomes rather abstract. One should always remem-ber, though, that the basic motivation is pragmatic: the abstractions have arisen out of necessityand can usually be related directly to concrete intuitions. Moreover, formal techniques need notbe applied in full in order to be useful and influential. A knowledge of the main principles oftype systems can help in avoiding obvious and not so obvious pitfalls, and can inspire regularityand orthogonality in language design.
When properly developed, type systems provide conceptual tools with which to judge theadequacy of important aspects of language definitions. Informal language descriptions often failto specify the type structure of a language in sufficient detail to allow unambiguous implemen-tation. It often happens that different compilers for the same language implement slightly dif-ferent type systems. Moreover, many language definitions have been found to be type unsound,allowing a program to crash even though it is judged acceptable by a typechecker. Ideally, for-mal type systems should be part of the definition of all typed programming languages. This way,typechecking algorithms could be measured unambiguously against precise specifications and,if at all possible and feasible, whole languages could be shown to be type sound.
In this introductory section we present an informal nomenclature for typing, execution er-rors, and related concepts. We discuss the expected properties and benefits of type systems, andwe review how type systems can be formalized. The terminology used in the introduction is notcompletely standard; this is due to the inherent inconsistency of standard terminology arisingfrom various sources. In general, we avoid the words type and typing when referring to run timeconcepts; for example we replace dynamic typing with dynamic checking and avoid commonbut ambiguous terms such as strong typing. The terminology is summarized in the DefiningTerms section.
Type Systems
Luca Cardelli
Microsoft Research
Thursday, March 8, 12
![Page 26: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/26.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given
that copying
is by perm
ission of
the Association
for Com
puting Machinery.
To copy
othcrwisc, or
to republish.
requires B fee
and/or specific
pornlission. HOPL-11/4/93/M
A,USA o 1993
ACM 0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Programming R. Morr is Techniques Edi tor
On the Criteria To Be Used in Decomposing Systems into Modules D.L. Parnas Carnegie-Mellon University
This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom- positions are discussed. The unconventional decomposi- tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
Key Words and Phrases: software, modules, modularity, software engineering, KWIC index, software design
CR Categories: 4.0
Introduction
A lucid s tatement o f the phi losophy of modula r p rogramming can be found in a 1970 tex tbook on the design of system programs by Gouth ie r and Pon t [1, ¶I0.23], which we quote below: 1
A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the in- tegrity of the module is tested independently; there are few sche- duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching.
Usual ly nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means o f examples, suggest some criteria which can be used in decompos ing a system into modules.
Copyright @ 1972, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part
of this material is granted, provided that reference is made to this publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Com- puting Machinery.
Author's address: Department of Computer Science, Carnegie- Mellon University, Pittsburgh, PA 15213.
1053
A Brief Status Report
The ma jo r advancement in the area o f modula r p rogramming has been the development o f coding techniques and assemblers which (l) allow one module to be written with little knowledge o f the code in another module, and (2) allow modules to be reas- sembled and replaced wi thout reassembly o f the whole system. This facility is extremely valuable for the product ion o f large pieces o f code, but the systems mos t often used as examples o f problem systems are highly- modular ized programs and make use o f the techniques ment ioned above.
1 Reprinted by permission of Prentice-Hall, Englewood Cliffs, N.J.
Communications December 1972 of Volume 15 the ACM Number 12
CRC Handbook of Computer Science and Engineering, 2nd Edition, Ch. 97, Wednesday, February 25, 2004, 8:00 pm. © CRC Press. 1
1 IntroductionThe fundamental purpose of a type system is to prevent the occurrence of execution errors dur-ing the running of a program. This informal statement motivates the study of type systems, butrequires clarification. Its accuracy depends, first of all, on the rather subtle issue of what consti-tutes an execution error, which we will discuss in detail. Even when that is settled, the absenceof execution errors is a nontrivial property. When such a property holds for all of the programruns that can be expressed within a programming language, we say that the language is typesound. It turns out that a fair amount of careful analysis is required to avoid false and embar-rassing claims of type soundness for programming languages. As a consequence, the classifica-tion, description, and study of type systems has emerged as a formal discipline.
The formalization of type systems requires the development of precise notations and defi-nitions, and the detailed proof of formal properties that give confidence in the appropriatenessof the definitions. Sometimes the discipline becomes rather abstract. One should always remem-ber, though, that the basic motivation is pragmatic: the abstractions have arisen out of necessityand can usually be related directly to concrete intuitions. Moreover, formal techniques need notbe applied in full in order to be useful and influential. A knowledge of the main principles oftype systems can help in avoiding obvious and not so obvious pitfalls, and can inspire regularityand orthogonality in language design.
When properly developed, type systems provide conceptual tools with which to judge theadequacy of important aspects of language definitions. Informal language descriptions often failto specify the type structure of a language in sufficient detail to allow unambiguous implemen-tation. It often happens that different compilers for the same language implement slightly dif-ferent type systems. Moreover, many language definitions have been found to be type unsound,allowing a program to crash even though it is judged acceptable by a typechecker. Ideally, for-mal type systems should be part of the definition of all typed programming languages. This way,typechecking algorithms could be measured unambiguously against precise specifications and,if at all possible and feasible, whole languages could be shown to be type sound.
In this introductory section we present an informal nomenclature for typing, execution er-rors, and related concepts. We discuss the expected properties and benefits of type systems, andwe review how type systems can be formalized. The terminology used in the introduction is notcompletely standard; this is due to the inherent inconsistency of standard terminology arisingfrom various sources. In general, we avoid the words type and typing when referring to run timeconcepts; for example we replace dynamic typing with dynamic checking and avoid commonbut ambiguous terms such as strong typing. The terminology is summarized in the DefiningTerms section.
Type Systems
Luca Cardelli
Microsoft Research
CRC Handbook of Computer Science and Engineering, 2nd Edition, Ch. 97, Wednesday, February 25, 2004, 8:00 pm. © CRC Press. 15
Table 5. A derivation in F1
Now that we have examined the basic structure of a simple first-order type system, we canbegin enriching it to bring it closer to the type structure of actual programming languages. Weare going to add a set of rules for each new type construction, following a fairly regular pattern.We begin with some basic data types: the type Unit, whose only value is the constant unit; thetype Bool, whose values are true and false; and the type Nat, whose values are the natural num-bers.
The Unit type is often used as a filler for uninteresting arguments and results; it is calledVoid or Null in some languages. There are no operations on Unit, so we need only a rule statingthat Unit is a legal type, and one stating that unit is a legal value of type Unit (Table 6).
Table 6. Unit Type
We have a similar pattern of rules for Bool, but booleans also have a useful operation, theconditional, that has its own typing rule (Table 7). In the rule (Val Cond) the two branches ofthe conditional must have the same type A, because either may produce the result.
The rule (Val Cond) illustrates a subtle issue about the amount of type information neededfor typechecking. When encountering a conditional expression, a typechecker has to infer sep-arately the types of N1 and N2, and then find a single type A that is compatible with both. In sometype systems it might not be easy or possible to determine this single type from the types of N1
and N2. To account for this potential typechecking difficulty, we use a subscripted type to ex-press additional type information: ifA is a hint to the typechecker that the result type should beA, and that types inferred for N1 and N2 should be separately compared with the given A. In gen-eral, we use subscripted types to indicate information that may be useful or necessary fortypechecking, depending on the whole type system under consideration. It is often the task of atypechecker to synthesize this additional information. When it is possible to do so, subscriptsmay be omitted. (Most common languages do not require the annotation ifA.)
by (Env ) by (Env ) by (Env ) by (Env )
K by (Type Const) K by (Type Const) K by (Type Const) K by (Type Const)
K!K by (Type Arrow) K!K by (Type Arrow)
, y:K!K by (Env x) , y:K!K by (Env x)
, y:K!K K by (Type Const) , y:K!K K by (Type Const)
, y:K!K, z:K by (Env x) , y:K!K, z:K by (Env x)
, y:K!K, z:K y : K!K by (Val x) , y:K!K, z:K z : K by (Val x)
, y:K!K, z:K y(z) : K by (Val Appl)
, y:K!K "z:K.y(z) : K!K by (Val Fun)
(Type Unit) (Val Unit)# #
# Unit # unit : Unit
Thursday, March 8, 12
![Page 27: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/27.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given that
copying is by
permission
of the
Association for
Computing
Machinery. To
copy othcrwisc,
or to
republish. requires
B fee and/or
specific pornlission.
HOPL-11/4/93/MA,USA
o 1993 ACM
0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Thursday, March 8, 12
![Page 28: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/28.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given that
copying is by
permission
of the
Association for
Computing
Machinery. To
copy othcrwisc,
or to
republish. requires
B fee and/or
specific pornlission.
HOPL-11/4/93/MA,USA
o 1993 ACM
0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
hobby
Thursday, March 8, 12
![Page 29: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/29.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given that
copying is by
permission
of the
Association for
Computing
Machinery. To
copy othcrwisc,
or to
republish. requires
B fee and/or
specific pornlission.
HOPL-11/4/93/MA,USA
o 1993 ACM
0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Thursday, March 8, 12
![Page 30: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/30.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given that
copying is by
permission
of the
Association for
Computing
Machinery. To
copy othcrwisc,
or to
republish. requires
B fee and/or
specific pornlission.
HOPL-11/4/93/MA,USA
o 1993 ACM
0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
startmakingmoney
Thursday, March 8, 12
![Page 31: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/31.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given that
copying is by
permission
of the
Association for
Computing
Machinery. To
copy othcrwisc,
or to
republish. requires
B fee and/or
specific pornlission.
HOPL-11/4/93/MA,USA
o 1993 ACM
0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Thursday, March 8, 12
![Page 32: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/32.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given that
copying is by
permission
of the
Association for
Computing
Machinery. To
copy othcrwisc,
or to
republish. requires
B fee and/or
specific pornlission.
HOPL-11/4/93/MA,USA
o 1993 ACM
0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
startsucking
less
Thursday, March 8, 12
![Page 33: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/33.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given that
copying is by
permission
of the
Association for
Computing
Machinery. To
copy othcrwisc,
or to
republish. requires
B fee and/or
specific pornlission.
HOPL-11/4/93/MA,USA
o 1993 ACM
0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Thursday, March 8, 12
![Page 34: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/34.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given that
copying is by
permission
of the
Association for
Computing
Machinery. To
copy othcrwisc,
or to
republish. requires
B fee and/or
specific pornlission.
HOPL-11/4/93/MA,USA
o 1993 ACM
0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
startconsulting
Thursday, March 8, 12
![Page 35: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/35.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given that
copying is by
permission
of the
Association for
Computing
Machinery. To
copy othcrwisc,
or to
republish. requires
B fee and/or
specific pornlission.
HOPL-11/4/93/MA,USA
o 1993 ACM
0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Thursday, March 8, 12
![Page 36: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/36.jpg)
how I got started with functions
Thursday, March 8, 12
![Page 37: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/37.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given
that copying
is by perm
ission of
the Association
for Com
puting Machinery.
To copy
othcrwisc, or
to republish.
requires B fee
and/or specific
pornlission. HOPL-11/4/93/M
A,USA o 1993
ACM 0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Programming R. Morr is Techniques Edi tor
On the Criteria To Be Used in Decomposing Systems into Modules D.L. Parnas Carnegie-Mellon University
This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom- positions are discussed. The unconventional decomposi- tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
Key Words and Phrases: software, modules, modularity, software engineering, KWIC index, software design
CR Categories: 4.0
Introduction
A lucid s tatement o f the phi losophy of modula r p rogramming can be found in a 1970 tex tbook on the design of system programs by Gouth ie r and Pon t [1, ¶I0.23], which we quote below: 1
A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the in- tegrity of the module is tested independently; there are few sche- duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching.
Usual ly nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means o f examples, suggest some criteria which can be used in decompos ing a system into modules.
Copyright @ 1972, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part
of this material is granted, provided that reference is made to this publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Com- puting Machinery.
Author's address: Department of Computer Science, Carnegie- Mellon University, Pittsburgh, PA 15213.
1053
A Brief Status Report
The ma jo r advancement in the area o f modula r p rogramming has been the development o f coding techniques and assemblers which (l) allow one module to be written with little knowledge o f the code in another module, and (2) allow modules to be reas- sembled and replaced wi thout reassembly o f the whole system. This facility is extremely valuable for the product ion o f large pieces o f code, but the systems mos t often used as examples o f problem systems are highly- modular ized programs and make use o f the techniques ment ioned above.
1 Reprinted by permission of Prentice-Hall, Englewood Cliffs, N.J.
Communications December 1972 of Volume 15 the ACM Number 12
CRC Handbook of Computer Science and Engineering, 2nd Edition, Ch. 97, Wednesday, February 25, 2004, 8:00 pm. © CRC Press. 1
1 IntroductionThe fundamental purpose of a type system is to prevent the occurrence of execution errors dur-ing the running of a program. This informal statement motivates the study of type systems, butrequires clarification. Its accuracy depends, first of all, on the rather subtle issue of what consti-tutes an execution error, which we will discuss in detail. Even when that is settled, the absenceof execution errors is a nontrivial property. When such a property holds for all of the programruns that can be expressed within a programming language, we say that the language is typesound. It turns out that a fair amount of careful analysis is required to avoid false and embar-rassing claims of type soundness for programming languages. As a consequence, the classifica-tion, description, and study of type systems has emerged as a formal discipline.
The formalization of type systems requires the development of precise notations and defi-nitions, and the detailed proof of formal properties that give confidence in the appropriatenessof the definitions. Sometimes the discipline becomes rather abstract. One should always remem-ber, though, that the basic motivation is pragmatic: the abstractions have arisen out of necessityand can usually be related directly to concrete intuitions. Moreover, formal techniques need notbe applied in full in order to be useful and influential. A knowledge of the main principles oftype systems can help in avoiding obvious and not so obvious pitfalls, and can inspire regularityand orthogonality in language design.
When properly developed, type systems provide conceptual tools with which to judge theadequacy of important aspects of language definitions. Informal language descriptions often failto specify the type structure of a language in sufficient detail to allow unambiguous implemen-tation. It often happens that different compilers for the same language implement slightly dif-ferent type systems. Moreover, many language definitions have been found to be type unsound,allowing a program to crash even though it is judged acceptable by a typechecker. Ideally, for-mal type systems should be part of the definition of all typed programming languages. This way,typechecking algorithms could be measured unambiguously against precise specifications and,if at all possible and feasible, whole languages could be shown to be type sound.
In this introductory section we present an informal nomenclature for typing, execution er-rors, and related concepts. We discuss the expected properties and benefits of type systems, andwe review how type systems can be formalized. The terminology used in the introduction is notcompletely standard; this is due to the inherent inconsistency of standard terminology arisingfrom various sources. In general, we avoid the words type and typing when referring to run timeconcepts; for example we replace dynamic typing with dynamic checking and avoid commonbut ambiguous terms such as strong typing. The terminology is summarized in the DefiningTerms section.
Type Systems
Luca Cardelli
Microsoft Research
Thursday, March 8, 12
![Page 38: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/38.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given
that copying
is by perm
ission of
the Association
for Com
puting Machinery.
To copy
othcrwisc, or
to republish.
requires B fee
and/or specific
pornlission. HOPL-11/4/93/M
A,USA o 1993
ACM 0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Programming R. Morr is Techniques Edi tor
On the Criteria To Be Used in Decomposing Systems into Modules D.L. Parnas Carnegie-Mellon University
This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom- positions are discussed. The unconventional decomposi- tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
Key Words and Phrases: software, modules, modularity, software engineering, KWIC index, software design
CR Categories: 4.0
Introduction
A lucid s tatement o f the phi losophy of modula r p rogramming can be found in a 1970 tex tbook on the design of system programs by Gouth ie r and Pon t [1, ¶I0.23], which we quote below: 1
A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the in- tegrity of the module is tested independently; there are few sche- duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching.
Usual ly nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means o f examples, suggest some criteria which can be used in decompos ing a system into modules.
Copyright @ 1972, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part
of this material is granted, provided that reference is made to this publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Com- puting Machinery.
Author's address: Department of Computer Science, Carnegie- Mellon University, Pittsburgh, PA 15213.
1053
A Brief Status Report
The ma jo r advancement in the area o f modula r p rogramming has been the development o f coding techniques and assemblers which (l) allow one module to be written with little knowledge o f the code in another module, and (2) allow modules to be reas- sembled and replaced wi thout reassembly o f the whole system. This facility is extremely valuable for the product ion o f large pieces o f code, but the systems mos t often used as examples o f problem systems are highly- modular ized programs and make use o f the techniques ment ioned above.
1 Reprinted by permission of Prentice-Hall, Englewood Cliffs, N.J.
Communications December 1972 of Volume 15 the ACM Number 12
CRC Handbook of Computer Science and Engineering, 2nd Edition, Ch. 97, Wednesday, February 25, 2004, 8:00 pm. © CRC Press. 1
1 IntroductionThe fundamental purpose of a type system is to prevent the occurrence of execution errors dur-ing the running of a program. This informal statement motivates the study of type systems, butrequires clarification. Its accuracy depends, first of all, on the rather subtle issue of what consti-tutes an execution error, which we will discuss in detail. Even when that is settled, the absenceof execution errors is a nontrivial property. When such a property holds for all of the programruns that can be expressed within a programming language, we say that the language is typesound. It turns out that a fair amount of careful analysis is required to avoid false and embar-rassing claims of type soundness for programming languages. As a consequence, the classifica-tion, description, and study of type systems has emerged as a formal discipline.
The formalization of type systems requires the development of precise notations and defi-nitions, and the detailed proof of formal properties that give confidence in the appropriatenessof the definitions. Sometimes the discipline becomes rather abstract. One should always remem-ber, though, that the basic motivation is pragmatic: the abstractions have arisen out of necessityand can usually be related directly to concrete intuitions. Moreover, formal techniques need notbe applied in full in order to be useful and influential. A knowledge of the main principles oftype systems can help in avoiding obvious and not so obvious pitfalls, and can inspire regularityand orthogonality in language design.
When properly developed, type systems provide conceptual tools with which to judge theadequacy of important aspects of language definitions. Informal language descriptions often failto specify the type structure of a language in sufficient detail to allow unambiguous implemen-tation. It often happens that different compilers for the same language implement slightly dif-ferent type systems. Moreover, many language definitions have been found to be type unsound,allowing a program to crash even though it is judged acceptable by a typechecker. Ideally, for-mal type systems should be part of the definition of all typed programming languages. This way,typechecking algorithms could be measured unambiguously against precise specifications and,if at all possible and feasible, whole languages could be shown to be type sound.
In this introductory section we present an informal nomenclature for typing, execution er-rors, and related concepts. We discuss the expected properties and benefits of type systems, andwe review how type systems can be formalized. The terminology used in the introduction is notcompletely standard; this is due to the inherent inconsistency of standard terminology arisingfrom various sources. In general, we avoid the words type and typing when referring to run timeconcepts; for example we replace dynamic typing with dynamic checking and avoid commonbut ambiguous terms such as strong typing. The terminology is summarized in the DefiningTerms section.
Type Systems
Luca Cardelli
Microsoft Research
Thursday, March 8, 12
![Page 39: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/39.jpg)
Gzs%
ef . .
. . . . .
, .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. ,
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Permission
to copy
without fee
all or
part of
this materinl
is granted
prowded that
the topics
are not
mada or distributed
for direct
comm
crciol advantage,
the ACM
copyright notice
ond tho
lillc of
the publication
and its
dare appear.
and notice
is given
that copying
is by perm
ission of
the Association
for Com
puting Machinery.
To copy
othcrwisc, or
to republish.
requires B fee
and/or specific
pornlission. HOPL-11/4/93/M
A,USA o 1993
ACM 0-89791.571.2/93/0004/0069...$1.50
:LJ 2 2
.x E
.m
8 al
:5 a
.6
69 ACM
SIGPLAN Notices, Volum
e 28, No. 3 M
arch 1993
Programming R. Morr is Techniques Edi tor
On the Criteria To Be Used in Decomposing Systems into Modules D.L. Parnas Carnegie-Mellon University
This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom- positions are discussed. The unconventional decomposi- tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
Key Words and Phrases: software, modules, modularity, software engineering, KWIC index, software design
CR Categories: 4.0
Introduction
A lucid s tatement o f the phi losophy of modula r p rogramming can be found in a 1970 tex tbook on the design of system programs by Gouth ie r and Pon t [1, ¶I0.23], which we quote below: 1
A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the in- tegrity of the module is tested independently; there are few sche- duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching.
Usual ly nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means o f examples, suggest some criteria which can be used in decompos ing a system into modules.
Copyright @ 1972, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part
of this material is granted, provided that reference is made to this publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Com- puting Machinery.
Author's address: Department of Computer Science, Carnegie- Mellon University, Pittsburgh, PA 15213.
1053
A Brief Status Report
The ma jo r advancement in the area o f modula r p rogramming has been the development o f coding techniques and assemblers which (l) allow one module to be written with little knowledge o f the code in another module, and (2) allow modules to be reas- sembled and replaced wi thout reassembly o f the whole system. This facility is extremely valuable for the product ion o f large pieces o f code, but the systems mos t often used as examples o f problem systems are highly- modular ized programs and make use o f the techniques ment ioned above.
1 Reprinted by permission of Prentice-Hall, Englewood Cliffs, N.J.
Communications December 1972 of Volume 15 the ACM Number 12
CRC Handbook of Computer Science and Engineering, 2nd Edition, Ch. 97, Wednesday, February 25, 2004, 8:00 pm. © CRC Press. 1
1 IntroductionThe fundamental purpose of a type system is to prevent the occurrence of execution errors dur-ing the running of a program. This informal statement motivates the study of type systems, butrequires clarification. Its accuracy depends, first of all, on the rather subtle issue of what consti-tutes an execution error, which we will discuss in detail. Even when that is settled, the absenceof execution errors is a nontrivial property. When such a property holds for all of the programruns that can be expressed within a programming language, we say that the language is typesound. It turns out that a fair amount of careful analysis is required to avoid false and embar-rassing claims of type soundness for programming languages. As a consequence, the classifica-tion, description, and study of type systems has emerged as a formal discipline.
The formalization of type systems requires the development of precise notations and defi-nitions, and the detailed proof of formal properties that give confidence in the appropriatenessof the definitions. Sometimes the discipline becomes rather abstract. One should always remem-ber, though, that the basic motivation is pragmatic: the abstractions have arisen out of necessityand can usually be related directly to concrete intuitions. Moreover, formal techniques need notbe applied in full in order to be useful and influential. A knowledge of the main principles oftype systems can help in avoiding obvious and not so obvious pitfalls, and can inspire regularityand orthogonality in language design.
When properly developed, type systems provide conceptual tools with which to judge theadequacy of important aspects of language definitions. Informal language descriptions often failto specify the type structure of a language in sufficient detail to allow unambiguous implemen-tation. It often happens that different compilers for the same language implement slightly dif-ferent type systems. Moreover, many language definitions have been found to be type unsound,allowing a program to crash even though it is judged acceptable by a typechecker. Ideally, for-mal type systems should be part of the definition of all typed programming languages. This way,typechecking algorithms could be measured unambiguously against precise specifications and,if at all possible and feasible, whole languages could be shown to be type sound.
In this introductory section we present an informal nomenclature for typing, execution er-rors, and related concepts. We discuss the expected properties and benefits of type systems, andwe review how type systems can be formalized. The terminology used in the introduction is notcompletely standard; this is due to the inherent inconsistency of standard terminology arisingfrom various sources. In general, we avoid the words type and typing when referring to run timeconcepts; for example we replace dynamic typing with dynamic checking and avoid commonbut ambiguous terms such as strong typing. The terminology is summarized in the DefiningTerms section.
Type Systems
Luca Cardelli
Microsoft Research
mind-blowing.
Thursday, March 8, 12
![Page 40: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/40.jpg)
Thursday, March 8, 12
![Page 41: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/41.jpg)
Thursday, March 8, 12
![Page 42: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/42.jpg)
Thursday, March 8, 12
![Page 43: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/43.jpg)
Thursday, March 8, 12
![Page 44: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/44.jpg)
Thursday, March 8, 12
![Page 45: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/45.jpg)
Thursday, March 8, 12
![Page 46: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/46.jpg)
Thursday, March 8, 12
![Page 47: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/47.jpg)
Thursday, March 8, 12
![Page 48: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/48.jpg)
Thursday, March 8, 12
![Page 49: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/49.jpg)
Thursday, March 8, 12
![Page 50: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/50.jpg)
sounds cool
Thursday, March 8, 12
![Page 51: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/51.jpg)
Thursday, March 8, 12
![Page 52: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/52.jpg)
i suck
Thursday, March 8, 12
![Page 53: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/53.jpg)
i suck i suck
Thursday, March 8, 12
![Page 54: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/54.jpg)
i suck i suck i suck
Thursday, March 8, 12
![Page 55: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/55.jpg)
i suck i suck
Thursday, March 8, 12
![Page 56: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/56.jpg)
i suck
Thursday, March 8, 12
![Page 57: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/57.jpg)
Thursday, March 8, 12
![Page 58: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/58.jpg)
monads #FTW
Thursday, March 8, 12
![Page 59: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/59.jpg)
Thursday, March 8, 12
![Page 60: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/60.jpg)
there’s a lot of science.
Thursday, March 8, 12
![Page 61: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/61.jpg)
there’s a lot of science.
“the study of nature”—Anant Agarwal and Jeffrey Lang, 2007. MITOpenCourseWare
Thursday, March 8, 12
![Page 62: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/62.jpg)
there’s a lot of science.
very little engineering.
Thursday, March 8, 12
![Page 63: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/63.jpg)
there’s a lot of science.
“purposeful use of science”—Anant Agarwal and Jeffrey Lang, 2007. MITOpenCourseWare
very little engineering.
Thursday, March 8, 12
![Page 64: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/64.jpg)
what about engineering advice?well, there’s some.
Thursday, March 8, 12
![Page 65: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/65.jpg)
Thursday, March 8, 12
![Page 66: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/66.jpg)
Thursday, March 8, 12
![Page 67: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/67.jpg)
Thursday, March 8, 12
![Page 68: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/68.jpg)
M A N N I N G
Michael FogusChris HouserFOREWORD BY STEVE YEGGE
Thursday, March 8, 12
![Page 69: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/69.jpg)
M A N N I N G
Michael FogusChris HouserFOREWORD BY STEVE YEGGE
Thursday, March 8, 12
![Page 70: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/70.jpg)
Better Functional Design Through Test-Driven
DevelopmentPhil Calçado - SoundCloud
@pcalcadohttp://philcalcado.com
Thursday, March 8, 12
![Page 71: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/71.jpg)
Better Functional Design Through Test-Driven
DevelopmentPhil Calçado - SoundCloud
@pcalcadohttp://philcalcado.com
and how is this supposed
to help?
Thursday, March 8, 12
![Page 72: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/72.jpg)
mission: introduce Android support for push notifications
Thursday, March 8, 12
![Page 73: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/73.jpg)
Thursday, March 8, 12
![Page 74: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/74.jpg)
trying to test this...
Thursday, March 8, 12
![Page 75: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/75.jpg)
Thursday, March 8, 12
![Page 76: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/76.jpg)
not horrible... but we are asserting two things on each case.refactor!
Thursday, March 8, 12
![Page 77: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/77.jpg)
Thursday, March 8, 12
![Page 78: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/78.jpg)
make it pass...
Thursday, March 8, 12
![Page 79: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/79.jpg)
Thursday, March 8, 12
![Page 80: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/80.jpg)
Thursday, March 8, 12
![Page 81: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/81.jpg)
our test is not covering all interesting scenarios.
Thursday, March 8, 12
![Page 82: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/82.jpg)
our test is not specifying all interesting scenarios.
Thursday, March 8, 12
![Page 83: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/83.jpg)
Thursday, March 8, 12
![Page 84: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/84.jpg)
make it pass...
Thursday, March 8, 12
![Page 85: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/85.jpg)
Thursday, March 8, 12
![Page 86: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/86.jpg)
Thursday, March 8, 12
![Page 87: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/87.jpg)
now how to define iPhone notifications?
Thursday, March 8, 12
![Page 88: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/88.jpg)
Thursday, March 8, 12
![Page 89: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/89.jpg)
what about android?
Thursday, March 8, 12
![Page 90: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/90.jpg)
Thursday, March 8, 12
![Page 91: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/91.jpg)
we moved from
Thursday, March 8, 12
![Page 92: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/92.jpg)
Thursday, March 8, 12
![Page 93: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/93.jpg)
functional language,
procedural abstractions
Thursday, March 8, 12
![Page 94: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/94.jpg)
to
Thursday, March 8, 12
![Page 95: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/95.jpg)
Thursday, March 8, 12
![Page 96: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/96.jpg)
functions as abstractions
Thursday, March 8, 12
![Page 97: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/97.jpg)
Thursday, March 8, 12
![Page 98: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/98.jpg)
combinator
Thursday, March 8, 12
![Page 99: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/99.jpg)
just because we wanted better tests.
Thursday, March 8, 12
![Page 100: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/100.jpg)
I see strong correlation between good design and test-driven development.
Thursday, March 8, 12
![Page 101: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/101.jpg)
code which is coupled and complicated is bad design
Thursday, March 8, 12
![Page 102: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/102.jpg)
code which is coupled and complicated is
hard to maintain
Thursday, March 8, 12
![Page 103: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/103.jpg)
code which is coupled and complicated is hard to test
Thursday, March 8, 12
![Page 105: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/105.jpg)
Qs?
Phil Calçado - SoundCloud@pcalcado
http://philcalcado.comThursday, March 8, 12
![Page 106: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/106.jpg)
http://bit.ly/work-at-soundcloud
Thursday, March 8, 12
![Page 107: (v2.0) Better Functional Design Through Test-Driven Development](https://reader033.vdocument.in/reader033/viewer/2022060109/5556836cd8b42a182f8b48d0/html5/thumbnails/107.jpg)
http://www.flickr.com/photos/wolfgangstaudthttp://www.flickr.com/photos/seite-3/http://www.flickr.com/photos/nirakhttp://www.flickr.com/photos/doug88888/http://www.flickr.com/photos/donnagraysonhttp://rsiqueira.postbit.com/tk2000.html
pics:
Thursday, March 8, 12