Relationships between classes

• is-a: subtyping
• has-a: aggregation, composition
• uses-a: dependency

Subtyping vs. subclassing/inheritance

• Subtyping allows substituting a more specific object for a more general one.
• Inheritance is a mechanism for a subclass to reuse code from a superclass.
• Inheritance usually enables subtyping. But it is not the only way to enable subtyping; implementing or extending an interface are other ways.

Class-interface continuum C# (items 22, 23)

• Concrete class: can be instantiated. All specified methods are fully implemented.
• Abstract class: cannot be instantiated. Some or all of the specified methods are not implemented.
• Interface: limit case of a fully abstract class for specification purposes only. None of the specified methods are eimplemented, and there are no instance variables (only class-level constants).

Static vs. dynamic type (item 3)

• Static type: declared type of a variable.
• Dynamic type: actual type of the object to which the variable refers.
• How are static and dynamic type of a variable related?
• Casting: treat an object as if it had a different static type. Three different situations: downcast, upcast, crosscast.

Reference semantics vs. value semantics C# (item 6)

• Value semantics: variables directly contain values.
• Reference semantics: variables contain addresses that refer (point) to objects.

Equality vs. identity C# (items 6, 26)

• Equality: are two (possibly) different objects equivalent?
• Identity: do two references refer to the same objects?
• How are equality and identity related?

Packages/Namespaces C#

• Mechanism for grouping related or collaborating classes (cf. default package-level member access).
• Implemented as mapping from fully qualified class names to file system.

Member access C#

• public
• protected
• default (package)
• private

Being a descendent of java.lang.Object/System.Object C# (items 5, 9, 10, 27)

Implementing classes are usually required to provide the following methods:

• toString
• equals
• hashCode
• clone
• compareTo

Clone in the context of the Composite pattern C# (items 14, 27)

In general, cloning allows you to make a copy of an object. The clone method in Java is similar to the copy constructor in C++, but it is an ordinary method, unlike the copy constructor. Once you have the original object and its clone, then you can modify each one independently.

Cloning models the real-life situation where you build a prototype of something, say a car or a piece of furniture, and once you like it, you clone it as many times as you want. These things are composites, and the need to be cloned deeply (recursively).

As another example, imagine a parking garage with a list of cars that have access to it. To build another garage to handle the growing demand, you can clone the garage and the access list. But the cars should not get cloned. That's because the garage is not composed of the cars.

As we can see, the conceptual distinction between aggregation and composition has significant consequences for the implementation of the relationship. True, both relationships are represented as references in Java. However, composites usually require a deep clone (if cloning is supported): each parent is responsible for cloning its children.

Note also that you don't need to clone at all if your objects are not mutable because you wouldn't be able to distinguish the original from the clone anyway.