Re: Creating a "public only" constructor

Is InvoiceItem ever instantiated other than from inside the Invoice class?  If so then surely the solution is simply to remove the default constructor from InvoiceItem, forcing Invoice to always use the 1-parameter constructor (this parameter could be null if Invoice itself was instantiated without a server name) - you'll then have to do some refactoring within Invoice, but that's only one class.

Even if InvoiceItem is instantiated elsewhere, could you not do the same technique - this would simply require - roughly speaking - a global substitution everywhere else in the code of
    new InvoiceItem() 
with
   new InvoiceItem(null)

Which seems plausible even with 3 million lines of code, no?

Simon

On Mon, 6 Apr 2009 22:12:12 +1200, Dean Cleaver <[email protected]> wrote:

>It is template based - but a bespoke generator.
>
>"As is't the default ctor you're worried about, it's easy to spot with search/replace"
>
>Not with over 500 classes in 3 million lines of code it's not.
>
>There is no order of constructors. The "normal" apps which consist of about 5 Windows Applications and 15 to 20 Web applications always use the defaults, as has be the case for the past 8 or 9 years. Using the defaults causes the underlying class factory to use the defaults also, which is perfect for those apps.
>
>The scenario we have is we need to instantiate the same class on 2 different servers, and clone one to the other. My issue is if I instantiate an Invoice class using the second constructor to point it directly to it's server, that the existing code might not point all child objects to the same server if they call the default constructor. And there is 8 to 10 years worth of code already in there, so there is a *VERY* high chance that it uses the default constructor. Hence why I was looking for a way to "block" the default constructor from being used insite the assembly.
>
>Trust me - if the default cannot be blocked, then there are no other options. Search and replace is not an option. Even putting attributes or demands on the constructors requires someone to hand code all 500 constructors...
>
>Dino
>
>-----Original Message-----
>From: Discussion of advanced .NET topics. [mailto:[email protected]] On Behalf Of Frans Bouma
>Sent: Monday, 06 April 2009 20:34
>To: [email protected]
>Subject: Re: [ADVANCED-DOTNET] Creating a "public only" constructor
>
>> If it were a new design yes - but it's not. The code generation has
>allowed
>> for this separate server capability, but I fear it cannot be utilised
>fully
>> because the code was historically never designed to work with it, and
>> without hundreds of hours of trawling through the current codebase it
>can't
>> be successfully changed to a class factory type scenario.
>
>	If the code generation was template based, you might be able to do
>something about it, but I'm not sure how it's generated.
>
>	Refactoring the code might be simpler than you might think. As is't
>the default ctor you're worried about, it's easy to spot with
>search/replace. if you load the codebase into vs.net, and do find/replace in
>files, and replace the call to the empty ctor to a call to a factory, the
>only thing that's to solve after that is the references to the right
>namespace where the factory is located. You can also spot calls to the
>second ctor with a simple regex in the find/replace dialog in vs.net. 
>
>	But I still don't fully understand what the order is in which the
>ctors are used. As I understand it, it seems that if I want to instantiate
>an invoice, I use the empty ctor of Invoice. And if I want to instantiate an
>invoiceitem, I use the parameter-using ctor in invoice, and you want to
>prevent that the invoiceitem empty ctor is used, correct? 
>
>	If you replace calls to both ctors to a call to a factory and make
>both ctors internal, you have full control over when what is called.
>However, I am a bit puzzled why the empty ctor is supposed to be public if
>instantiating an invoiceitem is always dependent on the invoice itself (as
>instantiating it on the same server as the invoice is always the best idea)
>
>		FB 
>
>> 
>> Dino
>> 
>> -----Original Message-----
>> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
>> [email protected]] On Behalf Of Frans Bouma
>> Sent: Monday, 06 April 2009 19:57
>> To: [email protected]
>> Subject: Re: [ADVANCED-DOTNET] Creating a "public only" constructor
>> 
>> Dean,
>> 
>> I have the feeling the concern whether OTHER objects are created on the
>same
>> server is not the concern of the class you want to instantiate but the
>> concern of a repository or other object. I know you're facing a large pile
>> of code, but you have to make a change somewhere anyway. I'd factor out
>this
>> concern from this class and create factories to produce the proper
>instances
>> on the right server/service.
>> 
>> 	FB
>> 
>> > Hmm - yeah. Not a bad idea... but would mean that only the Business
>> Services
>> > layer would ever compile in that release, and everything else would
>fail.
>> >
>> > -----Original Message-----
>> > From: Discussion of advanced .NET topics. [mailto:ADVANCED-
>> > [email protected]] On Behalf Of Dave Jones
>> > Sent: Monday, 06 April 2009 19:31
>> > To: [email protected]
>> > Subject: Re: [ADVANCED-DOTNET] Creating a "public only" constructor
>> >
>> > Wrap the constructor in a #if release?   Then it won't be available in
>> > debug?
>> >
>> > Dave
>> >
>> >
>> >
>> >
>> > -----Original Message-----
>> > From:         Dean Cleaver <[email protected]>
>> >
>> > Date:         Mon, 6 Apr 2009 16:02:43
>> > To: <[email protected]>
>> > Subject: Re: [ADVANCED-DOTNET] Creating a "public only" constructor
>> >
>> >
>> > The second constructor allows you to create a business services object
>> > on
>> a
>> > different connection to the default - so I can specifically create
>> business
>> > services objects connected to 2 different servers from within the same
>> > application. I then want to ensure that if I create an Invoice object
>> > on a given server, than any InvoiceItems it creates are on the same
>> > server,
>> which
>> > would be done by using the second constructor. If a developer
>> > accidentally uses the default constructor, it could make a mess of the
>> system.
>> >
>> > -----Original Message-----
>> > From: Discussion of advanced .NET topics. [mailto:ADVANCED-
>> > [email protected]] On Behalf Of Shawn Wildermuth
>> > Sent: Monday, 06 April 2009 15:55
>> > To: [email protected]
>> > Subject: Re: [ADVANCED-DOTNET] Creating a "public only" constructor
>> >
>> > I don't think you can.  Can you explain why you want to protect it
>> > from internal classes?
>> >
>> > Thanks,
>> >
>> > Shawn Wildermuth
>> > http://wildermuth.com
>> > https://agilitrain.com
>> > Microsoft MVP (C#), MCSD.NET, Author and Speaker
>> >
>> > The Silverlight Tour is coming to a city near you!
>> >
>> >
>> > -----Original Message-----
>> > From: Discussion of advanced .NET topics.
>> > [mailto:[email protected]] On Behalf Of Dean
>> > Cleaver
>> > Sent: Sunday, April 05, 2009 11:42 PM
>> > To: [email protected]
>> > Subject: [ADVANCED-DOTNET] Creating a "public only" constructor
>> >
>> > Hey, anyone know if you can do this with attributes or something? I
>> > want
>> to
>> > have 2 public constructors:
>> >
>> > public ClassName()
>> > {
>> > }
>> >
>> > public ClassName(some param)
>> > {
>> > }
>> >
>> > I want both publically accessible, but I want the default one
>> *inaccessible*
>> > internally. Can that be done?
>> >
>> > Dino
>> >
>> > ===================================
>> > View archives and manage your subscription(s) at
>> > http://peach.ease.lsoft.com/archives
>> >
>> > ===================================
>> > View archives and manage your subscription(s) at
>> > http://peach.ease.lsoft.com/archives
>> >
>> > ===================================
>> > View archives and manage your subscription(s) at
>> > http://peach.ease.lsoft.com/archives
>> >
>> > ===================================
>> > View archives and manage your subscription(s) at
>> > http://peach.ease.lsoft.com/archives
>> 
>> ===================================
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>> 
>> ===================================
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>
>===================================
>View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives
>
>===================================
>View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives