Re: [Springnet-developer] Object creation invokingprotectedconstructors?
Brought to you by:
aseovic,
markpollack
Menu
▾
▴
Re: [Springnet-developer] Object creation invokingprotectedconstructors?
|
From: Erich E. <E.E...@di...> - 2007-09-12 15:54:08
|
Hi Stephen, =20 agreed that these circumstances exist and I'm pretty sure that everyone = is already more or less convinced, that Spring.NET should support them. = Means +1 from me for supporting non-public classes and their members = (ctor, method, props). =20 What I was trying to say - and I think Mark as well - is, that it drives = your design positively if you place your tests in another assembly, = because the need for testing internal classes is more an exception than = the usual case. Sometimes you find, that you can't test a class because = it is internal - which in general (at least to my experience) is a sign = to rethink the design or it is an implementation detail. I remember when = starting TDD myself, I placed my tests into the same assemblies for the = same reasons you described here. The danger you run into when doing this = is that you might easily overlook that you are testing implementation = details - which makes it hard to change these details later. A lot of = tests later I'm convinced that it is an important instrument for = improving the API of my classes to place the tests into their own = assembly. =20 cheers, Erich ________________________________ From: Trudel, Stephen [mailto:ste...@ba...]=20 Sent: Wednesday, September 12, 2007 2:50 PM To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer Subject: RE: [Springnet-developer] Object creation = invokingprotectedconstructors? =09 =09 Mark, =20 As we all know, the whole point is to allow separation the abstraction = from its implementation so the two can vary independently (GoF, Bridge = Pattern) ... that is great and I am glad Spring helps to apply this = pattern declaratively. =20 The question is one of scope. By design do we want client code outside = the physical assembly ("external code") to inject implementations? The = answer to this question is rarely yes in my opinion so I agree with you. = =20 =20 - Maybe allowing external code to inject would do more harm than good. = Rare? Yes.=20 - Maybe it just does not make sense for external code to provide the = implementation but for testing purposes the developer want to swap in a = separate mock implementation.=20 - etc =20 I think a more important question is do these circumstances exist? I = think they do. =20 =20 I did not interpret your email as aggressive at all with regard to unit = test placement. =20 =20 Regards, Stephen ________________________________ From: Mark Pollack [mailto:mpo...@in...]=20 Sent: Tuesday, September 11, 2007 6:23 PM To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; = 'springnet-developer' Subject: RE: [Springnet-developer] Object creation = invokingprotectedconstructors? =09 =09 Hi Stephen, =20 Yup, at your own risk pretty much summarizes what I think is going on = here. I'd hope that this is a rare case since if one was developing an = API for public consumption one would assume it has enough functionality = marked as public so that it is amenable to instantiate configuration via = its public API, either via 'new' or via dedicated factory objects. I = also see your point with environments putting constraints on where test = cases reside, I wasn't trying to imply a 'best way' as usually the best = way is dependent on many many things, such as how you migrate to PROD, = shipping policies...sometimes it is just the whim of a point-haired = manager J Anyway, I realize my email might have been a bit = terse/aggressive, that wasn't my intention, just trying to sneak in a = few emails on my vacation. =20 Cheers, Mark =20 =20 =20 =20 =20 =20 From: Trudel, Stephen [mailto:ste...@ba...]=20 Sent: Tuesday, September 11, 2007 2:52 PM To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer Subject: RE: [Springnet-developer] Object creation = invokingprotectedconstructors? =20 Mark, =20 I think most of us agree if developers are invoking non-public members = on classes they did not create then they are doing so at their own risk. = I think there is an argument that perhaps is being overlooked or I did = not read everyone posts carefully. If so I apologize. Consider if you = are the class designer, your classes have internal members by design, = and today you are NOT using Spring. Tomorrow you decide to use Spring = and you now have to change your class design. That seems intrusive. =20 =20 I really like your idea for top level attribute to the objects element = ... its explicit. =20 =20 Whether the tests can shipped to production or not depends in part on = if you promote source or promote binaries through the promotion = pipeline. Our releases (QA, UAT, PROD) are done by another group who = for audit reasons CANNOT promote binaries (rule only applies to PROD but = we follow the same process regardless). This group must build the = application from version control. Based on certain conditions (e.g. = non-DEV build) we can turn on or off a compilation switch resulting in = our unit tests being excluded from a release. There are other = approaches to achieve this exclusion as well. Clearly there are = tradeoffs to consider. In my experience no one has convinced me that = tests residing in the same assembly is a bad practice. =20 Regards, Stephen =20 ________________________________ From: Mark Pollack [mailto:mpo...@in...]=20 Sent: Tuesday, September 11, 2007 1:42 PM To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; = 'springnet-developer' Subject: RE: [Springnet-developer] Object creation = invokingprotectedconstructors? Hi, =20 I can see the +'s of allowing it, i.e. if a developer *really* needs to = go under the covers to get something to work, we shouldn't get in the = way, and the -'s of doing it, you subvert the intention of the original = designer of the class. How about we provide a top level attribute to = the <objects> element that allow for one to call protected constructors = and appropriate API changes to the context classes. This way, the = default is not to allow it, but if you need it, the requirements is made = explicitly and the contract is global. It also keeps the solutions = simple, i.e. not per object functionality. =20 An additional question, should one also allow calling of protected = properties, private ctor/properties? Probably something along the lines = of xor'ing of binding properties would make sense if we want to go down = that path. =20 =20 I'd guess that in some cases, people don't like having the test .dll = dependencies within the 'production' assembly that gets shiped to = clients, so tests are placed in a separate assembly. =20 =20 Cheers, Mark =20 =20 =20 =20 From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Trudel, Stephen Sent: Tuesday, September 11, 2007 8:19 AM To: Erich Eichinger; Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation = invokingprotectedconstructors? =20 The goals of TDD can be achieved as easily when the tests are inside = the assembly. =20 =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Erich Eichinger Sent: Tuesday, September 11, 2007 8:10 AM To: Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation = invokingprotectedconstructors? Hi, =20 Personally I'm also not a big fan of making everything internal. Even = more, I think that writing tests for my classes *outside* the assembly = is a really good way for driving the design. I *want* my tests to = influence the design (that's what TDD is all about I guess).=20 =20 Although I think Spring should somewhat enforce what we think are best = practices, the world is not always ideal and there are situations where = I wished that Spring supported accessing non-public code. =20 -Erich =20 =20 =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Bruno Baia Sent: Tuesday, September 11, 2007 2:02 PM To: Erich Eichinger Cc: springnet-developer Subject: Re: [Springnet-developer] Object creation = invokingprotectedconstructors? Hi, =20 To do that, Microsoft uses their new feature in .NET 2.0 : the = InternalsVisibleTo attribute to specify the assembly to which all = nonpublic types are to be made visible. (Take a look to = System.ServiceModel.dll for an example.)=20 I've also read somewhere MS uses reflection to testes non visible = classes too. =20 Anyway, I'm really not a fan of that InternalsVisibleToAttribute = because everything becomes internal now... =20 =20 Bruno =09 =20 2007/9/11, Erich Eichinger <E.E...@di...>:=20 Hi Stepen, =20 playing the "advocatus diaboli" now: How do you write tests for this = class then? If your design does not allow for instantiating the class, = why should Spring be allowed to?=20 =20 -Erich =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected = constructors? =09 =20 Related question ... does Spring.Net support object construction for = objects with internal constructors? If one does not want the = instantiation of an object to be allowed outside the scope of a module = for purposes of conceptual integrity or otherwise then Spring.Net = should support its construction in my opinion ... seem somewhat awkward = when class design is influenced by a framework ...=20 =09 =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected = constructors? =09 =20 Steinar on the forum asked this here: = http://forum.springframework.net/showthread.php?t=3D3448 =20 I'd like to revisit the design decision to not allow accessing = non-public types/constructors/methods/properties and hear your opinions = on this.=20 =20 I recently ran into this issue myself when trying to provide a DI = capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web = assembly. This type is internal and can't be instantiated using Spring = which required to implement a (non-trivial) workaround. The easy way = would be to remove the restriction to public types.=20 =20 I know of opinions out there to don't enforce any restrictions within = the framework. Developers should know what they are doing and if someone = wants to instantiate a non-public type, let him do it at his own risk.=20 =20 Other opinions? =20 cheers, Erich =20 =09 = -------------------------------------------------------------------------= This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.=20 http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________=20 Springnet-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springnet-developer =20 |
