> > 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. > > That sounds like your interfaces weren't factored out correctly - following > what we agree on above, shouldn't ISomeIf1, ISomeIf2 and ISomeIf3 also each > contain complete sets of method signatures required to comprimise meaningful > client views on your implementing classes?..
Well, I am not so sure. The problem is, in my case, that I had to choose between a cleaner design and simplified usage, which means correctness. What happens if DoSomething2() requires a transaction? That is, the action is atomic and in order to leave all these participating objects in a consistent state, a number of actions should be performed? In my case, I provide an interface for an object tree. To perform some more advanced operations, the whole tree is synchronized, using a single, tree-wide lock. This is why all objects must come from the same assembly and why the interfaces are, in fact, unimplementable. Perhaps another approach could be used - but still, this approach is simple and efficient enough to solve the problem. > > > 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. > > Yep, plus ISomeIf becomes essentially unimplementable - you're casting to > the private/internal class because you need to invoke methods not declared > in ISomeIf but no-one else will ever have visibility to what those methods > are. I believe that it happens quite often in varions object libraries that although they are based on interfaces or even sometimes on classes, they in fact only operate on objects created earlier by the library. Marek > -----Original Message----- > From: Marek Malowidzki [mailto:[EMAIL PROTECTED] > Sent: 16 April 2004 08:50 > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Public abstract classes with internal > abstr act methods > > > > 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 > > _____________________________________________________________________ > 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
