473,324 Members | 2,214 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

Enhancement idea: Private interfaces?

WXS
I know this sounds contrary to the idea of an interface, but read this and
see what you think.
-----------------------------------------------------------------------------------------
It would be nice if there was a way for a class to create a special type of
interface, a private one. Private meaning it's not directly exposed at the
class level, you need to be explicitly handed a reference to it by the class.
Often the encapsulation issue is you need to implement an interface (as a
callback or some other functionality is required), but doing so exposes all
of those interface methods to any user of your class, breaking encapsulation.
So the only alternative is to then have an internal proxy class implement the
interface and proxy all of the calls to that. This would be much easier of a
class can implement a private interface that could selectively be handed out.
This way the integrity of the encapsulation is protected without requiring
the user to write a proxy class.
An example might be something like (I'm sure there could be better syntax):

public interface IMyInterface
{
void Callback();
}

class MyInterfaceUser
{
public void SetUseInterface(IMyInterface usethis)
{
// ...
{
}
class MyClass : private IMyInterface
{
MyClass(MyInterfaceUser user)
{
user.SetUseInterface(this.PrivateInterface(IMyInte rface));

}

protected void Callback()
{
//...
}

}

Jul 31 '06 #1
6 1535
Why not use the factory pattern and inheritance? Return the derived type
(with the additional members) in the CreateX() method.

--
William Stacey [MVP]

"WXS" <WX*@discussions.microsoft.comwrote in message
news:34**********************************@microsof t.com...
|I know this sounds contrary to the idea of an interface, but read this and
| see what you think.
| -----------------------------------------------------------------------------------------
| It would be nice if there was a way for a class to create a special type
of
| interface, a private one. Private meaning it's not directly exposed at the
| class level, you need to be explicitly handed a reference to it by the
class.
| Often the encapsulation issue is you need to implement an interface (as a
| callback or some other functionality is required), but doing so exposes
all
| of those interface methods to any user of your class, breaking
encapsulation.
| So the only alternative is to then have an internal proxy class implement
the
| interface and proxy all of the calls to that. This would be much easier of
a
| class can implement a private interface that could selectively be handed
out.
| This way the integrity of the encapsulation is protected without requiring
| the user to write a proxy class.
|
|
| An example might be something like (I'm sure there could be better
syntax):
|
| public interface IMyInterface
| {
| void Callback();
| }
|
| class MyInterfaceUser
| {
| public void SetUseInterface(IMyInterface usethis)
| {
| // ...
| {
| }
|
|
| class MyClass : private IMyInterface
| {
| MyClass(MyInterfaceUser user)
| {
| user.SetUseInterface(this.PrivateInterface(IMyInte rface));
|
| }
|
| protected void Callback()
| {
| //...
| }
|
| }
|
Aug 1 '06 #2
WXS
Certainly proxies or factory patterns work, but that means you now have to
make anyone that uses your class go through a special factory just because
you don't want to expose a particular interface, that just seems plain not
good from the stand point of someone going to use the class.

It would be much cleaner to be able to avoid extra proxy method hops and
special patterns for usage of your class, by having this mechanism.

"William Stacey [MVP]" wrote:
Why not use the factory pattern and inheritance? Return the derived type
(with the additional members) in the CreateX() method.

--
William Stacey [MVP]

"WXS" <WX*@discussions.microsoft.comwrote in message
news:34**********************************@microsof t.com...
|I know this sounds contrary to the idea of an interface, but read this and
| see what you think.
| -----------------------------------------------------------------------------------------
| It would be nice if there was a way for a class to create a special type
of
| interface, a private one. Private meaning it's not directly exposed at the
| class level, you need to be explicitly handed a reference to it by the
class.
| Often the encapsulation issue is you need to implement an interface (as a
| callback or some other functionality is required), but doing so exposes
all
| of those interface methods to any user of your class, breaking
encapsulation.
| So the only alternative is to then have an internal proxy class implement
the
| interface and proxy all of the calls to that. This would be much easier of
a
| class can implement a private interface that could selectively be handed
out.
| This way the integrity of the encapsulation is protected without requiring
| the user to write a proxy class.
|
|
| An example might be something like (I'm sure there could be better
syntax):
|
| public interface IMyInterface
| {
| void Callback();
| }
|
| class MyInterfaceUser
| {
| public void SetUseInterface(IMyInterface usethis)
| {
| // ...
| {
| }
|
|
| class MyClass : private IMyInterface
| {
| MyClass(MyInterfaceUser user)
| {
| user.SetUseInterface(this.PrivateInterface(IMyInte rface));
|
| }
|
| protected void Callback()
| {
| //...
| }
|
| }
|
Aug 1 '06 #3
Not sure I follow. Just return the base class and the user uses that. Then
for internal usage, just cast it to lower class and use it. The user will
not see your "special" methods.

public class UserClass
{
private UserClass()
{
}
public static UserClass Create()
{
PowerClass ic = new PowerClass();
return (UserClass)ic;
}
public string Name = "Santa";
public static void DoSpecialWork(UserClass uc)
{
((PowerClass)uc).DoThis();
}

private class PowerClass : UserClass
{
public string SpecialName = "Saint Nick";
public void DoThis()
{
Console.WriteLine("I did that.");
}
}
}

// Test
UserClass uc = UserClass.Create();
UserClass.DoSpecialWork(uc);

--
William Stacey [MVP]

"WXS" <WX*@discussions.microsoft.comwrote in message
news:EF**********************************@microsof t.com...
| Certainly proxies or factory patterns work, but that means you now have to
| make anyone that uses your class go through a special factory just because
| you don't want to expose a particular interface, that just seems plain not
| good from the stand point of someone going to use the class.
|
| It would be much cleaner to be able to avoid extra proxy method hops and
| special patterns for usage of your class, by having this mechanism.
|
|
|
| "William Stacey [MVP]" wrote:
|
| Why not use the factory pattern and inheritance? Return the derived
type
| (with the additional members) in the CreateX() method.
| >
| --
| William Stacey [MVP]
| >
| "WXS" <WX*@discussions.microsoft.comwrote in message
| news:34**********************************@microsof t.com...
| |I know this sounds contrary to the idea of an interface, but read this
and
| | see what you think.
| >
| -----------------------------------------------------------------------------------------
| | It would be nice if there was a way for a class to create a special
type
| of
| | interface, a private one. Private meaning it's not directly exposed at
the
| | class level, you need to be explicitly handed a reference to it by the
| class.
| | Often the encapsulation issue is you need to implement an interface
(as a
| | callback or some other functionality is required), but doing so
exposes
| all
| | of those interface methods to any user of your class, breaking
| encapsulation.
| | So the only alternative is to then have an internal proxy class
implement
| the
| | interface and proxy all of the calls to that. This would be much
easier of
| a
| | class can implement a private interface that could selectively be
handed
| out.
| | This way the integrity of the encapsulation is protected without
requiring
| | the user to write a proxy class.
| |
| |
| | An example might be something like (I'm sure there could be better
| syntax):
| |
| | public interface IMyInterface
| | {
| | void Callback();
| | }
| |
| | class MyInterfaceUser
| | {
| | public void SetUseInterface(IMyInterface usethis)
| | {
| | // ...
| | {
| | }
| |
| |
| | class MyClass : private IMyInterface
| | {
| | MyClass(MyInterfaceUser user)
| | {
| | user.SetUseInterface(this.PrivateInterface(IMyInte rface));
| |
| | }
| |
| | protected void Callback()
| | {
| | //...
| | }
| |
| | }
| |
| >
| >
| >
Aug 1 '06 #4
WXS

You didn't actually use an interface there but same general idea.
I see a few concerns with that:
1. The "interface" is still accessible externally, they could cast the class
to the power class (unless the power class was internal/private)
2. It requires me as the class developer to create two classes just to hide
my interface
3. It requires me as the user of the component to know that I must call
UserClass.Create() rather than just being able to do new UserClass(); Forcing
the user to use a .Create method rather than a "new" just because you want to
hide an internal interface seems like it doesn't really deserve a factory
pattern and just feels wrong and makes usage of instantiation different for
that class just because the internal implementation needed to hide an
interface.

All of those add up to a less than desireable solution for both the
developer of the class and the user of the class. If you implemented the
private interface concept, the usage of creating the class can still use
"new" and the developer of the class did not have to create a derived class
just to hide the interface. Private interfaces produce truly encapsulated
private interfaces and easier to use code.

"William Stacey [MVP]" wrote:
Not sure I follow. Just return the base class and the user uses that. Then
for internal usage, just cast it to lower class and use it. The user will
not see your "special" methods.

public class UserClass
{
private UserClass()
{
}
public static UserClass Create()
{
PowerClass ic = new PowerClass();
return (UserClass)ic;
}
public string Name = "Santa";
public static void DoSpecialWork(UserClass uc)
{
((PowerClass)uc).DoThis();
}

private class PowerClass : UserClass
{
public string SpecialName = "Saint Nick";
public void DoThis()
{
Console.WriteLine("I did that.");
}
}
}

// Test
UserClass uc = UserClass.Create();
UserClass.DoSpecialWork(uc);

--
William Stacey [MVP]

"WXS" <WX*@discussions.microsoft.comwrote in message
news:EF**********************************@microsof t.com...
| Certainly proxies or factory patterns work, but that means you now have to
| make anyone that uses your class go through a special factory just because
| you don't want to expose a particular interface, that just seems plain not
| good from the stand point of someone going to use the class.
|
| It would be much cleaner to be able to avoid extra proxy method hops and
| special patterns for usage of your class, by having this mechanism.
|
|
|
| "William Stacey [MVP]" wrote:
|
| Why not use the factory pattern and inheritance? Return the derived
type
| (with the additional members) in the CreateX() method.
| >
| --
| William Stacey [MVP]
| >
| "WXS" <WX*@discussions.microsoft.comwrote in message
| news:34**********************************@microsof t.com...
| |I know this sounds contrary to the idea of an interface, but read this
and
| | see what you think.
| >
| -----------------------------------------------------------------------------------------
| | It would be nice if there was a way for a class to create a special
type
| of
| | interface, a private one. Private meaning it's not directly exposed at
the
| | class level, you need to be explicitly handed a reference to it by the
| class.
| | Often the encapsulation issue is you need to implement an interface
(as a
| | callback or some other functionality is required), but doing so
exposes
| all
| | of those interface methods to any user of your class, breaking
| encapsulation.
| | So the only alternative is to then have an internal proxy class
implement
| the
| | interface and proxy all of the calls to that. This would be much
easier of
| a
| | class can implement a private interface that could selectively be
handed
| out.
| | This way the integrity of the encapsulation is protected without
requiring
| | the user to write a proxy class.
| |
| |
| | An example might be something like (I'm sure there could be better
| syntax):
| |
| | public interface IMyInterface
| | {
| | void Callback();
| | }
| |
| | class MyInterfaceUser
| | {
| | public void SetUseInterface(IMyInterface usethis)
| | {
| | // ...
| | {
| | }
| |
| |
| | class MyClass : private IMyInterface
| | {
| | MyClass(MyInterfaceUser user)
| | {
| | user.SetUseInterface(this.PrivateInterface(IMyInte rface));
| |
| | }
| |
| | protected void Callback()
| | {
| | //...
| | }
| |
| | }
| |
| >
| >
| >
Aug 1 '06 #5
I think I see what you need. Actually, c# has private interface ability
already. Example:

interface IPower
{
void DoIt();
}

public class UserClass : IPower
{
public string Name = "Santa";

public UserClass()
{
}

void IPower.DoIt()
{
Console.WriteLine("DoIt");
}

public static void Test()
{
UserClass uc = new UserClass();
IPower ip = (IPower)uc;
ip.DoIt();
}
}

A user could still use reflection to gain access to private members.

--
William Stacey [MVP]

"WXS" <WX*@discussions.microsoft.comwrote in message
news:0E**********************************@microsof t.com...
|
| You didn't actually use an interface there but same general idea.
| I see a few concerns with that:
| 1. The "interface" is still accessible externally, they could cast the
class
| to the power class (unless the power class was internal/private)
| 2. It requires me as the class developer to create two classes just to
hide
| my interface
| 3. It requires me as the user of the component to know that I must call
| UserClass.Create() rather than just being able to do new UserClass();
Forcing
| the user to use a .Create method rather than a "new" just because you want
to
| hide an internal interface seems like it doesn't really deserve a factory
| pattern and just feels wrong and makes usage of instantiation different
for
| that class just because the internal implementation needed to hide an
| interface.
|
| All of those add up to a less than desireable solution for both the
| developer of the class and the user of the class. If you implemented the
| private interface concept, the usage of creating the class can still use
| "new" and the developer of the class did not have to create a derived
class
| just to hide the interface. Private interfaces produce truly encapsulated
| private interfaces and easier to use code.
|
| "William Stacey [MVP]" wrote:
|
| Not sure I follow. Just return the base class and the user uses that.
Then
| for internal usage, just cast it to lower class and use it. The user
will
| not see your "special" methods.
| >
| public class UserClass
| {
| private UserClass()
| {
| }
| public static UserClass Create()
| {
| PowerClass ic = new PowerClass();
| return (UserClass)ic;
| }
| public string Name = "Santa";
| >
| >
| public static void DoSpecialWork(UserClass uc)
| {
| ((PowerClass)uc).DoThis();
| }
| >
| private class PowerClass : UserClass
| {
| public string SpecialName = "Saint Nick";
| public void DoThis()
| {
| Console.WriteLine("I did that.");
| }
| }
| }
| >
| // Test
| UserClass uc = UserClass.Create();
| UserClass.DoSpecialWork(uc);
| >
| --
| William Stacey [MVP]
| >
| "WXS" <WX*@discussions.microsoft.comwrote in message
| news:EF**********************************@microsof t.com...
| | Certainly proxies or factory patterns work, but that means you now
have to
| | make anyone that uses your class go through a special factory just
because
| | you don't want to expose a particular interface, that just seems plain
not
| | good from the stand point of someone going to use the class.
| |
| | It would be much cleaner to be able to avoid extra proxy method hops
and
| | special patterns for usage of your class, by having this mechanism.
| |
| |
| |
| | "William Stacey [MVP]" wrote:
| |
| | Why not use the factory pattern and inheritance? Return the derived
| type
| | (with the additional members) in the CreateX() method.
| | >
| | --
| | William Stacey [MVP]
| | >
| | "WXS" <WX*@discussions.microsoft.comwrote in message
| | news:34**********************************@microsof t.com...
| | |I know this sounds contrary to the idea of an interface, but read
this
| and
| | | see what you think.
| | >
| >
| -----------------------------------------------------------------------------------------
| | | It would be nice if there was a way for a class to create a
special
| type
| | of
| | | interface, a private one. Private meaning it's not directly
exposed at
| the
| | | class level, you need to be explicitly handed a reference to it by
the
| | class.
| | | Often the encapsulation issue is you need to implement an
interface
| (as a
| | | callback or some other functionality is required), but doing so
| exposes
| | all
| | | of those interface methods to any user of your class, breaking
| | encapsulation.
| | | So the only alternative is to then have an internal proxy class
| implement
| | the
| | | interface and proxy all of the calls to that. This would be much
| easier of
| | a
| | | class can implement a private interface that could selectively be
| handed
| | out.
| | | This way the integrity of the encapsulation is protected without
| requiring
| | | the user to write a proxy class.
| | |
| | |
| | | An example might be something like (I'm sure there could be better
| | syntax):
| | |
| | | public interface IMyInterface
| | | {
| | | void Callback();
| | | }
| | |
| | | class MyInterfaceUser
| | | {
| | | public void SetUseInterface(IMyInterface usethis)
| | | {
| | | // ...
| | | {
| | | }
| | |
| | |
| | | class MyClass : private IMyInterface
| | | {
| | | MyClass(MyInterfaceUser user)
| | | {
| | | user.SetUseInterface(this.PrivateInterface(IMyInte rface));
| | |
| | | }
| | |
| | | protected void Callback()
| | | {
| | | //...
| | | }
| | |
| | | }
| | |
| | >
| | >
| | >
| >
| >
| >
Aug 2 '06 #6
WXS
Right, but I'm talking about a case where I may have to implement in my class
an interface that I don't control myself so I can not insure that it is
private. Let's say I have a routine I use internally that needs me to
implement INotMyInterface which is public. I don't control that interface
but I need to use it for a callback. I don't want the callback method it
exposes shown publicly from my class, so my choices are back to a
proxy/factory pattern which as I mentioned is detrimental for both the
implementer and the user of the class. Where if we could support "making"
any interface I derive from to be private I could prevent exposing the public
interface methods on my class, without having to resort to the not so good
solutions of proxy/factory patterns.
"William Stacey [MVP]" wrote:
I think I see what you need. Actually, c# has private interface ability
already. Example:

interface IPower
{
void DoIt();
}

public class UserClass : IPower
{
public string Name = "Santa";

public UserClass()
{
}

void IPower.DoIt()
{
Console.WriteLine("DoIt");
}

public static void Test()
{
UserClass uc = new UserClass();
IPower ip = (IPower)uc;
ip.DoIt();
}
}

A user could still use reflection to gain access to private members.

--
William Stacey [MVP]

"WXS" <WX*@discussions.microsoft.comwrote in message
news:0E**********************************@microsof t.com...
|
| You didn't actually use an interface there but same general idea.
| I see a few concerns with that:
| 1. The "interface" is still accessible externally, they could cast the
class
| to the power class (unless the power class was internal/private)
| 2. It requires me as the class developer to create two classes just to
hide
| my interface
| 3. It requires me as the user of the component to know that I must call
| UserClass.Create() rather than just being able to do new UserClass();
Forcing
| the user to use a .Create method rather than a "new" just because you want
to
| hide an internal interface seems like it doesn't really deserve a factory
| pattern and just feels wrong and makes usage of instantiation different
for
| that class just because the internal implementation needed to hide an
| interface.
|
| All of those add up to a less than desireable solution for both the
| developer of the class and the user of the class. If you implemented the
| private interface concept, the usage of creating the class can still use
| "new" and the developer of the class did not have to create a derived
class
| just to hide the interface. Private interfaces produce truly encapsulated
| private interfaces and easier to use code.
|
| "William Stacey [MVP]" wrote:
|
| Not sure I follow. Just return the base class and the user uses that.
Then
| for internal usage, just cast it to lower class and use it. The user
will
| not see your "special" methods.
| >
| public class UserClass
| {
| private UserClass()
| {
| }
| public static UserClass Create()
| {
| PowerClass ic = new PowerClass();
| return (UserClass)ic;
| }
| public string Name = "Santa";
| >
| >
| public static void DoSpecialWork(UserClass uc)
| {
| ((PowerClass)uc).DoThis();
| }
| >
| private class PowerClass : UserClass
| {
| public string SpecialName = "Saint Nick";
| public void DoThis()
| {
| Console.WriteLine("I did that.");
| }
| }
| }
| >
| // Test
| UserClass uc = UserClass.Create();
| UserClass.DoSpecialWork(uc);
| >
| --
| William Stacey [MVP]
| >
| "WXS" <WX*@discussions.microsoft.comwrote in message
| news:EF**********************************@microsof t.com...
| | Certainly proxies or factory patterns work, but that means you now
have to
| | make anyone that uses your class go through a special factory just
because
| | you don't want to expose a particular interface, that just seems plain
not
| | good from the stand point of someone going to use the class.
| |
| | It would be much cleaner to be able to avoid extra proxy method hops
and
| | special patterns for usage of your class, by having this mechanism.
| |
| |
| |
| | "William Stacey [MVP]" wrote:
| |
| | Why not use the factory pattern and inheritance? Return the derived
| type
| | (with the additional members) in the CreateX() method.
| | >
| | --
| | William Stacey [MVP]
| | >
| | "WXS" <WX*@discussions.microsoft.comwrote in message
| | news:34**********************************@microsof t.com...
| | |I know this sounds contrary to the idea of an interface, but read
this
| and
| | | see what you think.
| | >
| >
| -----------------------------------------------------------------------------------------
| | | It would be nice if there was a way for a class to create a
special
| type
| | of
| | | interface, a private one. Private meaning it's not directly
exposed at
| the
| | | class level, you need to be explicitly handed a reference to it by
the
| | class.
| | | Often the encapsulation issue is you need to implement an
interface
| (as a
| | | callback or some other functionality is required), but doing so
| exposes
| | all
| | | of those interface methods to any user of your class, breaking
| | encapsulation.
| | | So the only alternative is to then have an internal proxy class
| implement
| | the
| | | interface and proxy all of the calls to that. This would be much
| easier of
| | a
| | | class can implement a private interface that could selectively be
| handed
| | out.
| | | This way the integrity of the encapsulation is protected without
| requiring
| | | the user to write a proxy class.
| | |
| | |
| | | An example might be something like (I'm sure there could be better
| | syntax):
| | |
| | | public interface IMyInterface
| | | {
| | | void Callback();
| | | }
| | |
| | | class MyInterfaceUser
| | | {
| | | public void SetUseInterface(IMyInterface usethis)
| | | {
| | | // ...
| | | {
| | | }
| | |
| | |
| | | class MyClass : private IMyInterface
| | | {
| | | MyClass(MyInterfaceUser user)
| | | {
| | | user.SetUseInterface(this.PrivateInterface(IMyInte rface));
| | |
| | | }
| | |
| | | protected void Callback()
| | | {
| | | //...
| | | }
| | |
| | | }
| | |
| | >
| | >
| | >
| >
| >
| >
Aug 2 '06 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

50
by: 127.0.0.1 | last post by:
With all the problems with having register_globals = on, I propose the following idea: We define register_globals_manual = on as a new configuration default. What this does is enable 3 new...
12
by: R | last post by:
Hello everybody. I'm writing my own Content System in PHP5. I've written so far main classes for handling DB connections, XML, XForms and Sessions. But I've got problem with one thing - it's...
4
by: Matt Osborne | last post by:
I don't know if this is the correct forum to propose a new feature for the C# languange, but I thought I would do so anyway. I was working on a project and thought of a feature that would...
104
by: cody | last post by:
What about an enhancement of foreach loops which allows a syntax like that: foeach(int i in 1..10) { } // forward foeach(int i in 99..2) { } // backwards foeach(char c in 'a'..'z') { } // chars...
22
by: WXS | last post by:
Sometimes a method in a class requires the use of class instance variables/fields that will not be used outside of the method itself. Currently this means you must create a instance field in the...
86
by: jopperdepopper | last post by:
Hi, finally giving php 5 a go, and going over the new approach to classes. Can someone clarify the public, private and protected to me? I quote the php manual: "The visibility of a property or...
63
by: time.swift | last post by:
Coming from a C++ / C# background, the lack of emphasis on private data seems weird to me. I've often found wrapping private data useful to prevent bugs and enforce error checking.. It appears...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.