Making constructor visible only to a certain class

[Peter Gummer]

This is a design question.

I have a project containing a dozen or so classes with protected
internal constructors.

My reason for having protected internal constructors is to prevent
classes in other assemblies from instantiating them. There is a factory
class that instantiates them. Only the factory should do so, because
some of these classes have subclasses that will be created instead. The
decision of which class to instantiate belongs to the factory.

I've got this working just fine, except one detail.

Because the constructors are protected internal, it's possible for
classes inside the project to by-pass the factory. It's not too hard to
ensure this doesn't happen, by checking manually within the project;
but it would be easier and safer if the compiler could catch this
mistake.

Ideally, I'd like the constructors to have a more restricted visibility
than "internal". I'd like to specify that only the factory can see
them. I.e., instead of this:

protected internal Foo() {}

I'd like to be be able to write:

protected visibleto(Facto ry) Foo() {}

Unfortunately, C# has extremely coarse-grained visiblity modifiers.

I can think of a couple of work-arounds:

Work-around 1. Declare the constructors protected and let the factory
use reflection to instantiate them.

Work-around 2. Declare a nested protected class within the factory for
each of the classes it instantiates. The nested classes would have
public constructors. Then only the factory, or its descendants, could
instantiate the classes. Exactly what I want!

Both solutions would be worse than the original problem. Reflection
(Work-around 1) kills type-safety, so I avoid it unless I absolutely
need it; besides, it's slow. Work-around 2, on the other hand, would be
a bad case of code-bloat.

Is there a decent solution to this in C#?

-- Peter Gummer

[Peter Rilling]

It would be nice if there was a "friend" concept in c#. If I may ask, why
can you not trust the code within your own assembly?

"Peter Gummer" <pe************ ******@hotnospa mmail.com> wrote in message
news:ec******** ******@TK2MSFTN GP09.phx.gbl...

This is a design question.

I have a project containing a dozen or so classes with protected
internal constructors.

My reason for having protected internal constructors is to prevent
classes in other assemblies from instantiating them. There is a factory
class that instantiates them. Only the factory should do so, because
some of these classes have subclasses that will be created instead. The
decision of which class to instantiate belongs to the factory.

I've got this working just fine, except one detail.

Because the constructors are protected internal, it's possible for
classes inside the project to by-pass the factory. It's not too hard to
ensure this doesn't happen, by checking manually within the project;
but it would be easier and safer if the compiler could catch this
mistake.

Ideally, I'd like the constructors to have a more restricted visibility
than "internal". I'd like to specify that only the factory can see
them. I.e., instead of this:

protected internal Foo() {}

I'd like to be be able to write:

protected visibleto(Facto ry) Foo() {}

Unfortunately, C# has extremely coarse-grained visiblity modifiers.

I can think of a couple of work-arounds:

Work-around 1. Declare the constructors protected and let the factory
use reflection to instantiate them.

Work-around 2. Declare a nested protected class within the factory for
each of the classes it instantiates. The nested classes would have
public constructors. Then only the factory, or its descendants, could
instantiate the classes. Exactly what I want!

Both solutions would be worse than the original problem. Reflection
(Work-around 1) kills type-safety, so I avoid it unless I absolutely
need it; besides, it's slow. Work-around 2, on the other hand, would be
a bad case of code-bloat.

Is there a decent solution to this in C#?

-- Peter Gummer

[Peter Gummer]

Peter Rilling wrote:

It would be nice if there was a "friend" concept in c#. If I may
ask, why can you not trust the code within your own assembly?

Well, I can trust it only insofar as I am infallible. I am but human,
so I'm sure to make mistakes :-)

It would be very easy to forget to use the factory. New developers will
also have to learn that my design involves calling the factory. I have
documented the design, but if someone fails to read the documentation
then they will probably just write "new Foo()" instead of
"Factory.NewFoo ".

My preference is for Eiffel, not C++, so I was wishing for "selective
export" rather than "friend". But you get the idea.

-- Peter Gummer

[Joanna Carter [TeamB]]

"Peter Gummer" <pe************ ******@hotnospa mmail.com> a écrit dans le
message de news: ec************* *@TK2MSFTNGP09. phx.gbl...

| Because the constructors are protected internal, it's possible for
| classes inside the project to by-pass the factory. It's not too hard to
| ensure this doesn't happen, by checking manually within the project;
| but it would be easier and safer if the compiler could catch this
| mistake.

How about using the InternalsVisibl eTo attribute to allow one assembly
access to something internal from another assembly.

This means that you could declare your classes with internal constructors in
one assembly and the factory in a "friend" assembly. As long as the factory
is the only class in the "friend" assembly, then it will be the only class
that can instantiate your types.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Andreas Mueller]

Joanna Carter [TeamB] wrote:

"Peter Gummer" <pe************ ******@hotnospa mmail.com> a écrit dans le
message de news: ec************* *@TK2MSFTNGP09. phx.gbl...

| Because the constructors are protected internal, it's possible for
| classes inside the project to by-pass the factory. It's not too hard to
| ensure this doesn't happen, by checking manually within the project;
| but it would be easier and safer if the compiler could catch this
| mistake.

How about using the InternalsVisibl eTo attribute to allow one assembly
access to something internal from another assembly.

This means that you could declare your classes with internal constructors in
one assembly and the factory in a "friend" assembly. As long as the factory
is the only class in the "friend" assembly, then it will be the only class
that can instantiate your types.

Joanna

That's a cool one :-). I wish I knew that a year ago.

But this applies just for the complete type, not one of its fields. I
think the OPs intend was to declare just the ctors private.

Here's a way to make the just ctor private:

public class AA
{
private AA() { }
}

public static class AAFactory
{
public static AA CreateAA()
{
return (AA)Activator.C reateInstance(t ypeof(AA), true);
}
public static T Create<T>()
{
return (T)Activator.Cr eateInstance(ty peof(T), true);
}
}

AA a1 = AAFactory.Creat e<AA>();
AA a2 = AAFactory.Creat eAA();
However, if it is possible for the factory just to return a base class
or interface, Joannas aproach is the cleanest.

HTH,
Andy
--
To email me directly, please remove the *NO*SPAM* parts below:
*NO*SPAM*xmen40 @*NO*SPAM*gmx.n et

[Nick Hounsome]

"Peter Gummer" <pe************ ******@hotnospa mmail.com> wrote in message
news:ec******** ******@TK2MSFTN GP09.phx.gbl...

This is a design question.

I have a project containing a dozen or so classes with protected
internal constructors.

My reason for having protected internal constructors is to prevent
classes in other assemblies from instantiating them. There is a factory
class that instantiates them. Only the factory should do so, because
some of these classes have subclasses that will be created instead. The
decision of which class to instantiate belongs to the factory.

"protected internal" allows calling by the ctors of derived classes which
doesn't sound like what you want.

[Abubakar]

Why not just make the constructors private and use the factory thing
everywhere?

One more thing, have you checked FxCop? I think you can make a rule in it
and it'll do the enforcement of not using "new" that you want in your
current approach. Just an idea.

Regards.

-Ab.

"Peter Gummer" <pe************ ******@hotnospa mmail.com> wrote in message
news:ec******** ******@TK2MSFTN GP09.phx.gbl...

This is a design question.

I have a project containing a dozen or so classes with protected
internal constructors.

My reason for having protected internal constructors is to prevent
classes in other assemblies from instantiating them. There is a factory
class that instantiates them. Only the factory should do so, because
some of these classes have subclasses that will be created instead. The
decision of which class to instantiate belongs to the factory.

I've got this working just fine, except one detail.

Because the constructors are protected internal, it's possible for
classes inside the project to by-pass the factory. It's not too hard to
ensure this doesn't happen, by checking manually within the project;
but it would be easier and safer if the compiler could catch this
mistake.

Ideally, I'd like the constructors to have a more restricted visibility
than "internal". I'd like to specify that only the factory can see
them. I.e., instead of this:

protected internal Foo() {}

I'd like to be be able to write:

protected visibleto(Facto ry) Foo() {}

Unfortunately, C# has extremely coarse-grained visiblity modifiers.

I can think of a couple of work-arounds:

Work-around 1. Declare the constructors protected and let the factory
use reflection to instantiate them.

Work-around 2. Declare a nested protected class within the factory for
each of the classes it instantiates. The nested classes would have
public constructors. Then only the factory, or its descendants, could
instantiate the classes. Exactly what I want!

Both solutions would be worse than the original problem. Reflection
(Work-around 1) kills type-safety, so I avoid it unless I absolutely
need it; besides, it's slow. Work-around 2, on the other hand, would be
a bad case of code-bloat.

Is there a decent solution to this in C#?

-- Peter Gummer

[Peter Gummer]

Nick Hounsome wrote:

"protected internal" allows calling by the ctors of derived classes
which doesn't sound like what you want.

That's exactly what I want.

I'm not trying to restrict the capabilities of subclasses. I'm trying
to restrict the capabilities of clients; i.e., I don't want other
objects to be able to instantiate the product classes. Only the factory
should instantiate them.

So no: I definitely do not want "internal"; "protected internal" is
closer to what I want. My problem is that "internal" is too crude a
mechanism; "protected" is just fine.

-- Peter Gummer

[Peter Gummer]

Abubakar wrote:

Why not just make the constructors private and use the factory thing
everywhere?

If I made the constructors "private" (or "protected" ), the factory
would not have access to the constructors, so it would be unable to
instantiate the product classes -- unless, of course, I used one of the
two work-arounds that I mentioned in my original post (i.e. reflection,
for which Andreas Mueller gave sample code, or writing a protected
subclass for each product class nested within the factory) -- both of
which cures I feel are worse than the original problem.

Am I missing something in your "private" suggestion?

Thanks for the FxCop idea. We might end up doing that. It's a pain,
though, having to use a tool like FxCop to overcome the deficiencies of
the language.

-- Peter Gummer

[Peter Gummer]

Joanna Carter [TeamB] wrote:

How about using the InternalsVisibl eTo attribute to allow one
assembly access to something internal from another assembly.

This means that you could declare your classes with internal
constructors in one assembly and the factory in a "friend" assembly.
As long as the factory is the only class in the "friend" assembly,
then it will be the only class that can instantiate your types.

Something like that might work. I didn't know about InternalsVisibl eTo.

I wouldn't make the constructors "internal", though. That's exactly
what I'm trying to prevent: products within the assembly creating each
other directly. If I simply made the constructors "protected" , then
your idea should work.

The idea of adding another project, containing nothing but the factory,
doesn't really appeal to me. I actually have several factories (a fact
I didn't mention earlier), so I'd finish up with several teensy-weensy
factory projects. My initial feeling is that this is another cure worse
than the original problem; but I'll think about it.

Thanks for the suggestion.

-- Peter Gummer