Study Guide 10 Answers

Class designers often have a preferred way of orienting the classes and relationship connectors in a UML class diagram. However, constraints such as eliminating or minimizing relationships that cross each other may require us to abandon that orientation, making it necessary to examine the connectors closely to identify the relationships.

b. Alpha is the whole class and Gamma is the part.
c. Beta is the whole class and Delta is the part.
a. Gamma is the superclass and Delta is the subclass.
d. The classes are peers.
e. Delta is the dependent or client class; Epsilon is the independent or supplier class.
Aggregation. Implemented with a class-scope pointer variable.
Composition. Implemented with a class-scope non-pointer variable.
Dependency. A member function has a local variable of class type. We often omit dependencies from class diagrams because they are numerous and contribute less to our understanding of a system than the other relationships.
Association. Implemented with two class-scope pointer variables, one in each class. Association requires one or two forward references.
Dependency. The accepted implementation of dependency as a member function parameter.
Inheritance. The only relationship implemented with dedicated syntax: : public superclass_name.
Overridden functions
Overloaded functions
Overloaded functions
Overridden functions
b: Sending a message to an object is equivalent to calling one of the object's member functions
a & b: foo has a default constructor, which may be called implicitly (a) or explicitly (b)
a, b, & c: foo has a constructor that requires one integer argument, which the first three initializer lists provide
d: the foo constructor requires two arguments, and the initializer for (d) is the only one that provides the correct number
a: Although bar inherits function1 from foo, it overrides it with its own version of function1. When looking for inherited features, the compiler will begin with the class named in the variable definition (e.g., bar in bar b) and work its way up the inheritance chain; it will use the first one that it finds (the one in bar in this case).
b: bar inherits function2 from foo and may call it just as if it was defined in foo (remember, a bar is a foo).
c: C++ supports recursion but function1 in bar is not a properly formed recursive function. The body of function1 will call function1, which will call function1, which will. . . . Well, you get the idea.
d: The body of function1 in bar calls function1 in foo. In an inheritance situation like this, the bar function1 is said to be written in terms of the foo function1.
d: Although bar inherits the counter variable from foo, it may not access it directly because it is private in foo. The program will compile and run if we change private to protected in foo or if foo provides a function to access counter, which would be called in bar.
d: Begin with obj2.print(), you can ignore obj1 because the program doesn't do anything with it after it constructs it. The constructor call for obj2 passes 10 to the constructor, which stores that value in bar my_data. obj2.print() prints the value stored in my_data: 10.
a: Whenever an initializer list processes an inheritance relationship, it must be the first element in the list, before any member variable or other relationships; remaining relationships and variables my initialized in any order.
a: The B initializer is calling the constructor function in A, and the number of arguments in the call must match the number of parameters in the function definition
c: Use the member variable name in the whole class to call a constructor in the composed or part class
my_bar(a, b)
my_bar.display()
my_bar->display()
b: foo doesn't have any pointer members, so it doesn't need a copy constructor

bar::bar(bar& a_bar)
{
	name = new char[strlen(name) + 1];
	strcpy(name, a_bar.name);
	salary = a_bar.salary;
}

The two classes are related by inheritance
1. count(a_count), balance(a_balance) -- order is not significant
2. Bar(count, balance), name(a_name) -- Bar must be first
3. Bar::display()
The two classes are related by composition
1. count(c), balance(b) -- order is not significant
2. my_bar(c, b), name(n) -- order is not significant
3. my_bar.display()
The two classes are related by aggregation
1. count(c), balance(b)
2. name(n), my_bar(nullptr) -- the highlighted code is optional, but older versions of C++ required it
3. if (my_bar != nullptr) delete my_bar
4. if (my_bar != nullptr) delete my_bar
5. my_bar = new Bar(c, b)
6. if (my_bar != null_nullptr) my_bar->display()
There are several unique inheritance characteristics, and describing any one of them satisfies the question.
- Inheritance is the only relationship with dedicated implementation syntax: : public superclass-name. C++ implements the other relationships with variables.
- Inheritance is the only "Has-A" relationship.
- Inheritance is the only class relationship upon which other object-oriented concepts depend. For example:
  - Upcasting
  - Function overriding
  - Substitutability
  - Polymorphism (aka dynamic dispatch)
Association is the only bidirectional or two-way relationship. Like aggregation and composition, it is a "Has-A" relationship, but unlike them, it reads well in both directions.
As suggested by the similarity of their respective UML connector symbols, aggregation and composition have much in common. Both form a one-way or unidirectional or "Has-A" connection, implementing a whole-part relationship. However, they differ in their respective binding strengths (i.e., the "tightness" of their bindings). Binding strength summarizes the related object's relative lifetimes and the ability of the whole to share its parts. Composition's strong or tight binding requires the whole and part to have simultaneous (i.e., the same) lifetimes - the program creates and destroys the whole and part at the same time. Aggregation's weak or loose binding allows objects to have independent or different lifetimes; the program can create or change the connection between the whole and its parts whenever doing so is convenient. Composition doesn't allow a whole to share its parts, while aggregation allows sharing.