Saturday, June 6, 2009

The Summer Project 2009, Part 5: a Data Model and a Screenshot

Writing code at last. First, we implement the pieces discussed in part 3. With our design in hand it's a fairly mechanical process, but already there are details to be filled in. I chose for now to go with simple things that would get me started but that may need to change later. For instance, here's the Portfolio class so far:


import java.util.*;

public class Portfolio{
public Portfolio(){
accountList = new ArrayList<account>();
categoryList = new ArrayList<string>();
}

public void addAccount(
Account theAccount
){
accountList.add(theAccount);
}

public ArrayList<account> getAccounts(){
return(accountList);
}

public Account getAccount(String accountName){
Account result = null;
for (Account anAccount : accountList){
if (accountName.equals(anAccount.getName())){
result = anAccount;
break;
}//if
}//for
return(result);
}

public void addCategory(
String theCategory
){
categoryList.add(theCategory);
}

public ArrayList<string> getCategories(){
return(categoryList);
}

private ArrayList<account> accountList;
private ArrayList<string> categoryList;
}


I'm representing the categories as strings (a simple, liner group of characters) rather than giving them their own class. Since the categories don't have any attribute other than their name, it seems OK for now, but it does have some implications. Without giving them some level of existence beyond just the text of their name, the rename operation becomes meaningless. Changing the contents of a string creates a new string, but changing the name of a category doesn't create a new category. It's a good example of the trade-off between complexity and functionality. Simple code is always better, except when it fails to deliver a needed capability. Whether this particular choice becomes a problem will depend on how often we need to rename categories.

This Portfolio object and the collection of objects it contains form the underlying representation of the program's data. It is, in theory, everything EAR needs to keep track of. In programming parlance, it's the data model. And while the data model is the core of the code, it's not the whole story. We still need a way to show the data to the user, and a way for the user to manipulate it. We need a User Interface, or UI for short.*

The skill of making a good user interface goes beyond what it takes to write good code. Once you bring in other people into the equation, you get into the realms of design, usability, and aesthetics. Programmers, being programmers, generally tend toward making legendarily bad user interfaces. However, I'm all we've got for this project, so we'll just have to see how it goes. I tend to start off with a couple of pencil sketches debating how to organize things before I dive in, and EAR is no different. But before we can even get to the main program, we have to decide what actually happens when the program is run. It seems to me we have to do one of three things when the program starts (not counting run in fear):
This piece is actually fairly easy to do. Java provides a built-in mechanism for asking a question with three possible responses. It's just a custom version of the yes/no/cancel dialog you've probably seen before. As always, there are some subtleties, such as making sure that the option to open the last portfolio used is selected when the program runs so you can just hit the space bar or enter to get on with things. Unfortunately, not all of these buttons are going to work right away. We haven't actually thought about saving and loading data yet, and we won't for a while. So for now, we'll have to stick with the third option. Next time, we'll start in on the main UI so we can have something to display when that third option is chosen.

* Formally, the data Model is joined by a Controller and any number of Views. These pieces respectively provide representation, manipulation, and presentation of data. They aren't necessarily separated in a program's code, but they can be, and it often makes for a better program. In practice, this pattern gets used often enough to have its own acronym: MVC for Model-View-Controller. Naturally, I will be taking the lazy approach by combining the controller and the views for EAR in the User Interface.

No comments: