properties vs. fields... again

re: properties vs. fields... again

Miral — Fri, 09 Feb 2007 03:23:35 GMT

The factory should probably be a standalone class, rather than a subclass of MyClass. Then you can make the factory public and MyClass private, and then you're free to do whatever the heck you want with MyClass (including renaming it or deleting it).

At least as long as it's not binary serializable, anyway.

re: properties vs. fields... again

jaybaz_MS — Fri, 09 Feb 2007 04:16:27 GMT

Good call, Miral.

This all fits in to the more general statement of "future proofing is hard". :-)

re: properties vs. fields... again

Bjørn Reppen — Fri, 09 Feb 2007 12:39:54 GMT

Hooah! The world is sane after all.

Thanks man. Great post.

re: properties vs. fields... again

Keith Nicholas — Mon, 12 Feb 2007 06:48:56 GMT

---

I have to write too much code for my code to be future proof so therefore I write non future proof code because I have the foresight to see the future for this code?!?

---

Or alternatively, you gamble on the odds of needing future proof code.

Why can't we have a language where we can write simple code that is future proof?

Then we don't need to have these daft arguments about "good" code design / rules.

I think its worth remembering these aren't good design principles, these things are "hacks" around language difficulties. Don't get me wrong, It's not that these ideas are without merit, they certainly help you work within the bounds of C#, but its worth keeping it in mind that they are simply hacks and the "rules/guidance" would disappear if the language allowed you to express what you wanted.

re: properties vs. fields... again

Steve — Tue, 20 Feb 2007 16:59:55 GMT

http://codebetter.com/blogs/jeremy.miller/archive/2007/01/08/Orthogonal-Code.aspx

http://codebetter.com/blogs/jeremy.miller/archive/2006/12/06/On-Writing-Maintainable-Code.aspx

re: properties vs. fields... again

Jeremy — Tue, 20 Feb 2007 22:09:52 GMT

"Constructors lock you in to a type. If you really want binary compatibility, you should stop providing ctors, and start providing factory methods:"

public class MyClass

{

MyClass() { }

public static MyClass New() { return new MyClass(); }

}

You don't need to do this. Just use Constructor Injection to push in IMyClass instances into the dependent classes, then use an IoC tool if you want to do the mechanical work.

You'll end up with potentially more flexibility without having to go out of your way when you're building classes.