Might be missing the point here, but why would you ever want to provide an interface for an assembly's client that assures its implementation will be of a given type?
When I go to the trouble of writing a factory that returns references to a public interface implemented in an internal class then it's because I want to decouple the assembly clients from the implementation details so they can be transparently changed in future. On the other hand, the rest of the time when I'm less bothered about leaking implementation details into the outside world then I just take the lazy option and use a class (something I'm becoming increasingly less comfortable with). In fact "an interface that assures its implementation will be of a given type" just sounds to me like another way of describing a class in .NET?... Julian -----Original Message----- From: Marek Malowidzki [mailto:[EMAIL PROTECTED] Sent: 15 April 2004 14:58 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Public abstract classes with internal abstract methods > Instead of an unneeded abstract method, I'd rather get the same effect using > an internal constructor. > > public class BaseClass > { > internal BaseClass() > { > } > } Or, in managed C++, the "private public" access specifier. The original post touches one interesting issue: providing an interface for an assembly's client (where "interface" means either real interface or a class) that assures that its implementation will be of a given type (often, coming from the assembly). For example, when someone needs to develop a package that uses interfaces but internally casts them to an assembly's private type (to allow for operations or access state that should not be seen by the client). This is often not elegant but greatly simplifies the package's overall interface. With classes, with the internal constructor, or the foo() approach, it is possible. Using interfaces is often a better choice, but the problem is that anyone could implement it. So I personally sometimes feel it would be cool to have "public internally implementable" interfaces. E.g., through adding a "constructor" notion to interface (just to mark the inheritance access): public interface IMySmartInterface { internal IMySmartInterface(); // must be always parameterless and cannot have implementation in implementing classes void DoSomething(); // common methods: always public } Of course, I am speculating only. Marek > Jim Gunkel > Nevrona Designs > > ----- Original Message ----- > From: "Ilya Ryzhenkov" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, April 10, 2004 2:27 AM > Subject: [ADVANCED-DOTNET] Public abstract classes with internal abstract > methods > > > > This was recently discovered locally, that it is allowed (without a > warning) > > to create class like this: > > > > public abstract class AbstractBase > > { > > internal abstract void foo(); > > } > > > > First, I thought it's a sort of bug. But after some thinking about the > > fact... This could be used to ensure all derived classes are in the same > > assembly, but base class is still usable from outside. Moreover, unlike > with > > interfaces, you ensure protocol and still don't allow anyone to implement > it > > outside of your package. Details here: > > http://www.silicontaiga.com/orangy/000032.html > > > > Any comments from the group? > > > > Sincerely yours, Ilya Ryzhenkov > > > > =================================== > > This list is hosted by DevelopMentorŪ http://www.develop.com > > Some .NET courses you may be interested in: > > > > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles > > http://www.develop.com/courses/gaspdotnetls > > > > View archives and manage your subscription(s) at > http://discuss.develop.com > > > > =================================== > This list is hosted by DevelopMentorŪ http://www.develop.com > Some .NET courses you may be interested in: > > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles > http://www.develop.com/courses/gaspdotnetls > > View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. For further information visit http://www.star.net.uk/stats.asp IMPORTANT NOTICE This communication contains information, which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender. The opinions expressed within this communication are not necessarily those expressed by Teletext Ltd. Teletext Ltd. Building 10 Chiswick Park 566 Chiswick High Road London W4 5TS Registered in England number 2694814 _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. For further information visit http://www.star.net.uk/stats.asp =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
