SE251:Lecture Debriefing

Lecture Debriefing

Here is your opportunity to catch up on anything you didn't quite get during a particular lecture/Friday session, or you didn't get a chance to ask at the time. It's also the lecturers' opportunity to clarify any points they've made in the lectures/Friday sessions.

Now, to make this page purposeful, please only ask questions specifically pertaining to what the lecturers said during the lectures. Thus, it's suggested that you take notes during the lecture regarding any unclear points so you can post them here.

I didn't realise this when I created this, but there's a similar excellent page made by David for Richard's lectures.

(31 March & 1st April) OOP Revision

Any questions? Comments?

(4 April) Assignment 1 Post-mortem

A few new handy Java constructs were mentioned during the session: enums and the for-each mechanism.

Enums

Enum's were introduced in Java 1.5 to provide a type-safe alternative to keeping integer constants. For example, in the BankAccount assignment, the class Transaction has an integer field (instance variable) called transactionType, which can have three possible values: the integer constants DEPOSIT, WITHDRAWAL and INTEREST. Now you may realise this is inherently dangerous, as it would be easy to assign a bogus value to transactionType. For example:

transactions.add(new Transaction(4214788,amount,this)); //assuming transactions is a Vector

Also we could accidentally change the values of one of the constants to be equal to some other, for example:

public static final int DEPOSIT = 10;
public static final int WITHDRAWAL = 10; //woops!
public static final int INTEREST = 12;
private int transactionType;

You can imagine how this would affect withdraw() for savings account, right?

So instead what we could do is introduce a new Enum type called, say, TransactionType, which can have the values of either DEPOSIT, WITHDRAWAL or INTEREST. Like this:

public static enum TransactionType {DEPOSIT, WITHDRAWAL, INTEREST};
private TransactionType transactionType;

Now our field transactionType is no longer of type int but instead the new TransactionType. The only possible values it could have are TransactionType.DEPOSIT, TransactionType.WITHDRAWAL and TransactionType.INTEREST. Thus it would be impossible to provide a bogus type as the compiler would simply not allow anything as long as it's not one of these three. So now we can modify Transaction class's constructor and type() method to take in and return, respectively, a TransactionType instead of int. Like this;

public Transaction( TransactionType type, Money amount, BankAccount account ) {
   this.transactionType = type;
   ... //etc
}
public TransactionType type() {
   return transactionType;
}

Correspondingly, we modify any callers of Transaction class's constructor and type() method to pass in and retrieve, respectively, a TransactionType value. For example:

transactions.add(new Transaction(TransactionType.WITHDRAWAL,amount,this));

There's actually so much more you can do with Enums. Try looking further here.

The for-each construct

The for-each construct is the mechanism that allows you to do this:

String[] words = {"hi","my","name","is","not","to","be","spoken"};
for (String word : words) {
   System.out.println(word);
}

It's essentially a cute version of our classic for loop:

for (int i = 0; i < words.length; i ++) {
   String word = words[i];
   System.out.println(word);
}

This not only applies to arrays but also to any types that implement the Iterable interface. And it happens that all Collection classes, which include Vector, implement this Iterable interface. I cover all this stuff in April 8th's lecture.

(7 April) Interfaces, Lists and Generics essentials

[Insert your questions/comments here]

(8 April) Exploring the Java Collections Framework

A very minor follow-up to slide 12: I mentioned a shorthand alternative to the original Money's compareTo():

return this.cents - other.cents;

Although concise, this actually is not 100% safe if for instance this.cents is a large positive integer and other.cents is a large negative integer. As you may be aware from COMPSYS 201, subtracting between such two integers could result in an integer overflow thereby producing an unexpected result. This won't be a problem if we enforce a constraint that cents can't be negative, but it's always good to be on the safe side.