| Encapsulation vs. implementation [message #97147] |
Fri, 03 October 2003 11:26  |
Eclipse User |
|
|
|
Originally posted by: ThisisFake.Fakeness.xyz
This is a technique I like to use to clean up my code a bit and help hide
methods that should only be internal. Basically I do not like
implementing interfaces on my main class and exposing methods to the
public that are only for the internal architecture so I would do this
class x {
private PropertyChangeListener pcl = new PropertyChangeListener(){
public void PropertyChange(PropertyChangeEvent pce){
x.this.PropertyChange(pce);
}
};
protected void PropertyChange(PropertyChangeEvent pce){
}
}
When I do the above, the PropertChange method gets to be protected instead
of public. All overriding classes still get a change to process that
method, but they do not have to have a public method on them to do it.
Note, this method is not meant to be called from the public anyway.
As opposed to this;
class y implements PropertyChangeListener {
public void PropertyChange(PropertyChangeEvent pce){
}
}
in this case, all subsequent child classes must expose this method to the
public.
For me the first method is better because it lets other developers know
right off the bat that this method is not externally used. It reduces the
number of publicly exposed methods. especially those that do nto really
need to be exposed.
Does anyone see a drawback to this technique? I would like to see GEF use
it within its architecture and as a result expose fewer methods to the
public. Especially considering GEF is a library of sorts, public methods
should represent calls on the library.
Thanks for your opinioin.
CL
|
|
|
| Re: Encapsulation vs. implementation [message #97164 is a reply to message #97147] |
Fri, 03 October 2003 16:15  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
We do this a lot, when appropriate. For example, see SelectionEditPolicy's
selectionListener.
"CL [dnoyeB] Gilbert" <ThisisFake@Fakeness.xyz> wrote in message
news:pan.2003.10.03.15.26.16.937534@Fakeness.xyz...
> This is a technique I like to use to clean up my code a bit and help hide
> methods that should only be internal. Basically I do not like
> implementing interfaces on my main class and exposing methods to the
> public that are only for the internal architecture so I would do this
>
> class x {
> private PropertyChangeListener pcl = new PropertyChangeListener(){
> public void PropertyChange(PropertyChangeEvent pce){
> x.this.PropertyChange(pce);
> }
> };
>
> protected void PropertyChange(PropertyChangeEvent pce){
>
> }
> }
>
> When I do the above, the PropertChange method gets to be protected instead
> of public. All overriding classes still get a change to process that
> method, but they do not have to have a public method on them to do it.
> Note, this method is not meant to be called from the public anyway.
>
> As opposed to this;
>
> class y implements PropertyChangeListener {
> public void PropertyChange(PropertyChangeEvent pce){
>
> }
> }
>
> in this case, all subsequent child classes must expose this method to the
> public.
>
> For me the first method is better because it lets other developers know
> right off the bat that this method is not externally used. It reduces the
> number of publicly exposed methods. especially those that do nto really
> need to be exposed.
>
>
> Does anyone see a drawback to this technique? I would like to see GEF use
> it within its architecture and as a result expose fewer methods to the
> public. Especially considering GEF is a library of sorts, public methods
> should represent calls on the library.
>
>
> Thanks for your opinioin.
>
>
>
> CL
>
|
|
|
| Re: Encapsulation vs. implementation [message #97208 is a reply to message #97164] |
Fri, 03 October 2003 12:53 |
| Eclipse User |
|
|
|
Originally posted by: ThisisFake.Fakeness.xyz
On Fri, 03 Oct 2003 16:15:06 -0400, Randy Hudson wrote:
> We do this a lot, when appropriate. For example, see SelectionEditPolicy's
> selectionListener.
>
Nice, I guess I have been jumping the gun a bit lately. GEF still being
developed so I guess I can't expect it all to be exactly the same at the
same time. On the bright side, I haven't found any bugs :)
CL
|
|
|
Powered by
FUDForum. Page generated in 0.02730 seconds
Home