Jörn Nettingsmeier wrote:
me again... :(
Andreas Hartmann wrote:
Jörn Nettingsmeier wrote:
Andreas Hartmann wrote:
This sounds reasonable, and at the first glance your patch looks
very good. Maybe it would make sense to make
AbstractChangePassword.getUser()
abstract. ChangePassword.getUser() would just return the currently
logged-in user, and AdminChangePassword() would return the user
determined by the userId parameter. WDYT?
i tried it, but then it seemed better to have a variable
private User user
that defaults to null in AbstractChangePassword, and to set it to the
current user in the constuctor of ChangePassword. otherwise the code
to determine the current user would be called many times...
That can be solved by lazy loading. But communication between classes
should happen over methods, not fields - even in class hierarchies.
i don't understand... does my code (see attachment) violate this?
I wouldn't call it "violate", it's rather a personal preference.
I prefer to call a getter when necessary (A) to a setter which is
invoked in any case (B):
(A)
class Super {
protected abstract User getUser();
public void process() {
doSomethingWith( getUser() );
}
}
class Sub {
private User user;
protected User getUser() {
// lazy load
if (this.user == null) {
this.user = ...
}
return this.user;
}
}
(B)
class Super {
private User user;
protected void init() {
...
(expect that subclass sets the user -> no explicit contract)
}
public void process() {
doSomethingWith( this.user );
}
}
class Sub {
protected void init() {
setUser(...);
}
}
I'll reply to the rest of the mail separately.
HTH,
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
