----- Original Message -----

From: jasongorman_uk

To: parlezuml@yahoogroups.com

Sent: Monday, November 06, 2006 10:22 AM

Subject: [parlezuml] Re: To Jason Gorman--Interface Seperation

--- In parlezuml@yahoogroups.com, "saintthomson" <saintthomson@...> wrote:
>
> Hi ,
> i have gone through the tutorial you have publiched ,
>
> I do have a doubt in the interface seperation tutorial, you have
> given an example
>
> in the customer class some clients need to know the id only and the
> others need to only convert the customer class into XML, so you have
> created two interface for IBusiness interface for ID and IXML for
> getting the XML
>
> So we have implemented the two in the customer class..
>
>
> Ok,
> I need to get the XML for the customer class
>
>
> i did this
>
> Customer objCustomer=new Customer();
>
> ((IXML)objCustomer.getXML());
>
> what difference it make when i have a method like getXML() in
> Customer Class
>
> and Call directly objCustomer.getXML();
>
>
> Do let me know iam using the correct call, or what advantage do we
> have in interface seperation
>
> Regards
>
> Thomson
>

Hi Thomson

That's a good question. Why would we bother to split Customer into two
interfaces if we only endf up binding to Customer, which implements
both of them?

But we don't have to explicity instantiate Customer in our client
code, like in your example above. An instance of Customer could be
passed in as a method parameter or passed in the constrcutor of your
client object. In which case, since we only want to use the getXml()
method, we can declare the parameter as being of type IXml.

I've posted a slightly fuller explanation here -
http://parlezuml.com/blog/?postid=286

Also, you might find the OO Design Principles tutorial very useful, as
it explores these things in more detail (and also covers design
quality metrics, which help to guide our understanding a little
better). You can find it on the OO Metrics page here:

http://parlezuml.com/metrics/index.htm

You should probably bear in mind that these OO desigtn metrics are
quite old now, and were never really that robustly designed. One of my
current activities is to revisit design quality and explore new models
that might help update our understanding, espeically in the light of
advances made in the last 10 years or so (e.g., automated
refactorings, TDD, continuous integration etc). Is something that was
difficult in 1995 still as difficult today?

Hope that helps

Kind regards

Jason Gorman
http://www.parlezuml.com