Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 879
  • Last Modified:

domain classes vs implementation classes/solution space classes

Hi,


I was reading about domain classes vs implementation classes/solution space classes.

What are the practical uses, differences, advantages of each of them.

what is transient behaviour and what is static relation ship between classes represented in uml.
Please advise. Any ideas, resources, sample code highly appreciated. thanks in advance
0
gudii9
Asked:
gudii9
  • 3
  • 2
  • 2
2 Solutions
 
dpearsonCommented:
what is transient behaviour and what is static relation ship between classes

A transient relationship means one that comes and goes.

For example a class like this:

public class MyList {
     private List<Object> m_List ;

     public void add(Object obj) { m_List.add(obj) ; }
     public Object get(int index) { return m_List.get(index) ; }
}

could be used to store a list of many different types of objects (e.g. a list of Strings or a list of Integers).  So it's relationship to the objects being stored is transitory - it doesn't always store Strings or Integers.

That's very different from a class like this:
public class MasterList {
       private MyList m_MyList ;
}

where the MasterList has a static relationship to the MyList class.  It will always store a MyList instance.

Does that help?

Doug
0
 
David L. HansenProgrammer AnalystCommented:
If you are fairly new to Object Oriented Programming please take a look at this article.  I'd love some feedback, if you feel so inclined to leave a comment.

Beyond that, I can give you my take on the different types of objects in question and how to use them.  First of all, recall that in database design and OO design, we try and mimic the real world (ie. We don't want to have a class or a table named "Creatures" where we place information about all of our employees, customers, and pets).  We want to give each discrete thing its own table and object.  Now that can be taken too far, remember simplicity is the goal, break down what needs to be broken down and make sure you're planning for the future (ie. we don't have customers yet, but we will...so create those tables and object for them).  That being said, sometimes you have system specific needs that need to be managed that don't exist in the real world.  For example, your program may use a dozen log files which need to be managed.  In this case, you might make a class whose job it is to manage those logs.  I currently have a class which takes in error messages and tracks them over time - that's not part of specific real-world business object like "Customers" however, it serves an important role.  A Customer class is a domain class and the log-manager is an implementation class (used when the program is implemented just to maintain the program).
0
 
gudii9Author Commented:

public class MyList {
     private List<Object> m_List ;

     public void add(Object obj) { m_List.add(obj) ; }
     public Object get(int index) { return m_List.get(index) ; }
}

could be used to store a list of many different types of objects (e.g. a list of Strings or a list of Integers).  So it's relationship to the objects being stored is transitory - it doesn't always store Strings or Integers.

That's very different from a class like this:
public class MasterList {
       private MyList m_MyList ;
}

where the MasterList has a static relationship to the MyList class.  It will always store a MyList instance.

can you please elaborate on this. I am not clear on this
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
David L. HansenProgrammer AnalystCommented:
What you posted is true.  The two container classes do just as you describe.  One can only receive a specific type and the other doesn't care which type of objects go into it.  That really has nothing to do with your original question (as I see it) regarding domain classes and implementation classes (except that a collection object is built from what you might call an Implementation Class).

The question of "Domain" vs. "Implementation" Classes, deal more with your own personal categorization of your custom class.  If you build a class of "Customer" that is pretty much a clear business "domain" class.  If you build one called "Website_Launcher" that doesn't really have a lot to do with the business domain.  It's all about implementing the app.
0
 
gudii9Author Commented:
I have gone through tutorial. It is interesting.

If you build a class of "Customer" that is pretty much a clear business "domain" class.  If you build one called "Website_Launcher" that doesn't really have a lot to do with the business domain.  It's all about implementing the app.

What is the relation between customer and "Website_Launcher".
I have not understood difference  between business domain and implementing app.
Please advise
0
 
David L. HansenProgrammer AnalystCommented:
There is no inherit relation between domain and implementation classes.  Here you are in the "art" of coding.  You could just as easily say "I have big classes and small classes."  Nobody, least of which the compiler or IDE, is going to say you are wrong.  There are no rules governing such classes; they are categorized by you, using your own labeling methods (perhaps you don't even write it down).  It might be more instructive to say "these are the classes I like and these are the ones I don't."  Again, nobody can say you are wrong.  Domain and Implementation classes are just such classes (although most people would agree that a "Customer" class is more domain oriented than implementation oriented).  Please read my article, it speaks to some of your frustrations.
0
 
dpearsonCommented:
What is the relation between customer and "Website_Launcher".

A simple way to separate these out in your mind is that customers exist in the real world.  So they are good candidates for being in your domain model.  Other examples - items, inventories, prices etc.  They all have real-world parallels.

Website_Launchers do not exist in the real world.  So they are less likely to be part of the domain model.  Other examples - monitoring tools, loggers, connection pools.  They have no real world equivalents and so are less nature fits for a domain model.

Hope that helps,

Doug
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 3
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now