دسترسی نامحدود
برای کاربرانی که ثبت نام کرده اند
برای ارتباط با ما می توانید از طریق شماره موبایل زیر از طریق تماس و پیامک با ما در ارتباط باشید
در صورت عدم پاسخ گویی از طریق پیامک با پشتیبان در ارتباط باشید
برای کاربرانی که ثبت نام کرده اند
درصورت عدم همخوانی توضیحات با کتاب
از ساعت 7 صبح تا 10 شب
دسته بندی: برنامه نویسی: زبان های برنامه نویسی ویرایش: 1 نویسندگان: James O. Coplien سری: ISBN (شابک) : 0201824671, 9780201824674 ناشر: Addison-Wesley Professional سال نشر: 1998 تعداد صفحات: 276 زبان: English فرمت فایل : PDF (درصورت درخواست کاربر به PDF، EPUB یا AZW3 تبدیل می شود) حجم فایل: 2 مگابایت
در صورت تبدیل فایل کتاب Multi-Paradigm Design for C++ به فرمت های PDF، EPUB، AZW3، MOBI و یا DJVU می توانید به پشتیبان اطلاع دهید تا فایل مورد نظر را تبدیل نمایند.
توجه داشته باشید کتاب طراحی چند پارادایم برای C++ نسخه زبان اصلی می باشد و کتاب ترجمه شده به فارسی نمی باشد. وبسایت اینترنشنال لایبرری ارائه دهنده کتاب های زبان اصلی می باشد و هیچ گونه کتاب ترجمه شده یا نوشته شده به فارسی را ارائه نمی دهد.
Coplien بینشی در مورد فرآیند تحلیل و طراحی ارائه میدهد که از قابلیت الگوهای چندگانه C++، از جمله کلاسها، توابع اضافه بار، قالبها، ماژولها، برنامهنویسی رویهای و موارد دیگر بهره میبرد. این کتاب از نمادهای قابل درک و توضیحات قابل خواندن استفاده می کند تا به همه برنامه نویسان ++C - نه فقط معماران و طراحان سیستم - کمک کند تا چندین پارادایم را در توسعه برنامه خود برای نرم افزار مؤثرتر، کارآمدتر، قابل حمل، قوی تر و قابل استفاده مجدد تر ترکیب کنند. طراحی چند پارادایم عمیقتر از هر فناوری یا تکنیکی برای پاسخگویی به سؤالات اساسی انتزاع و طراحی نرمافزار است.
Coplien offers insight into an analysis and design process that takes advantage of C++'s multiple paradigm capability, including classes, overloaded functions, templates, modules, procedural programming, and more. The book uses understandable notation and readable explanations to help all C++ programmers--not just system architects and designers--combine multiple paradigms in their application development for more effective, efficient, portable, robust, and reusable software. Multi-paradigm design digs deeper than any single technology or technique to address fundamental questions of software abstraction and design.
Contents......Page 3
Apologia......Page 13
Abstraction......Page 15
Software Families......Page 16
Paradigm......Page 17
Meta-Design......Page 18
Method apart from Methodology......Page 19
The Organization of the Thesis......Page 20
Notations......Page 21
Acknowledgments......Page 23
Meta-Design......Page 25
The breakdown of classic domain analysis......Page 26
Negative Variability......Page 27
1.2 Domain Engineering and Multiple Paradigms......Page 28
1.3 Design, Analysis, Domains, and Families: Term Definitions......Page 30
1.3.1 Analysis......Page 31
1.3.3 Architecture......Page 32
1.3.5 Families and Commonality Analysis......Page 33
1.3.6 Dimensions of Abstraction......Page 34
1.3.8 Implementation and Engineering......Page 35
1.4 Beyond Objects......Page 36
1.5 Commonality and Variability Analysis......Page 37
1.6 Software Families......Page 38
1.7 Multi-Paradigm Design......Page 39
1.7.2 Dealing with Complex Families......Page 40
1.8 Multi-Paradigm Development and Programming Language......Page 42
1.8.1 Application-Oriented Languages in FAST......Page 43
1.8.2 Domain Analysis and the C++ Programming Language......Page 44
1.9 Commonality Analysis: Other Perspectives......Page 46
1.9.2 Variability over Time versus Variability over Space......Page 47
1.9.3 Philosophical Foundations......Page 48
1.10.1 Historic Notes......Page 50
1.10.2 metaobject Protocols......Page 51
1.10.4 Generative Programming......Page 52
1.11 Summary......Page 53
2.1 Commonality: The Essence of Abstraction......Page 55
2.1.1 Deductive and Inductive Commonality......Page 56
2.1.2 Software Families......Page 58
Finding Domains......Page 59
2.2.1 The Domain Dictionary......Page 60
2.2.2 Design Epistemology......Page 62
2.3 Dimensions of Commonality and Commonality Categories......Page 64
Figure 2.3: A family of operator* functions.......Page 65
Figure 2.4: Another dimension: Template arguments.......Page 66
2.3.1 (Data) Structure......Page 68
2.3.2 Name and Behavior......Page 72
2.3.3 Algorithm......Page 75
2.4.1 Structure......Page 76
2.4.2 Name and Behavior......Page 77
2.4.3 Algorithm......Page 79
2.5 Reviewing the Commonality Analysis......Page 81
2.6 Commonality and Evolution......Page 82
2.7 Summary......Page 83
3.1 Variability: The Spice of Life......Page 85
3.2 The Commonality Base......Page 86
3.3.1 Positive Variability......Page 87
3.3.2 Negative Variability......Page 88
3.4.1 The Text Editing Buffers Example......Page 90
3.4.2 Good Parameters of Variation......Page 91
3.5.3 Efficiency and Binding Time......Page 92
Link (and Load) Time......Page 93
3.6 Defaults......Page 94
3.7 Variability Tables......Page 95
3.8 Some Variability Traps......Page 97
3.10 Variability Dependency Graphs......Page 98
3.11 Summary......Page 99
4.1 Analysis, Domain Analysis, and Beyond......Page 101
4.1.2 System Families: Domain Analysis......Page 102
Balancing Abstraction and Specification......Page 104
Levels of Domain Abstraction......Page 105
4.1.4 The Activities of Domain Analysis......Page 107
4.2 Subdomains within a Domain Analysis......Page 109
Figure 4.1: Subdomains in the domain of Text Editing.......Page 110
4.2.1 Domain Analysis and Reuse......Page 111
4.2.2 Subdomain Modularity......Page 112
4.2.3 Iteration and Hierarchy......Page 113
4.3 The Structure of a Subdomain......Page 114
4.3.1 Frameworks as Subdomain Implementations......Page 116
4.3.2 The Activities of Subdomain Analysis......Page 117
4.4 Analysis: The Big Picture......Page 118
Figure 4.2: The domains of analysis.......Page 119
4.5 Summary......Page 120
5.1.1 Classes and Objects......Page 121
5.1.3 Virtual Functions......Page 122
Defaults......Page 124
Language and Paradigm......Page 126
5.2 Object-Oriented Commonality Analysis......Page 127
Figure 5.1: The domain dictionary for digital circuit design.......Page 128
5.2.2 Variability Analysis......Page 129
5.3 Summary......Page 130
6.1 The “Other” Domain......Page 133
Figure 6.1: Comparing a C++ design and Smalltalk design of class Stack.......Page 134
6.3 Data......Page 135
6.4 Overloading......Page 136
6.5.1 Template Specialization......Page 137
6.7 Inheritance......Page 138
Figure 6.2: A unified subtype/implementation inheritance hierarchy for Number.......Page 139
6.7.1 Aligning Domains......Page 140
Figure 6.3: Inheritance to reuse implementation and structure, not behavior.......Page 141
Figure 6.5: Encapsulation to reuse implementation and structure, not behavior.......Page 142
Figure 6.7: Separate implementation and subtyping hierarchies using Bridge.......Page 143
6.8 Virtual Functions......Page 144
Figure 6.8: The Wegner polymorphism taxonomy.......Page 146
6.11 Negative Variability......Page 147
6.11.1 Deciding When to Use Negative Variability......Page 148
Figure 6.10: A simple stack.......Page 149
An Example of Data Cancellation......Page 150
An Example of Behavior Cancellation......Page 153
An Example of Contravariance......Page 154
An Example of #ifdef......Page 156
An Example of Behavior Cancellation......Page 157
A Template Example......Page 158
An Example of #ifdef......Page 159
First case: Multiple Domains......Page 160
Second case: Mix-ins......Page 164
6.12.2 Design Patterns......Page 165
Patterns Beyond Language......Page 166
1. As aliases for commonality/variability pairs that emerge from the solution domain analysis......Page 167
Aliases for Solution Domain Constructs......Page 168
Higher-Level Than Programming Language Constructs......Page 169
Figure 6.11: Structure of the Bridge pattern (adapted from [Gamma1995], p. 153).......Page 171
Negative Variability......Page 170
6.13 A Summary of the C++ Solution Domain: A Family Table......Page 175
6.14 Relative Power of Paradigms......Page 176
7.1.1 One Size Does Not Fit All......Page 179
7.1.2 Degrees of Complexity......Page 182
Single Domain, Single Paradigm......Page 183
Multiple Decoupled Subdomains, Multiple Paradigms for Each Subdomain......Page 184
Circular Subdomains......Page 185
Figure 7.1: Relationships in classic MVC and in the more coupled EntryForm example.......Page 186
7.2 Activities of Multi-Paradigm Design......Page 187
1. Divide the problem into intuitive subdomains (Section4.1.4).......Page 188
7.3 Example: A Simple Language Translator......Page 192
Choosing a Partitioning......Page 193
Domain Analysis......Page 194
Domain Analysis and Iteration......Page 195
The Domain Vocabulary......Page 196
1. Abstractions in the external interfaces of the domain......Page 197
Figure 7.4: Reduced variability dependency graph for commonality domain: Name.......Page 201
Returning to the Question of Line Numbers and Labels......Page 202
Figure 7.5: Some C++ class interfaces capturing the analysis of Table7.1.......Page 203
7.4.1 Analysis, Architecture, or Design?......Page 204
1. Calculate the derivative directly as the slope of the function at a given point, dividing the .........Page 205
Figure 7.6: Automatic differentiation domain vocabulary.......Page 207
7.5.2 Degree Domain......Page 208
7.5.3 Value Domain......Page 209
Figure 7.7: Variability dependency graph for automatic differentiation.......Page 210
7.5.4 Evolving the Design......Page 213
7.7 Management Issues......Page 214
7.7.1 Occam’s Razor: Keeping Things Simple......Page 215
7.7.2 Divide and Conquer......Page 216
Capturing the Big Picture......Page 217
7.7.3 Beyond C++......Page 218
7.7.5 Systems Engineering and Process Issues......Page 219
7.8 Summary......Page 221
8.1 Method and Design......Page 223
8.2 Commonality Analysis: What Dimension of Commonality?......Page 224
8.3.1 Variability Analysis......Page 226
Figure 8.1: Variability dependency graph for the Text Buffer commonality analysis.......Page 228
8.3.2 Expressing the Commonality and Variability in C++......Page 227
8.5 Summary......Page 231
9.1.1 Generalizing Domain Analysis to Multiple Domains......Page 233
9.1.2 A TextBuffer Example......Page 234
Figure 9.1: Dependency graph for the Output Medium commonality analysis.......Page 235
Figure 9.2: Combining two domains of the application.......Page 237
Figure 9.3: Reduced variability dependency graph.......Page 238
9.1.3 First Case: Compile-Time Binding......Page 239
9.1.4 Second Case: Buffer Type depends on Output Medium Type at Run Time; Output Medium Type Dep.........Page 242
Alternative Solutions......Page 245
9.1.5 Third Case: Buffer Type Depends on Output Medium Type at Run Time; Output Medium Type Depe.........Page 247
9.2 Design and Structure......Page 249
9.2.1 A Note on Binding Time......Page 250
Figure 9.5: Class diagram for the design of Section9.1.4 (second design).......Page 251
Figure 9.6: Class diagram for the design of Section9.1.5 (third design).......Page 252
9.3 Another Example: A Finite-State Machine......Page 253
Figure 9.7: Domain diagram for the FSM example.......Page 256
Figure 9.8: Class diagram of the solution.......Page 259
9.5 Summary......Page 260
10.1 Recap......Page 261
10.1.3 The Relationship between Domain and Paradigm......Page 262
10.1.6 Theory of Negative Variability......Page 263
10.2 Other Paradigms......Page 264
10.3 Scalability......Page 265
10.4.2 Taxonomy of Paradigms......Page 266
Bibliography......Page 269