zmarak ahmad djan

two different points here :
-why the class in the interface ?
- usage ?

point one : notice that the class and the interface definition
depend on each other. if you declare this as two different compilation units
it would be possible but would need to be compiled together
the fact that the class is IN the interface expresses the fact
that the definition of the interfaces need that class.

point two:
- A) write a base class named "NormalProduct" and tax it.
all derived class will derive from this class.

-B) now a 1.5 feature
write a derived Interface IsTaxableSpecial extends IsTaxable
where the method getTaxAgent returns a local subclass of TaxAgent
write a class that derives from "NormalProduct" but implements
IsTaxableSpecial.
you're in for a (happy) surprise (courtesy J2SE 5)

[QB]Encapsulation might mean that you cannot access another object's data at all.

you are right to use "might" :
public class X { private int secret ; public void modifyInstance(X anotherInstance) { anotherInstance.secret = this secret ; } }
this code works perfectly!
though it does not break encapsulation
because encapsulation is NOT dealing with "protecting objects data".

now another example :
public class Account { private double balance ; private double authorizedOverdrawn ; public void withdraw (double amount ) throws AccountOverdrawnException{ //deals with balance in respect with authorizedOverdrawn } public double getBalance() { ..... } public void setBalance(double val) { // BREAKS ENCAPSULATION !!!! }
so encapsulation is more subtle than the use of getters and setters

[QB]Encapsulation might mean that you cannot access another object's data at all.

imprecise assertion:
[code]
public class X {
private int secret ;


}

Originally posted by Tony Morris:
The class needn't be abstract for it to be a member of an interface.
.

absolutely right

the class in the example does not need to be abstract

but in this example there was a pedagogical intent in doing so
I was trying to give some hints on why the class is here
and why it should be here.
designing a class that implements the interface gives some clues

stack overflow

class Demo { private X mandatoryField; private Y optionalField ; public Demo (X arg) { mandatoryField = arg ; } public void setOptionalField(Y arg) { optionalField= arg ; } public void someMethod() { .... if(null == optionalField) { // do not use it // otherwise NullPointerException } } }
[ September 10, 2004: Message edited by: zmarak ahmad djan ]

getSource() considered harmful:
except in rare occasions if you want to use getSource() you have
an architectural problem ..

is this possible? :
MyTextField extends TextField implements ActionListener

therer are also schedulers in java.util.concurrent packages in J2SE5
but wait until next year

java.util.Timer is not costly
(but I have never used it with such a wide gap ... have a try)

public interface IsTaxable { double getValue() ; TaxAgent getTaxAgent() ; public abstract class TaxAgent { // to be extended private double taxRate; protected TaxAgent(double tx) { this.taxRate = tx ; } public double taxMe(IsTaxable itx) { return itx.getValue() * taxRate ; } } }

have fun

zmarak

I've never been a private but I actually *am* a publican

a filed marked transient is not serialiazed by the serialisation mechanism
that serialize the enclosing Object.

in your example you serialize explicitly the field "a"
so it should work that way!
transient is not a sticky marker to object "a" it's something
that is operating when serializing the ENCLOSING object.

code number one will issue an error
Borderlayout is not a package

import static java.awt.BorderLayout.* ; ... ... container.add(component, CENTER); //instead of BorderLayout.CENTER
so it's syntactic sugar
my advice: don't overuse (specifically don't overuse with static methods)

I don't understand what you're after...
a very simple example could help
what tests do you want to generate automagically?

do you want to generate code and dynamically compile it
or use reflection and a program that calls method dynamically?

in the later case a dynamic proxy is for you
(but the generic test code has to be clever )