Re: private vs. protected access
+1 to Soren's proposal, as long as it is done intelligently :-) > I propose the following change(s). > Mainly for the supplied matchers and mailets ... > instance variables and methods ... > promote them to protected access. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
Søren Hilmer wrote: > > I propose the following change(s). > > Mainly for the supplied matchers and mailets I would like to > reconsider having > instance variables and methods being of private access and > move promote them > to protected access. Lets look at the intent of this change which is (please correct me if I am wrong) to facilitate specialization by subclassing. This requires that classes follow a few simple rules: 1) Only expose as public methods that must be accessible to external classes and are guaranteed to be maintained throughout the class' development lifecycle. Such methods should ideally be defined in an interface. 2) Only make private methods which should never be exposed to subclasses, such as required constructors which only partially establish an instance's state, basic getters for lazily initialized variables, etc. 3) The remaining methods should be made protected. 4) Public and protected methods should be sufficiently granular to enable specialization of a sole behavior. The specializing method should not need to duplicate code in the superclass method. (If it does, refactor!) 5) All variables should be private and self-encapsulating, ie: access both within and without the class should be via getter and setter methods. Of the above, I would have thought only (5) is particularly contentious. Martin Fowler covers this in "Refactoring : improving the design of existing code", p171. Like Martin, I am willing to live with direct access within the defining class. Direct access from outside of the defining class should never be permitted as it breaks encapsulation and increases coupling. The specializing class should not need to know how a value is maintained and should simply invoke the getter/setter methods. These methods may access a variable directly, perform lazy initialization or delegate off to another class. The specializing class should neither know or care. So Søren, I am basically with you on making most methods protected but very much against making variables protected. Rather, we should make them private and add getter/setter methods! -- Steve - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
Steve Brewin wrote: > and add getter/setter methods! should read... and add protected getter/setter methods! -- Steve - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private vs. protected access
No, I believe we are exactly on the same wavelength, I would not really make the instance variables protected, just supply getters/setters, which amounts to the same functional wise, I guess I was not clear on that. --Søren On Wednesday 05 November 2003 11:05, you wrote: >Søren Hilmer wrote: >> >> I propose the following change(s). >> >> Mainly for the supplied matchers and mailets I would like to >> reconsider having >> instance variables and methods being of private access and >> move promote them >> to protected access. > >Lets look at the intent of this change which is (please correct me if I am >wrong) to facilitate specialization by subclassing. This requires that >classes follow a few simple rules: > >1) Only expose as public methods that must be accessible to external classes >and are guaranteed to be maintained throughout the class' development >lifecycle. Such methods should ideally be defined in an interface. > >2) Only make private methods which should never be exposed to subclasses, >such as required constructors which only partially establish an instance's >state, basic getters for lazily initialized variables, etc. > >3) The remaining methods should be made protected. > >4) Public and protected methods should be sufficiently granular to enable >specialization of a sole behavior. The specializing method should not need >to duplicate code in the superclass method. (If it does, refactor!) > >5) All variables should be private and self-encapsulating, ie: access both >within and without the class should be via getter and setter methods. > >Of the above, I would have thought only (5) is particularly contentious. >Martin Fowler covers this in "Refactoring : improving the design of existing >code", p171. > >Like Martin, I am willing to live with direct access within the defining >class. > >Direct access from outside of the defining class should never be permitted >as it breaks encapsulation and increases coupling. The specializing class >should not need to know how a value is maintained and should simply invoke >the getter/setter methods. These methods may access a variable directly, >perform lazy initialization or delegate off to another class. The >specializing class should neither know or care. > >So Søren, I am basically with you on making most methods protected but very >much against making variables protected. Rather, we should make them private >and add getter/setter methods! > >-- Steve > -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
Søren Hilmer wrote:
>
>
> No, I believe we are exactly on the same wavelength, I would
> not really make
> the instance variables protected, just supply
> getters/setters, which amounts
> to the same functional wise, I guess I was not clear on that.
Excellent!
If you happen to use Eclipse, its refactoring tool includes self
encapsulation. This may save some time.
Also, while making this change it might be worth considering adding a prefix
to the variable names, 'field' is typical. So...
private String name;
protected String getName()
{
return this.name;
}
protected void setName(String name)
{
this.name = name;
}
becomes...
private String fieldName;
protected String getName()
{
return name;
}
protected void setName(String name)
{
fieldName = name;
}
This has two advantages. Firstly, it avoids mistaken direct access to the
variable and secondly it makes the class JavaBean compatible. Again, Eclipse
helps out with the rename refactoring tool.
Not a big deal, but if we are tidying up variable access we may as well do
everything that needs to be done in one pass.
-- Steve
- - - - - - - - - - - - - - - - - -
This private and confidential e-mail has been sent to you by Synergy Systems Limited.
It may not represent the views of Synergy Systems Limited.
If you are not the intended recipient of this e-mail and have received it in error,
please notify the sender by replying with "received in error" as the subject and then
delete it from your mailbox.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
We have to support what we release as a public interface. In some cases, the code as it exists may not be what we want to support, and that is another reason for why it isn't exposed. In the specific case of the RemoteDelivery mailet, rather than having to track changes, if/when he submits his change, it could be incorporated into the next build. I am not saying that we should not expose some things that aren't, but let's be judicious about it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
+1 Mainly for the supplied matchers and mailets, adding protected getter/setter methods. This is a very sound and clean initiative. We should perhaps also write a "mailet/matcher coding best practices" wiki page. "Also, while making this change it might be worth considering adding a prefix to the variable names, 'field' is typical. So... ... This has two advantages. Firstly, it avoids mistaken direct access to the variable and secondly it makes the class JavaBean compatible..." +1 for the first reason, but I think that it is JavaBean compatible even without the renaming. Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private vs. protected access
Vincenzo Gianferrari Pini wrote: +1 > Mainly for the supplied matchers and mailets, adding protected getter/setter methods. +1 This is a very sound and clean initiative. We should perhaps also write a "mailet/matcher coding best practices" wiki page. +1 "Also, while making this change it might be worth considering adding a prefix to the variable names, 'field' is typical. So... ... This has two advantages. Firstly, it avoids mistaken direct access to the variable and secondly it makes the class JavaBean compatible..." +1 for the first reason, but I think that it is JavaBean compatible even without the renaming. +0. I've seen this.name = name cause problems, so whatever workaround makes the coder doing it happy. Dunno if it's worth refactoring existing stuff. -- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private vs. protected access
On Wednesday 05 November 2003 16:33, Noel J. Bergman wrote: > We have to support what we release as a public interface. In some cases, > the code as it exists may not be what we want to support, and that is > another reason for why it isn't exposed. I can see your point on what we expose we need to support. But IMO people messing at this level needs to have a certain level of competance anyway, eg. they need to have understood the inner workings of the mailet/matcher they are extending. This initiative is just to lend those developers a helping hand. > > In the specific case of the RemoteDelivery mailet, rather than having to > track changes, if/when he submits his change, it could be incorporated into > the next build. I was only using the specific case as an example, and I agree that Andreas's DSN solution should make it into the next build. My only concern is that we get yet another processor with special meaning, besides root and error. I suggest that we make the processor name a parameter to RemoteDelivery. dsn > > I am not saying that we should not expose some things that aren't, but > let's be judicious about it. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private vs. protected access
"Also, while making this change it might be worth considering adding a
prefix
to the variable names, 'field' is typical. So...
...
This has two advantages. Firstly, it avoids mistaken direct access to the
variable and secondly it makes the class JavaBean compatible..."
+1 for the first reason, but I think that it is JavaBean compatible
even without the renaming.
+0. I've seen this.name = name cause problems, so whatever workaround
makes the coder doing it happy. Dunno if it's worth refactoring
existing stuff.
What kind of problems?
The refactoring tool I'm using (eclipse) can generate getters and
setters, but it names them by adding a "get" and "set" prefix.
Generating Getter and Setter for
private String name;
produces the following:
public String getName() {
return name;
}
public void setName(String string) {
name = string;
}
So if you add "field" to these private variables, the automatic
getter and setter generation won't work.
So IMHO it's a bad idea.
Steen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: private vs. protected access
> So if you add "field" to these private variables, the automatic > getter and setter generation won't work. Actually eclipse allows you to set prefixes and suffixes for internal variables, these are then stripped correctly when you "encapsulate variable" or "generate getters and setters". d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private vs. protected access
Danny Angus wrote: So if you add "field" to these private variables, the automatic getter and setter generation won't work. Actually eclipse allows you to set prefixes and suffixes for internal variables, these are then stripped correctly when you "encapsulate variable" or "generate getters and setters". d. Wow, I wasn't aware of that. I just tried it and it's working beautifully. Eclipse keeps on amazing me. With this new knowledge I too think it's a good idea. Steen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private vs. protected access
Steen Jansdal wrote: +0. I've seen this.name = name cause problems, so whatever workaround makes the coder doing it happy. Dunno if it's worth refactoring existing stuff. What kind of problems? The setter used this.name = name; and then someone changed the name in the method signature while updating for JavaDocs. A simple mistake that the compiler didn't catch. -- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
Steen Jansdal wrote: > > So if you add "field" to these private variables, the automatic > getter and setter generation won't work. > > So IMHO it's a bad idea. Actually, Eclipse handles this just fine. But the issue is whether the pattern should be followed, not if a particular tool, which not everyone uses, helps code it. -- Steve - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
> Actually, Eclipse handles this just fine. But the issue is whether the > pattern should be followed, not if a particular tool, which not everyone > uses, helps code it. +1. Quite. FWIW I'm in favour of encapsulation but the accessors should be protected. I also think that using a prefix of "field" is ugly and unnecessary why do we want them to be beans? In the meantime I'd favour underscore, so instead of fieldServerName we would have _serverName which is easier on the eye. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
Danny Angus wrote: > FWIW I'm in favour of encapsulation but the accessors should > be protected. Absolutely, unless the public interface requires otherwise. > I also think that using a prefix of "field" is ugly and unnecessary > why do we want them to be beans? > underscore, so > instead of fieldServerName we would have _serverName which is > easier on the > eye. As with many things, beauty is in the eye of the beholder. I think that all we need to say is that a java-legal prefix should be used and not get hung up on what it actually is. I wish I hadn't mentioned beans, especially as a bean requires the accessor methods to be public and we are mainly discussing protected accessors here. -- Steve - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
Søren Hilmer wrote: > On Wednesday 05 November 2003 16:33, Noel J. Bergman wrote: > > We have to support what we release as a public interface. > > In some cases, the code as it exists may not be what we > > want to support, and that is another reason for why it > > isn't exposed. > I can see your point on what we expose we need to support. > But IMO people messing at this level needs to have a certain level of > competance anyway, eg. they need to have understood the inner workings > of the mailet/matcher they are extending. This initiative is just to > lend those developers a helping hand. Exposing internals, as opposed to behavior, is not necessarily giving anyone a helping hand. I'm just saying to be careful, not rather than do this by rote. Considering that this is Open Source, I would rather have someone come to us and point out where we should expose something, than expose too much and be backed into a corner when it comes to changing how something internal is implemented. > I agree that Andreas's DSN solution should make it into > the next build. My only concern is that we get yet > another processor with special meaning, besides root and > error. I suggest that we make the processor name a > parameter to RemoteDelivery. > dsn I absolutely agree. Isnt' that what we've been discussing? I'm almost certain that I mentioned that in one of my e-mails. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
Noel J. Bergman wrote: > Søren Hilmer wrote: > > I agree that Andreas's DSN solution should make it into > > the next build. My only concern is that we get yet > > another processor with special meaning, besides root and > > error. I suggest that we make the processor name a > > parameter to RemoteDelivery. > > > dsn > > I absolutely agree. Isnt' that what we've been discussing? > I'm almost > certain that I mentioned that in one of my e-mails. > > --- Noel Yes you mentioned this. An I'll implement it as a parameter before I submit the Mailet and a Patch for RemoteDelivery. But be patient, I'm very busy with other things at the moment. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
