http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Noticed you have Execute on the interface but not on the class... @Andrey "Doing something 'just for tests' feels as bad as doing something 'just for persistence' or 'just for specific IoC container'." I think a lot of the time this is true, changes put in for testing don't necessarily prove that useful. That is not an argument against TDDD though, just not sure always designing for testability is always a good approach. @Jon Skeet Good, maybe not but I've seen it used where you have a seperation between layers but actually there is a tight relationship. For example only an AccountService (in one project) should access a member on Account (in another project), in those cases you can make the member public and only use it from AccountService or just use InternalsVisibleTo in order to give the project containing AccountService access. http://ayende.com/3377/public-vs-published#comment19http://ayende.com/3377/public-vs-published#comment19Mon, 30 Jun 2008 12:36:42 GMTThe first textbook I ever came across on computer security discussed role-based security access to functions prior to applying it to things like file and object access. I agree that public/private/protected/internal are too gross in their scopes- very convenient for lots of cases, but not adequate. I for one would like to be able to unit-test "private" methods and classes as well. Of course, role-based or named-entity-based access authorization for code introduces a set of questions, but I'm quite confident that a broader set of cases could be handled with the answers that are easier to arrive at. http://ayende.com/3377/public-vs-published#comment18http://ayende.com/3377/public-vs-published#comment18Fri, 27 Jun 2008 17:22:30 GMTJon, when working with NHibernate, I use InternalsVisibleTo to give Castle.DynamicProxy access to the internals of my domain model.This allows me to use the lazy loading that Castle.DynamicProxy provides while keeping stricter controls on the visibility of constructors. http://ayende.com/3377/public-vs-published#comment17http://ayende.com/3377/public-vs-published#comment17Fri, 27 Jun 2008 08:06:33 GMTOut of interest, has anyone here ever seen a good use for InternalsVisibleTo *other* than testing? That's the only use I've had for it so far, and I'd be slightly worried at other uses, I suspect. If anyone's found one, I'd be interested to hear about it. http://ayende.com/3377/public-vs-published#comment16http://ayende.com/3377/public-vs-published#comment16Fri, 27 Jun 2008 06:06:47 GMTI do not see any be-public requirements here: http://www.ayende.com/Blog/archive/2008/01/24/Interception-as-an-extensibility-mechanism.aspx, what am I missing? http://ayende.com/3377/public-vs-published#comment15http://ayende.com/3377/public-vs-published#comment15Thu, 26 Jun 2008 13:12:44 GMTI do not see any be-public requirements here: http://www.ayende.com/Blog/archive/2008/01/24/Interception-as-an-extensibility-mechanism.aspx, what am I missing? http://ayende.com/3377/public-vs-published#comment14http://ayende.com/3377/public-vs-published#comment14Thu, 26 Jun 2008 13:12:44 GMTBecause testability is a secondary concern. I often need to be able to support additional functionality, and I found out that creating this distinction means that I can get pretty good results over a long period of time. here is an example: http://www.ayende.com/Blog/archive/2008/01/24/Interception-as-an-extensibility-mechanism.aspx http://ayende.com/3377/public-vs-published#comment13http://ayende.com/3377/public-vs-published#comment13Thu, 26 Jun 2008 06:44:52 GMTEd, I really don't see how "other explicitly defined assemblies" could access internal members. It would defeat the whole purpose of friend assemblies. Ayende, could you say why you dislike this method ? Because I see it very much like Andrey. The other way to test internal stuff could be to implement test classes inside the tested assembly itself and manage builds so that test classes are not included in release version. With partial classes maybe we could test private stuff to. Haven't tried this scenario myself.. http://ayende.com/3377/public-vs-published#comment12http://ayende.com/3377/public-vs-published#comment12Thu, 26 Jun 2008 06:24:01 GMTYou seem to be ignoring the part of testing not the only thing required. And published is not the same as public. For published, I want to support this. For public, it means that you can do things with it, but it is your responsability http://ayende.com/3377/public-vs-published#comment11http://ayende.com/3377/public-vs-published#comment11Thu, 26 Jun 2008 06:14:52 GMTTesting works extremely well with InternalsVisibleTo. Also it seems the right thing to do -- why do something as big as making everything public just for testing purposes? I always try to write my code to be test ignorant (making code modular or using interfaces are common sense good design decisions, not test-forced ones). Doing something 'just for tests' feels as bad as doing something 'just for persistence' or 'just for specific IoC container'. But if you have an advanced scenario when you need these classes to be public, probably it means they are 'published' as well. http://ayende.com/3377/public-vs-published#comment10http://ayende.com/3377/public-vs-published#comment10Thu, 26 Jun 2008 06:10:53 GMTWhy wouldn't you mark the set parts of the properties to private since the way they should be initialized is via the Init method? http://ayende.com/3377/public-vs-published#comment9http://ayende.com/3377/public-vs-published#comment9Thu, 26 Jun 2008 02:07:24 GMTAdding InternalsVisibleTo a project's AssemblyInfo.cs will allow other explicitly defined assemblies access to internal members. This is really helpful for unit testing. Example: -------------- [assembly: System.Runtime.CompilerServices.InternalsVisibleTo("UnitTests, PublicKeyToken=123456789abcdef0")] http://www.sturmnet.org/blog/archives/2005/05/10/internalsvisibleto-sn/ http://ayende.com/3377/public-vs-published#comment8http://ayende.com/3377/public-vs-published#comment8Wed, 25 Jun 2008 23:19:01 GMTPetar, I am aware of that. I strongly dislike this method http://ayende.com/3377/public-vs-published#comment7http://ayende.com/3377/public-vs-published#comment7Wed, 25 Jun 2008 21:19:02 GMTAyende, you can test internal members if you make test assembly a friend assembly (with InternalsVisibleToAttribute) http://ayende.com/3377/public-vs-published#comment6http://ayende.com/3377/public-vs-published#comment6Wed, 25 Jun 2008 21:16:41 GMTandrey, Internal is a bad solution, it means that you are only exposing things to the current assembly. Testing, advance scenarios needs that access as well http://ayende.com/3377/public-vs-published#comment5http://ayende.com/3377/public-vs-published#comment5Wed, 25 Jun 2008 20:19:24 GMTI've used the "Interface as published" thing before on my projects. I had class with a HUGE set of public methods being passed around, and I finally went around partitioning them into separate iterfaces, and rewriting the client code to accept only the narrowed interface. This worked wonders. I was able to componentize the kitchen-sink class and finally refactor the responsibilities into wherever they needed to go, rather than in the kitchen-sink. It helps intellisense within the client code too, as I only see those methods which I "ought" be using, instead of everything the class has. http://ayende.com/3377/public-vs-published#comment4http://ayende.com/3377/public-vs-published#comment4Wed, 25 Jun 2008 20:06:02 GMTcongrats, you've discovered OOP! ;) http://ayende.com/3377/public-vs-published#comment3http://ayende.com/3377/public-vs-published#comment3Wed, 25 Jun 2008 20:04:39 GMTI use this all the time for my repository and service classes. It allows me to use property injection without publishing the public properties. I can still access those properties if I want to, but they aren't a part of the "published" interface to those classes. http://ayende.com/3377/public-vs-published#comment2http://ayende.com/3377/public-vs-published#comment2Wed, 25 Jun 2008 19:44:45 GMTI think it's exactly what 'internal' is for. I always make things like UserRepository internal. http://ayende.com/3377/public-vs-published#comment1http://ayende.com/3377/public-vs-published#comment1Wed, 25 Jun 2008 19:24:18 GMT