Looking for a pattern to solve this problem;

  • Thread starter Thread starter Brad Quinn
  • Start date Start date
B

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() );
}
}
}
 
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.
 
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.

Nicholas Paldino said:
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)

Brad Quinn said:
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() );
}
}
}
Click to expand...
Click to expand...
 
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.

Brad Quinn said:
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
Click to expand...
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]...
Click to expand...
Click to expand...
 
Back
Top