38 4/11/98 CSE 143 Modules [Chapter 2]

39 4/11/98 What is a Module?  Collection of related items packaged together  Examples:  Stereo System Components  Computer Components  Application Suites

40 4/11/98 Example Turntable Tuner CD Player Tape Deck  Two ways to design a stereo system Turntable Tuner CD Player Tape Deck All-in-one design Modular design What are the advantages of each?

41 4/11/98 Modularization  Basic idea: break apart large system into smaller units (modules)  Group related functionality in one module  Often continued in a hierarchy of modules  Design modules to be general and reusable  Multiple times in same program  Different programs/programmers

42 4/11/98 Specification vs. Implementation Two parts of each module  Specification (what)  Also known as “interface”  Describes what services module provides to clients (users)  Publicly visible  Implementation (how)  Parts of the module that actually do work  Private, hidden behind module interface

43 4/11/98 Specification as Contract Module specification acts as a contract between client and implementor  Client depends on specification not changing  Doesn’t need to know any details of how module works, just what it does  Implementor can change anything not in the specification, (eg. to improve performance)  Implementation is a “black box” (encapsulation), providing information hiding

44 4/11/98 Locality  Locality of design decisions from encapsulation  Benefits of private data and algorithm locality:  Division of labor  Easier to understand  Implementation independence

45 4/11/98 Modules in C++  Modules represented by a pair of files  specification (.h ) file  implementation (.cpp,.cc,.c++,.C, etc) file  Client’s only interaction with module is through the interface defined in the.h file

46 4/11/98 Imports and Exports  Specification (. h ) file declares which items are exported  constants, function prototypes, and data types  Client program must import features of a module to use them  Use the #include directive  Implementation (. cpp ) file also uses #include to ensure it obeys the contract

47 4/11/98 Specification  Supplies constants, data types, function prototypes  Comments describing what each function does  Preconditions: What should be true before function call (e.g., relationships among arguments)  Postconditions: What is true after function return (e.g., relationship of return value to arguments)  Invariants: What must be true while function executes (e.g., relationships among local variables)

48 4/11/98 Sample Specification File // Specification file for computational geometry // functions // POST: returns the area of a circle with given // radius double circleArea (double radius); // PRE: area must be non-negative // POST: returns the radius of a circle of given // area double circleRadius(double area); geometry.h prototype

49 4/11/98 Sample Implementation File // Implementation of geometry functions #include "geometry.h" #include const double PI = ; double circleArea (double radius) { return PI * radius * radius; } double circleRadius (double area) { return sqrt(area/PI); } geometry.cpp

50 4/11/98 Sample Client File #include #include "geometry.h" int main(void) { double value; cout << "Enter radius: "; cin >> value; cout << "Area of circle is " << circleArea(value) << endl; return 0; } main.cpp

51 4/11/98 Building the Program Three stages to go from source code to executable:  Preprocess  reads #include files, expands #define  Compile  Converts C++ code to object code the computer can understand  Link  Connects your object code with system libraries to make an executable program

52 4/11/98 Building the Program (2) Compile compiler main.cpp geometry.h Compile compiler iostream.h Link linker main.exe geometry.obj main.obj geometry.cpp geometry.h math.h geometry.obj main.obj libraries

53 4/11/98 Separate Compilation  Each module’s.cpp source code is converted into object code separately  Linker collects object code together to build executable  Many environments hide this process from you  On MSVC, just press the “build all” button (or even just “run” …)  Must be done “manually” under UNIX

54 4/11/98 Advantages of Separate Compilation  One module usable by many clients  Individual modules may be changed and recompiled without changing entire program  Client’s code can be changed and recompiled without recompiling modules  Can distribute object code to protect secrets  Interface (specification) changes mandate recompiling both implementation and client

55 4/11/98 Designing Modules  Must think about implementor’s and client’s roles  Implementor’s goals:  Provide a reusable, robust abstractions  Make interface independent of client  Keep freedom to modify implementation  Protect module from abuse and misuse  Client’s goals:  Assemble a program from usable modules  Rely solely on specification  Very hard to do well!

56 4/11/98 Standard Libraries  C/C++ comes with some predefined modules (libraries)  iostream.h, fstream.h for stream I/O  math.h for sin, cos, sqrt, etc.  string.h for strcmp, strlen, etc.  Compilers also include nonstandard libraries  Graphics, windowing, etc.  Please don’t use them for CSE 143

57 4/11/98 Compile-time error if identifiers (function names, constants, etc.) are defined multiple times: Multiple Inclusion... const int MINSIZE = 20; void writeLetters (ofstream& otfile);... #include "lmatrix.h"... #include "lmatrix.h" #include "word.h"... word.h lmatrix.h main.cpp

58 4/11/98 Multiple Inclusion (2)  To avoid this problem, use preprocessor directives: // lmatrix.h #ifndef _LMATRIX_H_ #define _LMATRIX_H_... const int MINSIZE = 20; void writeLetters (ofstream& otfile);... #endif  Read the above as: If _LMATRIX_H_ undefined, compile the code through #endif Preprocessor directive

59 4/11/98 Summary  Specification (.h ) and implementation (.cpp ) files  Specification as contract  Information hiding, black box analogy, locality  Imports and exports, public and private code  Separate compilation