Looking for a pattern to solve this problem;

[Brad Quinn]

Friday, no brain power remains...

I have three assemblies; Client, Interface and Implementation.

The Client uses Implementation through remoting.
Client has a reference to Interface, but not to Implementation. Likewise,
Implementation has a reference to Interface, but not to Client.

Interface contains a class that I want to be constructed by some
class+method in Implementation, and nowhere else.

I would make the constructor internal, but the constructing class+method is
in another assembly.

Here is a greatly simplified example;

== Client ==

using System;
using Interface;

namespace Client
{
class Class1
{
// <snip/>

[STAThread]
static void Main(string[] args)
{
string someurl = GetsInitializedSomehow();

IConstructSomeClass foo =
(IConstructSomeClass)Activator.GetObject(
typeof(IConstructSomeClass), someurl );

SomeClass some = foo.Construct( "This is a test" );
}
}
}

== Interface ==

using System;

namespace Interface
{
[Serializable]
public class SomeClass
{
// I want this constructor to be hidden
public SomeClass( string data ) {
this.data = data;
}

private string data;
public string Data
{
get { return data; }
}
}

public interface IConstructSomeClass
{
SomeClass Construct( string data );
}
}

== Implementation ==

using System;
using Interface;

namespace Implementation
{
public class Class1 : MarshalByRefObject, IConstructSomeClass
{
public SomeClass Construct( string data )
{
return new SomeClass( data.ToLower() );
}
}

public class Class2 : MarshalByRefObject, IConstructSomeClass
{
public SomeClass Construct( string data )
{
return new SomeClass( data.ToUpper() );
}
}
}

 

[Nicholas Paldino [.NET/C# MVP]]

Brad,

Maybe I am missing something, but why are you going to have the class in
the Interface assembly? Why not just place it in the Implementation
assembly? If the class is never going to be used anywhere but the
Implementation assembly, then I don't see the problem.

Hope this helps.

 

[Brad Quinn]

My real client calls a method on a remote object. I'm using an interface
assembly to decouple the client and the remote object. The real method has
a few parameters and a complicated return type, hence the class in the
interface assembly.

The correct solution (I guess) is not to return a class, but rather an
interface that describes the class.

My real implementation contains the only objects with the "authority" (for
lack of a better word) to construct returned class. That is, the client
should not be able to instantiate the class returned by the remote object,
except by calling the remote object.

The incorrect solution that I was looking for was some kind of friend
functionality.

Brad,

Maybe I am missing something, but why are you going to have the class in
the Interface assembly? Why not just place it in the Implementation
assembly? If the class is never going to be used anywhere but the
Implementation assembly, then I don't see the problem.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Friday, no brain power remains...

I have three assemblies; Client, Interface and Implementation.

The Client uses Implementation through remoting.
Client has a reference to Interface, but not to Implementation. Likewise,
Implementation has a reference to Interface, but not to Client.

Interface contains a class that I want to be constructed by some
class+method in Implementation, and nowhere else.

I would make the constructor internal, but the constructing class+method is
in another assembly.

Here is a greatly simplified example;

== Client ==

using System;
using Interface;

namespace Client
{
class Class1
{
// <snip/>

[STAThread]
static void Main(string[] args)
{
string someurl = GetsInitializedSomehow();

IConstructSomeClass foo =
(IConstructSomeClass)Activator.GetObject(
typeof(IConstructSomeClass), someurl );

SomeClass some = foo.Construct( "This is a test" );
}
}
}

== Interface ==

using System;

namespace Interface
{
[Serializable]
public class SomeClass
{
// I want this constructor to be hidden
public SomeClass( string data ) {
this.data = data;
}

private string data;
public string Data
{
get { return data; }
}
}

public interface IConstructSomeClass
{
SomeClass Construct( string data );
}
}

== Implementation ==

using System;
using Interface;

namespace Implementation
{
public class Class1 : MarshalByRefObject, IConstructSomeClass
{
public SomeClass Construct( string data )
{
return new SomeClass( data.ToLower() );
}
}

public class Class2 : MarshalByRefObject, IConstructSomeClass
{
public SomeClass Construct( string data )
{
return new SomeClass( data.ToUpper() );
}
}
}

 

[Brad Quinn]

I'm having some trouble making this work.

When my "Interface" assembly defines an interface, whose methods take
interfaces as parameters, neither the "Client" nor the "Implementation"
assembly is satisfied with just a reference to the "Interface" assembly.

Everything looks fine at compile time, but at runtime the "Client" and the
"Implementation" want to have access to the assemblies that actually
implement the interfaces.

In this case I may as well leave the class in the interface assembly. I
can't get things scoped the way I want them, but at least the assembly
dependencies are minimal.

My real client calls a method on a remote object. I'm using an interface
assembly to decouple the client and the remote object. The real method has
a few parameters and a complicated return type, hence the class in the
interface assembly.

The correct solution (I guess) is not to return a class, but rather an
interface that describes the class.

My real implementation contains the only objects with the "authority" (for
lack of a better word) to construct returned class. That is, the client
should not be able to instantiate the class returned by the remote object,
except by calling the remote object.

The incorrect solution that I was looking for was some kind of friend
functionality.

in message news:[email protected]...

Brad,

Maybe I am missing something, but why are you going to have the

class

in
the Interface assembly? Why not just place it in the Implementation
assembly? If the class is never going to be used anywhere but the
Implementation assembly, then I don't see the problem.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

news:[email protected]...