Re: [Springnet-developer] Object creation invokingprotectedconstructors?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Mark,

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.

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.

- Maybe allowing external code to inject would do more harm than good.
Rare?  Yes. 
- 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. 
- etc

I think a more important question is do these circumstances exist?  I
think they do.  

I did not interpret your email as aggressive at all with regard to unit
test placement.  

Regards,
Stephen

________________________________

From: Mark Pollack [mailto:mpo...@in...] 
Sent: Tuesday, September 11, 2007 6:23 PM
To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
'springnet-developer'
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?

Hi Stephen,

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.

Cheers,

Mark

From: Trudel, Stephen [mailto:ste...@ba...] 
Sent: Tuesday, September 11, 2007 2:52 PM
To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?

Mark,

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.  

I really like your idea for top level attribute to the objects element
... its explicit.  

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.

Regards,

Stephen

________________________________

From: Mark Pollack [mailto:mpo...@in...] 
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,

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.

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.   

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.   

Cheers,

Mark

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?

The goals of TDD can be achieved as easily when the tests are inside the
assembly.  

________________________________

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,

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). 

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.

-Erich

________________________________

	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,

	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.) 

	I've also read somewhere MS uses reflection to testes non
visible classes too.

	Anyway, I'm really not a fan of that InternalsVisibleToAttribute
because everything becomes internal now...

	Bruno

	2007/9/11, Erich Eichinger <E.E...@di...>: 

	Hi Stepen,

	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? 

	-Erich

________________________________

		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?

		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 ... 

________________________________

		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?

		Steinar on the forum asked this here:
http://forum.springframework.net/showthread.php?t=3448

		I'd like to revisit the design decision to not allow
accessing non-public types/constructors/methods/properties and hear your
opinions on this. 

		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. 

		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. 

		Other opinions?

		cheers,

		Erich

------------------------------------------------------------------------
-
	This SF.net email is sponsored by: Microsoft
	Defy all challenges. Microsoft(R) Visual Studio 2005. 
	http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
	_______________________________________________ 
	Springnet-developer mailing list
	Spr...@li...
	https://lists.sourceforge.net/lists/listinfo/springnet-developer