Comp 410 Final Exam

Front 1

iterator design pattern

Back 1

In object-oriented programming, the Iterator pattern is a design pattern in which iterators are used to access the elements of an aggregate object sequentially without exposing its underlying representation. An Iterator object encapsulates the internal structure of how the iteration occurs.

Front 2

template design pattern

Back 2

The Template Design Pattern is perhaps one of the most widely used and useful design pattern. It is used to set up the outline or skeleton of an algorithm, leaving the details to specific implementations later. This way, subclasses can override parts of the algorithm without changing its overall structure.

A common example of this is when writing a program that will handle data using various sorting algorithms. The AbstractClass would have a method called Sort() (analagous to TemplateMethod() -- the invariant behaviour) which when called, would use the helper methods in the class, which are specified by any class that inherits from it.

Front 3

adapter design pattern

Back 3

In computer programming, the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value.

Front 4

singleton design pattern

Back 4

In software engineering, the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. (This concept is also sometimes generalized to restrict the instance to a specific number of objects - for example, we can restrict the number of instances to five object

Front 5

composite design pattern

Back 5

Composite can be used when clients should ignore the difference between compositions of objects and individual objects.[1] If programmers find that they are using multiple objects in the same way, and often have nearly identical code to handle each of them, then composite is a good choice; it is less complex in this situation to treat primitives and composites as homogeneous.

file system. product bundles.

Front 6

factory design pattern

Back 6

The essence of the Factory Pattern is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

modems?

Front 7

EJ 1

Why consider static factory methods instead of constructors and what does this mean?

Back 7

Example: The java collections has static factory methods like unmodifiable collection.

Static factory methods have names (unlike constructors), don't need to instantiate new objects each time (unlike constructors), can return an object of any subtype (unlike constructors),

Front 8

EJ 3:

Singleton property. What exactly is the singleton class/property, and how do you use it?

Back 8

A singleton is simply a class that is instantiated exactly once.

One way to do it:

Class Elvis {
public static final Elvis INSTANCE = new Elvis()
private Elvis() {}
}

This makes the constructor private so that other classes can't access it. When a new elvis class is instantiated, the member field will be initialized and a new elvis is created once.

Another approach is to make the member field private and make a public getInstance() method that returns the same elvis.

public class elvis() {
private static final elvis INSTANCE = new elvis();
private elvis() {}
public static Elvis getInstance() {return Instance}
}

Front 9

EJ 4:

How can you enforce noninstantiability?

Back 9

All classes without any constructor will automatically generate a default constructor.

However, if you make one private constructor, no default constructor will be created.

public class UtilityClass{
private UtilityClass() {
throw new AssertationError
}
}

Front 10

EJ 8:

When are the criteria which would make you not want to override equals?

When overriding equals, what is the contract?

Back 10

Not override if:
1. Each instance of the class is inherently unique.
2. You don't care if there is a logical equality test.
3. The superclass's equals is sufficient (example, Set)


1. Reflexive: x.equals(x) is true
2. Symmetric: if x.equals(y) is true, y.equals(x) is true.
3. Transitive: if x.equals(y) is true and y.equals(z) is true then x.equals(z) is true.
4. Consistent: if x.equals(y) is true, then x.equals(y) is always true until x or y is modified.
5. x.equals(null) is false.

Front 11

EJ 9:

When one must always override hashCode?

Back 11

When one is overriding equals.

Because Object's hash returns random numbers, if you run hash twice on an object that is supposedly equal, you are likely to get different two random integers. In otherwords, hash isn't working. So write a hash function that incorporates all the fields used in the equals method.

Front 12

EJ 10:

Why override toString?

Back 12

Makes your class more pleasant to use.

Include in the toString all the interesting information in the object.

Also, provide programming access to all the information contained in the value returned by toString. That way, other programmers don't need to parse through your toString.

Front 13

EJ 12:

When consider implementing comparable?

Back 13

When instances of that class have a natural ordering.

Front 14

EJ 13:

What is the single most important factor that distinguishes well-designed modules?

Back 14

The degree to which the module hides its internal data and other implementation details from other modules. Clearly separates the API from its implementation.

Front 15

EJ 13:

What is the most important reason for using information hiding?

Back 15

It decouples the modules that comprise a system. Modules can be developed in parallel.

Front 16

EJ 13:

What's the rule of thumb for information hiding?

Back 16

Make each member as inaccessible as possible.

Front 17

EJ 14:

If a class is public, what should use rather than public fields?

Back 17

Accessor methods.

Front 18

EJ 15:

What are 5 things you can do to minimize mutability?

Back 18

1, Don't provide mutators.
2. Ensure that the class can't be extended.
3. Make all fields final
4. Make all fields private.
5. Ensure exclusive access to any mutable components.

Front 19

EJ 16:

Why favor composition over inheritance?

Back 19

Inheritance violates encapsulation.

Liskov's substitution principle.

Front 20

EJ 17:

What can you do to design a class for inheritance?

Back 20

Test it by writing subclasses (at least 3).

Write subclasses before you release it.

Constructors must not invoke overrideable methods.

Front 21

EJ 17:

How can you prevent inheritance?

Back 21

way 1:
Declare the class final.


Way 2:
Make all constructors private or package private and add public static factories in place of constructors.

Front 22

Guide to picking correct java collection

Back 22

Are you storing key-value pairs?

* Yes
o Do you need to acces the elements in sorted order?
+ Yes - use NavigableMap
+ No - use Map
* No
o First in first out access?
+ Yes - use Queue
+ No
# Is there a linear ordering of elements?
* Yes - use List
* No
o Are duplicate elements prohibited?
+ Yes - use Set
+ No - use Collection

Front 23

Definition of abstraction (handout)

Back 23

the practice of ignoring details so that one can focus on the key concept. We separate the what gets done from the how it gets down. In computer science, we say we separate the interface from the implementation. A good example is the remote control for a TV. The interface consists of simple buttons to turn the TV on or off and to move to the next higher or lower channel. The implementation of actually changing the channel involves the electronics of RLC tuning circuits. This is mercifully abstracted out so that you don't need a electrical engineering degree to watch TV.

Front 24

Definition of information hiding (handout)

Back 24

the hiding (or abstracting) of the representation of data within an object. This insulates the users of the data from the details of its representation. Changes may be made in the low level details of the representation without requiring changes to all the users of the data. Sometimes this term is used interachgeably with encapsulation.

Front 25

Coupling (handout)

Back 25

the degree of dependency between two program modules such as classes. If two classes are highly coupled then they are highly interdependent and rely on each other. For example, a class for a SinglyLinkedList data structure and its iterator are tightly coupled; the iterator exists only to provided access to the SinglyLinkedList and usually has access to its internal data representation. In general, we would like classes to be loosely coupled so that one class does not have to be concerned with the internal implementation details of another. Changes to the internals of one class do not require changes to the other.

Front 26

Cohesion (handout)

Back 26

this is the opposite of coupling. How well do the components work together to provide a specific functionality? We want individual classes to be highly cohesive but loosely coupled to other classes. There has been considerable research done on measuring the cohesion and coupling in software.We will briefly touch on these and use the Software Metrics tool for measurement (see Tools web link).

Front 27

Four symptoms of rotting design, (Martin article)

Back 27

Rigidity. Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules. When the manager’s fears become so acute that they refuse to allow changes to software,official rigidity sets in.

Fragility. Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix,they fear that the software will break in some unexpected way.

Immobility. Immobility is the inability to reuse software from other projects or from parts of the same project. Software is rewritten instead of reused.

Viscosity. Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high

Front 28

System under test handout. What are the different ways to change implementation objects, for example between an emulator and a database?

Back 28

A. Hardcode
i. comment it in/out, use a member field boolean flag, static initialization block
B. Dependency injection
i. use setter member function, pass as parameter to methods, pass as parameter to constructor
C. Dependency lookup
i. uses text file (.ini)