Partial interfaces

[Giulio Petrucci]

Hello there,

I need to have a Foo class which has a behaviour we can assume made of
two methods: X() and Y().
A client assembly A must "see" only X, while another client assembly B
must see only Y (maybe it's a typical ISP case). I thought to define
the two methods as separate behaviours using partial interfaces. So I
think I can write:

(Assembly MyProject.A)
namespace MyProject {
public partial interface IFoo {
void X();
}
}

(Assembly MyProject.B)
namespace MyProject {
public partial interface IFoo {
void B();
}
}

(Assembly MyProject)
namespace MyProject {
public class Foo : IFoo {
public void X();
public void Y();
}
}

(Assembly Client.A --> reference solo a MyProject.A)
....
IFoo f = FooFactory.CreateFoo();
f.X();

(Assembly Client.B --> reference solo a MyProject.B)
....
IFoo f = FooFactory.CreateFoo();
f.Y();

I got this from the compiler:

Error 1 The type 'MyProject.IFoo' exists in both 'c:\Documents and
Settings\petrux\My Documents\Visual Studio
2008\Projects\PartialInterfaces\MyProject.A\bin\Debug\MyProject.A.dll'
and 'c:\Documents and Settings\petrux\My Documents\Visual Studio
2008\Projects\PartialInterfaces\MyProject.B\bin\Debug\MyProject.B.dll'

What I've made wrong?
Thanks in advance,
Giulio
--

 

[Patrice]

Partial is a compile time features and allows to split the code that defines
your interface between several files. All those files are still supposed to
be compiled at the same time... Here you are just creating the same type in
two different projects which gives the error message you get.

Depending on what you mean by "must see", you could just have two separate
interfaces (of course each client is still able to use whatever interface he
wants).

 

[Giulio Petrucci]

Hi Patrice,

Partial is a compile time features and allows to split the code that
defines your interface between several files. All those files are still
supposed to be compiled at the same time... Here you are just creating
the same type in two different projects which gives the error message
you get.

Right. I also checked the C# 3.0 spec and found:
"All parts of a partial type must be compiled together such that the
parts can be merged at compile-time into a single type declaration.
Partial types specifically do not allow already compiled types to be
extended."

Depending on what you mean by "must see",

Interface Segregation.

you could just have two
separate interfaces (of course each client is still able to use whatever
interface he wants).

I know. But have multiple interface is a big deal because of the
multiplication of names/namespaces. The patrial interface could have
been a great solution.

Thanks,
Giulio
--

 

[Patrice]

I know. But have multiple interface is a big deal because of the

multiplication of names/namespaces. The patrial interface could have been
a great solution.

Not sure it's worse than using the same name to name different things ;-).
You may want to elaborate a bit if for some reason using multiple interfaces
causes a real problem other than being annoyed to have to use multiple
names...

 

[Harlan Messinger]

Hi Patrice,


Right. I also checked the C# 3.0 spec and found:
"All parts of a partial type must be compiled together such that the
parts can be merged at compile-time into a single type declaration.
Partial types specifically do not allow already compiled types to be
extended."


Interface Segregation.


I know. But have multiple interface is a big deal because of the
multiplication of names/namespaces. The patrial interface could have
been a great solution.

What you're asking for is what interfaces *are*: the ability to show one
face to one set of clients, another face to another set of clients, etc.
What you've asked for, by definition, is how to present two different
interfaces to clients. The answer is, by having two interfaces. As for
the number of names: a program should have as many names as it needs! As
for namespaces: there is nothing preventing all of this from occurring
within the same namespace.

 

[Gregory A. Beamer]

I know. But have multiple interface is a big deal because of the
multiplication of names/namespaces. The patrial interface could have
been a great solution.

I have also seen the problem solved with different builds of classes. As
long as the serializable bits stay the same, you can easily serialize to
the client classes, even though they do not contain all of the methods
of the server classes. I have worked on both effective and ineffective
versions of this idea.

A "translation layer" is another option. Or you can "decorate" (pattern
clue) the server vresion of the class and not use the "decoration" on
the client bits.

It is all in how you wish to solve the problem.

The partial interface idea is interesting, but you still end up with
some conditional compilation, which already solves the problem without
the need for additional partials on the interface. In addition, if you
are not serializing, you will still end up with incompatibilities
between objects require a "translation layer" to solve the issue.

As it stands, I don't envision an implementation that does not require
other patterns that can solve it without the partial. This is looking at
the entire problem and not just the path you are aiming at.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************