Partial classes not good OO design

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Does Microsoft even bother involving developers anymore in their process of
developing new "features"?

I've spent about four hours with VS2005 now and can't believe the list of
problematic improvements I've generated in that short time.

Then I run across this partial class feature. What a mind bending stupid
idea. This isn't an object oriented concept at all - it's very much akin to
using a preprocessor to insert code.

The ability to "hide" code is pretty much covered by the OO model - it's
called encapsulation. Hiding UI code is the reason given for this
"innovation". What happened to patterns such as MVC? Even a UI helper class
would be a better idea. UI code could have been placed in a generated class
which is then included as a member in the developer's "business" logic class.
At least there would be a clear separation of function with this approach.

Splitting code for a single class into multiple files is such an obvious,
bad, hack. It seems to me the last resort to solving a programming problem is
to change the underlying language specification. What a horrible precedent
to set. Microsoft language "architects" ought to be really ashamed of
themselves for permitting this feature to be added to the .Net language
syntax.

IMHO,
Mike O'Shea
Logicalis
 
oshea00 said:
Then I run across this partial class feature. What a mind bending stupid
idea. This isn't an object oriented concept at all - it's very much akin to
using a preprocessor to insert code.
Click to expand...

It's totally about hiding the code generated by machines, it isn't
really for human use. One problem with using inheritance for this
specific purpose is that the human driving the process may want some
generated members may be private, and thus they wouldn't be accessible
using other techniques.

-- Barry
 
Thanks Barry. The problem with the solution is that it's now a language
feature that can be used for other purposes than hiding machine generated
code. It creates more problems than the one it was intended to solve.

The machine generated code could have been placed in a separate class (where
the private machine generated methods would have relevance) and included as a
member in the "user friendly" class representing the Form.

So, there would be one declaration in the user friendly class that could be
accidentally deleted - a problem easily fixed by adding a check at build time
that could replace the missing line or provide a build error message. But not
much more than that could be done unless the coder wanted to track down the
generated class file and make changes to it directly.

Well, even with the partial class solution, nothing prevents the coder from
editing the generated partial class file. Using the more OO approach above
wouldn't prevent the coder from editing the generated class either - at least
it doesn't require a language spec change on top of everything else.

See what I mean? The "solution" doesn't even solve the problem better than
using a more OO approach already supported by the language.

That's what I'm whining about.
 
Does Microsoft even bother involving developers anymore in their process of
There were various preview and beta builds of VS2005 released years
before it finally shipped. And during that time, I can't recall ever
seeing anyone complaining about this aspect of partial classes. I
think you're the first.


Is that a bad thing? Does every feature necessarily be based on OO to
be useful? Why whould your physical source code distribution have
anything to do with OO?


Other languages such as C++ has supported this for years. Do you think
C++ is a hack too?

Thanks Barry. The problem with the solution is that it's now a language
feature that can be used for other purposes than hiding machine generated
code.
Click to expand...

Almost any feature can be abused, that doesn't necessarily make it bad
when used appropriately.

It creates more problems than the one it was intended to solve.
Click to expand...

What problems do partial classes create?


Mattias
 
Let me see if I get this straight. You're complaining that an *additional
feature,* which, if used correctly, can make the development process much
simpler, is a problem because people can abuse it? Hmm. Perhaps we ought to
apply that to any feature that a developer can abuse. Of course, it we did,
there would be no programming technologies, languages, or developers.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.
 
There is absoluteley NOTHING in the OO paradigm that requires class code be
limited to a single source file. The real question is whether the interface
to the class is secure in that consumers of the class cannot see the
implementation details of the class. Implicit inheritance, by exposing some
of the underlying implementation, is more of a problem in this regard than
splitting the class source across multiple files. Both features, when used
correctly, can improve code and ease of maintainence. Both features, when
used incorrectly, can become the OO paradigm's equivalent to unstructured
GOTOs.

Mike Ober.
 
What I tend to dislike about it (well more the concept) is that it seems to
have only been included to work with Visual Studio! I don't think anything
should be included in a language just to make the editor work (or work
better / worse depending upon your opinion)

- Paul.
 
Partial classes also solve the issue of mixing code and UI elements in
web-projects.

Mike.
 
any code generator can now make use of this feature, including ones you write
yourself. code generators can significantly enhance developer productivity
and any language feature which helps support them is a good thing. i agree
that language evolution should not necessarily be driven by the associated
toolset, but language designers cannot ignore the needs of commercial
developers with regards to productivity.
 
Paul,
You are free to introduce your own partial classes. See partial in VB or C#.

Of course like any language feature it is easy to abuse. As Kevin suggests,
just because you can abuse something doesn't mean its bad. Look at multiple
inheritance in the languages that support it, its been known to be over used
& abused. That doesn't mean that MI is bad where you should use...

In fact they (partial classes) are rather useful in typed datasets, VB My
Settings, Resources... Any generated class that you want to add code to.

Even non-generated classes they can be useful for organization reasons:

I use them to separate nested classes into their own files.

' SomeCollection.vb
Public Class SomeCollection
...
End Class

' SomeCollection.Enumerator.vb
Partial Public Class SomeCollection
Private Class Enumerator
...
End Class
End Class

I also use them to separate out interface implementations that are required
in a specific class.

I've used them in VSTO projects to help organize code.

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| What I tend to dislike about it (well more the concept) is that it seems
to
| have only been included to work with Visual Studio! I don't think anything
| should be included in a language just to make the editor work (or work
| better / worse depending upon your opinion)
|
| - Paul.
|
| | > Thanks Barry. The problem with the solution is that it's now a language
| > feature that can be used for other purposes than hiding machine
generated
| > code. It creates more problems than the one it was intended to solve.
| >
| > The machine generated code could have been placed in a separate class
| > (where
| > the private machine generated methods would have relevance) and included
| > as a
| > member in the "user friendly" class representing the Form.
| >
| > So, there would be one declaration in the user friendly class that could
| > be
| > accidentally deleted - a problem easily fixed by adding a check at build
| > time
| > that could replace the missing line or provide a build error message.
But
| > not
| > much more than that could be done unless the coder wanted to track down
| > the
| > generated class file and make changes to it directly.
| >
| > Well, even with the partial class solution, nothing prevents the coder
| > from
| > editing the generated partial class file. Using the more OO approach
| > above
| > wouldn't prevent the coder from editing the generated class either - at
| > least
| > it doesn't require a language spec change on top of everything else.
| >
| > See what I mean? The "solution" doesn't even solve the problem better
| > than
| > using a more OO approach already supported by the language.
| >
| > That's what I'm whining about.
| >
| > "Barry Kelly" wrote:
| >
| >>
| >> > Then I run across this partial class feature. What a mind bending
| >> > stupid
| >> > idea. This isn't an object oriented concept at all - it's very much
| >> > akin to
| >> > using a preprocessor to insert code.
| >>
| >> It's totally about hiding the code generated by machines, it isn't
| >> really for human use. One problem with using inheritance for this
| >> specific purpose is that the human driving the process may want some
| >> generated members may be private, and thus they wouldn't be accessible
| >> using other techniques.
| >>
| >> -- Barry
| >>
|
|
 
In addtion to what some of the others has said, I believe partial classes
allow some other language features to be possible. I don't remember the
details now, but I believe the LINQ project is possible to implement due to
partial classes. I don't think partial classes were added only to allow
the designer to put code in a separate file.
 
Back
Top