> 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? To avoid casting errors in some cases.
Imagine you have an interface called ISomeIf. Then you have a type Type (either interface or a class), and that t is an instance of Type: Type t = ...; ISomeIf someIf = ...; t.DoSomething(someIf); Should ISomeIf contain the complete interface (understood as a set of methods) for DoSomething() to succeed? I believe so. Moreover, in most cases it would be probably better to define DoSomething() in ISomeIf. However, if DoSomething() operates on a number of objects: t.DoSomething2(someIf1, someIf2, someOtherIf3); then the situation may change. I recall at least one project in which the supplied references were cast internally by DoSomething2() to private types because the interface (again, set of methods) provided by types represented by someIf1, someIf2, someOtherIf3 was not sufficient for the operation to be performed. Thus, all three references had to represent classes created by factories from this assembly. Maybe, this was not a good design - but it was a kind of a compromise and allowed to provide a much simpler interface for assembly's clients. The dark side of this approach is, of course, that someone could create its own type, implementing ISomeIf, and be surprised by a cast exception. Maybe, the use of classes could help - but I wanted to stick to pure interfaces-based interface. Another project uses classes and there is no problem (but the choice of classes over interfaces was caused by a completely different things - I was implementing wrappers for an existing implementation). > 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?... Well, I was not too serious about my proposal. Just wanted to add that "sometimes I feel I would like to have this or that". I believe that many developers could feel that the language could be augmented in a few places; this not always justifies making changes, of course. Marek -----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 =================================== 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
