(der threadtitel ist eventuell nicht sehr aussagekräftig, aber mir fällt kein besserer ein.)
ich habe in meinem programm etliche packages. zum beispiel gibt es ein package meinprog für die logik, dann meinprog.gui für die userinterface klassen und dann noch unterpackages wie meinprog.gui.something. nun kann es zum beispiel sein, dass es in einer klasse im meinprog-package eine methode à la createNewSomething(String title, Object value) gibt. title und value dürfen nicht null sein. die methode deligiert das ganze weiter an eine klasse aus meinprog.ui, welche dieselbe Methode anbietet. schließlich gibts in meinprog.ui.something (neben vielen anderen Klassen) eine Klasse Something mit dem entsprechenden Konstruktor oder eine SomethingFactory oder sowas.
worauf ich hinaus will: ich habe hier 3 mal das title argument und 3 mal das value argument. ich habe in der doku der methoden/konstruktoren erwähnt, dass die werte nicht null sein dürfen. meine frage lautet nun wo/wie/wie oft ich die null-überprüfung machen soll?
derzeit habe ich in jeder dieser methoden zu beginn eine zeile à la
nun bin ich gerade dabei, einige teile meines codes auf assertions umzustellen. es gilt aber der grundsatz, dass man die argumentüberprüfung von public methoden nicht mit assertions machen soll (bei private/protected aber sehr wohl). das leuchtet mir ein. hier steckt wohl die intention dahinter, dass clients aussagekräftige fehlermeldungen bekommen sollen, wenn sie falsche argumente übergeben. bei mir ist es aber so, dass zb das subpackage something zwar aus meiner sicht durchaus sinnvollerweise ein eigenes package ist, aber ich eigentlich nicht davon ausgehe, dass es jemals ohne meinprog.ui sinn machen wird. für mich ist also quasi das ganze package "protected". viele methoden muss ich aufgrund der unterschiedlichen packages aber nun public machen.
soll ich in solchen fällen nun weiterhin mehrmals die checks ausführen? soll ich gegen die regel mit assertions arbeiten? oder soll ich in einigen methoden ganz auf die checks verzichten?
mein hauptproblem sind die subpackages bzw. wie ich sie verwende (eventuell liegt auch hier der fehler). ich habe zb ein package mit 20 files. dann sehe ich, dass 10 klassen eigentlich nur für eine 11. klasse da sind (--> zb Klasse Something) --> neues sub-package something. macht aus meiner sicht absolut sinn, ist zb auch viel übersichtlicher. durch das neue package entstehen aber eben public methoden, die vorher keine waren, was zur folge hat, dass ich zb laut den assertion-conventionen in diesen public methoden ausführliche fehlerüberprüfung machen muss, entsprechende doku, etc.
war es nun von vorneherein ein fehler ein "subpackage" zu machen? warum gibt es eigentlich keine "echten" "subpackages", wo dieses sichtbarkeits problem nicht auftritt? (wäre das nicht durchaus nützlich?)
eine weitere frage: soll ich auf null überprüfen, wenn java ohnehin ein paar zeilen später eine nullpointer exception werfen würde? ich persönlich finde es schöner und von daher mache ich es auch (besonders weils durch codeänderungen ja schnell mal vorkommen kann, dass die nullpointerexception plötzlich erst viel später geworfen wird). allerdings braucht selbst ne null-überprüfung etwas zeit und auch wenn die in meinem fall selbst in schleifen kein performance-problem darstellen sollte, so wären nach meinem verständnis dann doch assertions besser geeignet. aber die darf ich laut konvention ja nicht verwenden...
hab ich hier irgendnen denkfehler?
ich habe in meinem programm etliche packages. zum beispiel gibt es ein package meinprog für die logik, dann meinprog.gui für die userinterface klassen und dann noch unterpackages wie meinprog.gui.something. nun kann es zum beispiel sein, dass es in einer klasse im meinprog-package eine methode à la createNewSomething(String title, Object value) gibt. title und value dürfen nicht null sein. die methode deligiert das ganze weiter an eine klasse aus meinprog.ui, welche dieselbe Methode anbietet. schließlich gibts in meinprog.ui.something (neben vielen anderen Klassen) eine Klasse Something mit dem entsprechenden Konstruktor oder eine SomethingFactory oder sowas.
worauf ich hinaus will: ich habe hier 3 mal das title argument und 3 mal das value argument. ich habe in der doku der methoden/konstruktoren erwähnt, dass die werte nicht null sein dürfen. meine frage lautet nun wo/wie/wie oft ich die null-überprüfung machen soll?
derzeit habe ich in jeder dieser methoden zu beginn eine zeile à la
Code:
if (value == null) throw new IllegalArgumentException(...);nun bin ich gerade dabei, einige teile meines codes auf assertions umzustellen. es gilt aber der grundsatz, dass man die argumentüberprüfung von public methoden nicht mit assertions machen soll (bei private/protected aber sehr wohl). das leuchtet mir ein. hier steckt wohl die intention dahinter, dass clients aussagekräftige fehlermeldungen bekommen sollen, wenn sie falsche argumente übergeben. bei mir ist es aber so, dass zb das subpackage something zwar aus meiner sicht durchaus sinnvollerweise ein eigenes package ist, aber ich eigentlich nicht davon ausgehe, dass es jemals ohne meinprog.ui sinn machen wird. für mich ist also quasi das ganze package "protected". viele methoden muss ich aufgrund der unterschiedlichen packages aber nun public machen.
soll ich in solchen fällen nun weiterhin mehrmals die checks ausführen? soll ich gegen die regel mit assertions arbeiten? oder soll ich in einigen methoden ganz auf die checks verzichten?
mein hauptproblem sind die subpackages bzw. wie ich sie verwende (eventuell liegt auch hier der fehler). ich habe zb ein package mit 20 files. dann sehe ich, dass 10 klassen eigentlich nur für eine 11. klasse da sind (--> zb Klasse Something) --> neues sub-package something. macht aus meiner sicht absolut sinn, ist zb auch viel übersichtlicher. durch das neue package entstehen aber eben public methoden, die vorher keine waren, was zur folge hat, dass ich zb laut den assertion-conventionen in diesen public methoden ausführliche fehlerüberprüfung machen muss, entsprechende doku, etc.
war es nun von vorneherein ein fehler ein "subpackage" zu machen? warum gibt es eigentlich keine "echten" "subpackages", wo dieses sichtbarkeits problem nicht auftritt? (wäre das nicht durchaus nützlich?)
eine weitere frage: soll ich auf null überprüfen, wenn java ohnehin ein paar zeilen später eine nullpointer exception werfen würde? ich persönlich finde es schöner und von daher mache ich es auch (besonders weils durch codeänderungen ja schnell mal vorkommen kann, dass die nullpointerexception plötzlich erst viel später geworfen wird). allerdings braucht selbst ne null-überprüfung etwas zeit und auch wenn die in meinem fall selbst in schleifen kein performance-problem darstellen sollte, so wären nach meinem verständnis dann doch assertions besser geeignet. aber die darf ich laut konvention ja nicht verwenden...
hab ich hier irgendnen denkfehler?
