/* This is an example of the MONOLITHIC STYLE of design. Several features are to be noted: (a) Physical modules: 1 file (b) Logical modules: 8 functions (c) Language supported data abstractions used: file. (d) Application defined data abstractions: Vector. (e) Data encapsulation used: NO The type Vector is not encapsulated in its own physical module (file). (f) Information hiding used: Limited In reference to type Vector we note the following: - The representation of the type is completely visible and accessable to the client code, main(). - The client explicitly references and accesses the internal components of type Vector (x,y) in the i/o statements that read and write Vectors. - Limited information hiding is demonstrated in that the internal view of Vectors as "cartesian" or "polar" is hidden in the functions that manipulate Vectors. The internal view is not revealed in the client code either; even though the client reads and writes the components x,y of Vectors, there is nothing in the client that assumes or exploits one particular view over the other. However, there is nothing to prevent the client from exploiting the fact that the internal view of Vectors is Cartesian - we have a well-written client. (g) Decomposition stype: FUNCTIONAL (h) Degree of OO'ness: - Variables are used to denote File objects. The C language provides various library functions (methods) for manipulating file objects. Furthermore, the internal representation of file objects is effectively hidden from all client code. The fopen() function is effectively a constructor for file objects. - Within a single instance of a "problem," Vector variables are used consistent with an object view; that is, variables always denote the same Vector instance - this is a virtue of the client code, not a virtue of the C language. Operations on Vectors are consistent with an object view. 42 */