C++ Language - Session 10: A Few More Topics - FPT University

Nội dung text: C++ Language - Session 10: A Few More Topics - FPT University

1. Session 10 - A Few More Topics The ISO Standard Design Principles Session 10 - A Few More Topics 1/32
2. Objectives • The ISO Standard – Libraries – Namespaces – Insufficient Space – Casting – Implicit – Explicit Session 10 - A Few More Topics 2/32
3. Objectives • Design Principles – Design Principles – Object Definition – Relationships Session 10 - A Few More Topics 3/32
4. The ISO Standard • The official standard for the C++ language is the ISO/IEC 14882 standard. • The standard added new features, removed some old features and deprecated some other old features. • New features: – a fully rewritten stream library, – Namespaces, – a string class, – casting syntax and – a comprehensive standard template library. Session 10 - A Few More Topics 4/32
5. Libraries(1) • Certain standard libraries are completely rewritten versions of the pre-standard libraries. • The standard libraries have unique names that distinguish the libraries from the pre-standard ones. • The standard header files have names that are prefaced by the character c. These names do not include the .h suffix found with the pre-standard versions. This convention applies only where the standard introduced only minor changes. The standard did not apply the c prefix notation to those libraries that were rewritten to any significant extent • For example: – cstring corresponding pre-standard library is string.h. Session 10 - A Few More Topics 5/32
6. Libraries(2) • The standard library objects are declared in the std namespace. Pre-standard library objects were declared globally. • Syntax: using namespace std; Session 10 - A Few More Topics 6/32
7. Namespaces • A namespace is a named scope. • A named scope may contain declarations of local identifiers. • An identifier in one namespace does not conflict with the identically named identifier declared in another namespace. =>Namespaces minimize identifier naming conflicts in large systems with multiple libraries. Session 10 - A Few More Topics 7/32
8. Insufficient Space (1) • If the operating system is unable to provide the freestore memory that a program requests, the call to the new operator generates an error. • In ISO C++, the new operator, if passed a nothrow argument, returns the NULL address in the event of such a failure. • To define the nothrow argument, we include the new header file. Session 10 - A Few More Topics 8/32
9. Insufficient Space (2) #include #include using namespace std; int main( ) { char* p; int i = 0; do { p = new (nothrow) char[100001]; i++; } while (p != NULL); cout << "Out of space after " << i << " attempts!" << endl; return 0; } Session 10 - A Few More Topics 9/32
10. Casting • Pre-Standard Casts – C-style: (type)indentifier – Function-style: type(indentifier) Session 10 - A Few More Topics 10/32
11. Standard Style Casts(1) • Convert between related types: static_cast identifier Session 10 - A Few More Topics 11/32
12. Standard Style Casts(2) • Unrelated Data Types – For converting between unnrelated data types such as int to pointer to an int or pointer to an unrelated pointer type, we use the reinterpret_cast keyword. Session 10 - A Few More Topics 12/32
13. Implicit • The C language used to allow the omission of int in function and variable declarations. C99 no longer allows such omissions. • Standard C++ requires that we specify the data type of every function, variable and constant. Session 10 - A Few More Topics 13/32
14. Explicit(1) • A single argument constructor defines an implicit conversion between the type of its parameter and the constructor's class type. • To suppress such implicit conversions, we qualify the constructor as explicit in the class declaration. Session 10 - A Few More Topics 14/32
15. Explicit(2) Session 10 - A Few More Topics 15/32
16. Design Principles (1) • Design proceeds from the application itself. • Object and class abstractions identify the concept boundaries in the application domain. • To minimize complexity, we divide the application into modules so that each module: – is highly cohesive, and – exhibits low coupling Session 10 - A Few More Topics 16/32
17. Design Principles (2) • The primary identifications in the early stages of design include: – key abstractions - the objects that form the vocabulary of the problem domain, – implementation mechanisms - the structures that objects use to provide the behaviors that satisfy the requirements of the problem Session 10 - A Few More Topics 17/32
18. Abstractions(1) • Sources – Highlight nouns that repeat in the written requirements document (Abbott, 1983). The verbs associated with them suggest the operations on the objects themselves. – Another way to identify key abstractions is through problem domain experts. Experts usually describe their problems in terms of the basic abstractions of the application domains. – Shlaer and Mellor (1988) suggest the following classification of sources: • tangible things - such as cars, tables, persons • roles - such as teachers, politicians, doctors • events - such as requests, landings, crashes • interactions - such as meetings, celebrations Session 10 - A Few More Topics 18/32
19. Abstractions(2) • Collaboration – Once we have isolated potential key abstractions, we refine our design to ensure collaboration amongst them. Session 10 - A Few More Topics 19/32
20. Abstractions(3) • Support Classes – Each and every class in a complete design does not have to correspond directly to an abstraction from the application domain. Session 10 - A Few More Topics 20/32
21. Abstractions(4) • Implementation Mechanisms – Implementation mechanisms represent patterns of behavior. – One tool for identifying the mechanisms is a set of representative scenarios. Scenarios are typical cases that we expect the application to process. We refer to these as "use cases". Session 10 - A Few More Topics 21/32
22. Abstractions(5) • Member Functions – Stroustrup (1997) classifies member functions according to their use of an object's state: • Foundations - constructors, destructors and copy operators • Queries - do not change the state of an object • Modifiers - update the state of an object • Conversions - produce an object of another type from the current object Session 10 - A Few More Topics 22/32
23. Abstractions(6) • Member Functions! – Once we accept a prospective set of public member functions, we write out the purpose of each function in the form of its header comment. If our comment is simple and clear, the function is a strong candidate for implementation. If our comment is unclear or complex, we need to reconsider the implementation in the hope of finding a simpler and cleaner design. Session 10 - A Few More Topics 23/32
24. Object Definition(1) • Metrics – Booch (1994) proposed five metrics for defining objects well: • low coupling – Coupling measures the design interface. (avoid friendship and inheritance) • high cohesion – Cohesion measures internal design • Sufficiency – Sufficiency measures the satisfaction of minimum requirements • Completeness – Completeness measures satisfaction of necessary requirements • Primitiveness – Primitiveness keeps completeness in check Session 10 - A Few More Topics 24/32
25. Object Definition(2) • Invariance – Invariance is a concept that is central to abstraction. An invariant is a Boolean condition that is always true for any instance of a class. – The invariant of an object is that property that makes the state of an object well-defined. Session 10 - A Few More Topics 25/32
26. Object Definition(3) • Invariance (sample): Consider an ISBN class. Every ISBN has • exactly ten digits and • a checkdigit that is modulo 11 No matter what operation or function is performed on an ISBN, these two conditions must be satisfied before and after any call to the operation or function. Session 10 - A Few More Topics 26/32
27. Object Definition(4) • Kinds of Classes: Stroustrup (1997) identified the different roles that classes play in an application: – Concrete types • We understood a class of concrete type in isolation from other classes and rarely use it as a base class in a hierarchy – Nodes • Part of a class hierarchy. It relies upon its base class for implementation and provides a wider interface than does the base class. Use it for further derivation. – Interfaces: is empty or nearly empty class – Handles: A handle class separates the user interface from the representation of the object itself. Session 10 - A Few More Topics 27/32
28. Relationships(1) • The three basic kinds of relationship amongst classes and objects that we have covered are: – inheritance, – aggregation, – association. Session 10 - A Few More Topics 28/32
29. Relationships(2) • Inheritance – Inheritance describes the ordering of classes in a hierarchy. The base class is the more abstract class, while the derived class is the more concrete class. Session 10 - A Few More Topics 29/32
30. Relationships(4) • Association – An association is a semantic connection between classes. – An association allows one class to know about the public attributes and operations of another class. Session 10 - A Few More Topics 30/32
31. Relationships(3) • Aggregation – An aggregation is a stronger form of association. An aggregation is a relationship between a whole and its parts. Session 10 - A Few More Topics 31/32
32. Summary • The ISO Standard – Libraries – Namespaces – Insufficient Space – Casting – Implicit Q&A – Explicit • Design Principles – Design Principles – Object Definition – Relationships Session 10 - A Few More Topics 32/32