design - Analogy between Account class and java.io.File -
i designing expensemanager application , came across design/refactoring decision.
account domain object (immutable) looks this:
public class account { private long accountid; private string accountname; //getters //static nested builder instantiate in immutable fashion }
it nothing value object (not domain object :( ) earlier had deisgned (and implemented) accountmanager class managed account creation, edition, deletion, etc.
public class accountmanager { public createaccount(account account) { //impl } //similarly edit, delete methods }
but when read this article, got me thinking.
the analogy
java.io.file class has method createnewfile() creates file in underlying file system. file class uses filesystem object this. similarly, thought account class should have createnewaccount() method , use accountmanager internally.
which better design decision? using accountmanager account operations or giving account class ability create, edit , delete?
you describe account object thus:
it nothing value object
and don't think that's unreasonable. if above holds true, separate construction/instantiation , create accountfactory
or accountmanager
(which create subclasses if need be, keep track of references etc.).
as aside, wouldn't take standard java classes being great example follow in terms of software design. file
class has been reworked java 7 , date
/calendar
classes well-known nightmare. learn them, don't follow them religiously!
Comments
Post a Comment