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