Some interesting points... > Inheritance may make sense as you point out, but I think it is more often > than not used as a way to avoid the #region mess. One pro argument is that
> you do not need to basically double the number of classes just to add some > custom code. I do agree it is not a silver bullet by any mean. Agreed, the extra classes are a bit of an eyesore, and do add some unnecessary noise to the code / documentation. > I think using inheritance merely for separating generated code from custom > code is not the intended purpose of inheritance, i.e. the 'is-a' > relationship is not kosher, when it says class Derived is-a-piece-of class > Base, i.e. the 'is-a' relationship is no longer an object oriented one > w.r.t. the domain. I see your point, although I can convince myself that a "Person" is-a "PersonBase" enough to not have too much problem with this. It might not be squeaky clean, but there is a line between "perfection" vs pragmatism that I need to draw somewhere, otherwise I'd never get anything done :) > There's another problem: parallel hierarchies. > Say you have Customer and Order. Customer has a List<Order> property called > Orders. > say you now subclass Customer and Order to add implementation. The 'Orders' > property still has a type of List<Order>, not List<SubtypeOfOrder> I haven't thought of this in the context of actual parallel hierarchies, as such. Typically, I make use of code generation in relatively straightforward business applications, where time pressures and productivity dominate, rather than future-proofing and quality (I'm not saying those are not possible to achieve using code-generation, just that they are often not the primary concern for most clients, however sad that might be). As such, deep inheritance is almost never done (well, at least not on the business objects themselves). We side-step the issue of having to continuously type-casting stuff by: 1) Always having a subclass paired with a base class, even if it's essentially empty (it can even be generated by a code generator initially). This way, you can reference the subclass's type by default. 2) The base class uses generics to be informed of the subclass's type. Essentially, this means that properties and methods that would have returned an object of the base type, can now return the subclass's type, decreasing the need for type casting. Far from perfect, I agree, but within my threshold of "good enough". I suspect this would not work particularly well if the inheritance hierarchy was any deeper than 1 (ignoring any classes you build the base classes on top of). Thanks again for your inputs, I am a little more convinced of partial classes now :) -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Frans Bouma Sent: 28 July 2008 03:06 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] The effects of ORM in architecture and domain driven design > > I'm a little bit surprised that everybody seems to be saying that > > partial > > classes > inheritance. I'm not saying that inheritance is a perfect > > fit for > > the whole "reverse engineer DB into a persistence layer" scenario, but > > I > > prefer to at least have some buffer between the generated code and the > > business logic. There are certain things in the generated code that > > you > > should see / touch, and inheritance helps ensure that you do not. In > > cases > > where you do need to do muck around with the plumbing, the override > > keyword > > at least helps indicate that you have done so. > > > > What good arguments pro-partial classes am I missing? > > > > -- Daniel. > > I think using inheritance merely for separating generated code from custom > code is not the intended purpose of inheritance, i.e. the 'is-a' > relationship is not kosher, when it says class Derived is-a-piece-of class > Base, i.e. the 'is-a' relationship is no longer an object oriented one > w.r.t. the domain. There's another problem: parallel hierarchies. Say you have Customer and Order. Customer has a List<Order> property called Orders. say you now subclass Customer and Order to add implementation. The 'Orders' property still has a type of List<Order>, not List<SubtypeOfOrder> FB =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
