Aside from method/field visibility, are there any big issues with writing a class that extends something from another package?
Thanks.
-
Any problems with extending a class from another package? (2 messages)
- Posted by: scott powell
- Posted on: October 05 2004 13:26 EDT
Threaded Messages (2)
- Any problems with extending a class from another package? by Stephane Vaucher on October 05 2004 15:44 EDT
- Extendinging classes from other packages by Sven Helmberger on October 05 2004 17:26 EDT
-
Any problems with extending a class from another package?[ Go to top ]
- Posted by: Stephane Vaucher
- Posted on: October 05 2004 15:44 EDT
- in response to scott powell
Nope, the only issue is the organisation of your code. I regularly separate type from implementation by using different type and impl packages. Never encountered problems with this approach. Furthermore, it's relatively common if you use a 3rd party frameworks.
HTH
sv -
Extendinging classes from other packages[ Go to top ]
- Posted by: Sven Helmberger
- Posted on: October 05 2004 17:26 EDT
- in response to scott powell
Classes which are not defined public can't be accessed from outside the package.
This can be an issue if you would have to override a class out of a library where the libraries' author did not think of that scenario.
You can use packages to control class access in your own code, too. If you know that a certain class is and should only be used by another class in the same package you can define it non-public
package foo;
class Bar
{
...
}
to forbid access from another package.