Ayende @ Rahien

Daniel Cazzulino commented on The buddy classes are drowning DRY

Tue, 16 Jun 2009 05:06:34 GMT

Why don't they just allow you to annotate the interface itself with the contracts rather than having to maintain the "buddy" ?

ReSc commented on The buddy classes are drowning DRY

Sun, 31 May 2009 02:44:07 GMT

@ Daniel To quote the post you link to: "Since interfaces cannot have a method body, we use a ‘buddy’ class to express those contracts". So you only need to use a 'buddy' class for interfaces, classes don't need them, because there the contracts can be expressed in the methods directly, no buddy class needed. and to top it off "All implementations of that particular interface will be instrumented with the runtime checks by the rewriter at compile time." excellent DRY instead of buddy hell methinks...

Daniel Cazzulino commented on The buddy classes are drowning DRY

Tue, 19 May 2009 14:10:23 GMT

Want more buddy hell? [blog.dotnetwiki.org/.../...odelsWithContracts.aspx](http://blog.dotnetwiki.org/2009/05/02/StubsAsParameterizedModelsWithContracts.aspx) Code contracts is another official feature coming out of MS that encourages the same practice.

Brian Henderson commented on The buddy classes are drowning DRY

Wed, 06 May 2009 03:58:50 GMT

It's one thing to be lazy about design in writing application code; HOWEVER being lazy with Framework Design can lead to structural failures across many applications going forward. Beyond the DRY rot, there is a serious loss in readability and communication of intent, as behavioral abstractions have leaked out of MyClass. The CLI team needs to revisit Properties with .NET 5. The issue of tooling (IDE & compiler) for Attributes and ChangeNotification (XAML binding) including wiring up events (particularly with partial classes).

Peter Morris commented on The buddy classes are drowning DRY

Tue, 05 May 2009 20:02:00 GMT

It's a heap load of connascence, and that's certainly a bad thing!

Gunnar Liljas commented on The buddy classes are drowning DRY

Tue, 05 May 2009 16:21:29 GMT

It's getting a bit old with these NIH/ their code sucks posts. At least when "there are other ways of doing that" is not followed by any suggestions on how to do it better. I certainly agree that the code smells, but it's a working solution to a problem caused by an oversight in the language. The MetadataClass is akin to a FNH mapping class, although the relation between the classes is decorated to the primary class. A FNH approach could be better, but the discovery process requires a bit more from the framework. public class MyClassMetaData : MetaData x.MyProperty,1,100); } >

Eddie Garmon commented on The buddy classes are drowning DRY

Tue, 05 May 2009 15:33:48 GMT

I have no idea why they didn't do something like the way Design attributes are broken out in WPF, and use something similar to 'IRegisterMetadata'. Insanely simple, very DRY, and doesnt interfere with either the generation tool, or the generated code. it also avoids the double inheritance paradigm, which is also just another 'work around'.

Stephen commented on The buddy classes are drowning DRY

Tue, 05 May 2009 15:19:31 GMT

@Dave, ok but I'm not sure how that effects what I said- my comment was purely that XML and especially buddy classes are imperfect for attributing data (and I'm not specifically talking about System.Attribute, I'm talking generally about how members can have data attached to them).. The most simplistic example I could give was.. I have this 'fact' about property X.. how do I let people find that? attributes would be a good way, but what if I cannot attribute it.. tons of systems have this requirement but there seems to be three main ways people do this: attributes (not always possible but good), xml/config (great but the compiler won't help you anymore).. or by directly interacting with the related service (such as fluent interfaces) I'm wondering if theres a better way..

Dave commented on The buddy classes are drowning DRY

Tue, 05 May 2009 13:13:37 GMT

@Stephen: The problem is not the generation of code with or without attributes. If you have ever programmed WinForms in .net 1.x VS generated code in the same file as you was writing your code. Partial classes were introduced into .net 2.0. Using a partial class to separate generated code from user written code seems a good thing at first. Most problems in 1.x were not related to the generated code, but generated code changed by the user that needs to be parsed back for use with a designer. As I wrote earlier, Dynamic Data was probably better off implementing the visitor pattern. And what about keeping to two classes in sync when the data model changes.. Another benefit when using the visitor pattern is that the developer has auto completion and (code) validation at compile time. Maybe David Hayden should give a few P&P presentations to some Microsoft architects?

Stephen commented on The buddy classes are drowning DRY

Tue, 05 May 2009 09:03:37 GMT

Buddy classes and XML both seem to promote not getting compile time help.. maybe .NET needs a better (consistent) story for 'stood off' data attributing.

Anon commented on The buddy classes are drowning DRY

Tue, 05 May 2009 08:01:46 GMT

Having an external XML file still violates the DRY principal doesn't it?

Dave commented on The buddy classes are drowning DRY

Tue, 05 May 2009 06:59:40 GMT

If you're writing a buddy class just to add some behavioral attributes, XML is a much cleaner way. In the example Oren has given (validation) the visitor pattern should have been used. When Microsoft started asp.net MVC, I thought yeah, they are finally gonna start using patterns and practices themselves instead of advocating them to the world. But it was just a fluke. Just my 2 cents

configurator commented on The buddy classes are drowning DRY

Mon, 04 May 2009 23:24:29 GMT

Couldn't agree more.

James Newton-King commented on The buddy classes are drowning DRY

Mon, 04 May 2009 23:02:45 GMT

I think they are laziness on the part of the tool that is generating the code. The tool should provide hooks to add attributes without a clunky solution like this.

Ayende Rahien commented on The buddy classes are drowning DRY

Mon, 04 May 2009 22:43:15 GMT

Andrey, I actually really like NH's XML style.

Nigel Sampson commented on The buddy classes are drowning DRY

Mon, 04 May 2009 21:08:14 GMT

Thankfully in Dynamic Data (not sure about RIA Services yet) you can replace the Metadata provider to something else if you'd like (xml, fluent interface etc).

Andrey Shchekin commented on The buddy classes are drowning DRY

Mon, 04 May 2009 21:04:26 GMT

Well at least there *is* a way to solve the problem (customize the metadata of original classes). I do not like it much, but I can not really criticize the idea (after all, NHibernate was using *XML* for similar task for years and most people were ok with that). What approach would you prefer? I would say use lambda expressions, hopefully they will get to that. Otherwise, double-derived works pretty well, I was always using it for any codegen I did.

PeteGoo commented on The buddy classes are drowning DRY

Mon, 04 May 2009 20:10:26 GMT

Hi found this one pretty horrible as well when I seen Mikes post. Funny thing is the MS DSL tools have their own, much better, solution to this problem, i.e. the double-derived pattern.

Kelly Stuard commented on The buddy classes are drowning DRY

Mon, 04 May 2009 20:08:55 GMT

It is a huge mistake taking this "buddy" class approach. If only they had extended the tools to allow the flexibility to add attributes to properties. The whole thing sets off a South Park line: "I'm not your buddy, pal. I'm not your pal, friend."

Mark Nijhof commented on The buddy classes are drowning DRY

Mon, 04 May 2009 20:08:19 GMT

wow buddy classes, I hadn't heard of it yet, but this looks ugly. Hope too never see it again.

Damien Guard commented on The buddy classes are drowning DRY

Mon, 04 May 2009 19:55:22 GMT

You're not the only one hating buddy classes - an ugly hack that presumably was quicker than doing the proper thing. [)amien