Re: Newbie: ArrayList.indexOf help
On 23/08/2008 05:36, Kurt allegedly wrote:
So this gets me to thinking about the appropriate getter/setter/etc
methods that an
an object with an ArrayList of other objects should provide publicly.
Don't think of it as "an Object with an ArrayList". That's the wrong way
down. Think about what the Object "is", what functionality it represents
or models. Then think about what "behaviour", what "form" it should have
and define access from outside (id est: its public fields, methods and
c'tors) accordingly.
The implementation of the Object's functionality is only the last step
in this process of thought, not the first. It should never matter squat
whether an Object uses an ArrayList internally or a fubar or whatever.
Instead, it might provide a *List*, or implement the *List* interface.
Note the difference. java.util.List is the interface defining the
functionality. ArrayList is the specific implementation. The specific
implementation shouldn't matter, generally.
I struggle with the encapsulation of objects
Indeed you do. Let's have a closer look at your code, as it provides
almost a textbook example.
myCust.add_aCenters();
myCust.numCenters++;
myCust._aCenters.get(myCust.numCenters-1).set_sCenterId("PHX");
myCust._aCenters.get(myCust.numCenters-1).set_sStartDate("2008-01-01");
myCust._aCenters.get(myCust.numCenters-1).set_sEndDate("2100-12-31");
This is all terribly wrong. Your goal is to add a Center to a Customer's
set of Centers. But to achieve that, you go poke, from outside, in the
Customer's innards. To achieve that you had to:
define the add_aCenters() method,
make the numCenters field accessible,
make the _aCenters field accessible.
I won't go too much in depth about the bugs in this code. I suspect that
numCenters being static is one. Also, you should have a look at the Java
coding conventions:
<http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html>
and especially naming conventions:
<http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367>
But let's focus on the design instead. The block of code above should be
reduced to a one-liner. This is how:
Firstly, the Center class:
<code>
class Center {
private String centerId;
private String startDate;
private String endDate;
public Center(String centerid, String startdate, String enddate) {
centerId = centerid;
startDate = startdate;
endDate = enddate;
}
public String getCenterId(){ return centerId; }
public String getStartDate(){ return startDate; }
public String getEndDate(){ return endDate; }
public String toString(){
return String.format(
"Center[id=%s,startDate=%s,endDate=%s]",
getCenterId(),
getStartDate(),
getEndDate()
);
}
}
</code>
Note the toString() method for a nice output. Note that this way, the
Center Object is immutable, as I assume (maybe wrongly) that it won't
need to be modified once created. Note, finally, that dates may be
represented best with a java.util.Date Object, and not a String.
Secondly, the Customer class:
<code>
class Customer {
private String customerName;
List<Center> centers;
public Customer(String name){
customerName = name;
centers = new ArrayList<Center>();
}
public String getCustomerName(){ return customerName; }
public List<Center> getCenters(){ return centers; }
public boolean addCenter(Center c){
return centers.add(c);
}
public boolean addCenter(String id, String start, String end){
return addCenter( new Center(id, start, end) );
}
}
</code>
Note how the instance field "centers" is defined as a List, and not as
an ArrayList. It *is* an ArrayList in the end, but that doesn't matter
to the outside view -- that it's a List matters. On that subject, it may
be enough to define it as a Set or a Collection, and not as a List.
With all this, we can reduce the part of the main()'s code I quoted
above to:
<code>
myCust.addCenter("PHX", "2008-01-01", "2100-12-31");
</code>
HTH.
--
DF.