Question concerning object-oriented programming

I haven't done a lot of reading about "design patterns" so this may or
may not be a related issue.

My question is why does it always seem necessary in OO for .Net to
decorate objects with state (class level variables) with a bunch of
extra procedures such as toString() and dispose()?

[My list is longer as seen in my book Build Your Own .Net Language and
Compiler.]

[I will try to ignore replies such as "because you're a dip ***".
Grow up.]

That is: there seems to be a consensus that the ancestor Object should
be without qualities or procedures.

Whereas I believe that all non-stateless objects should have a Usable
property and an inspect() method. If at the end of the constructor the
inspect() of the state fails to verify key assertions, actual objects
should mark themselves Unusable and thereafter all procedures should
take an early exit, and properties and methods returning values should
return defaults such as zero, a null string, or null.

Why should the code of an object instance mindlessly grind on,
allowing itself to be called again and again, when another part of the
code has found an assert violation?

"Run time asserts are a waste of time". But Stroustrup says why would
you leave a harbor without lifejackets? Didn't something like that
happen on the Titanic?

Therefore Object should expose abstract and unimplemented toString(),
dispose() (which is an issue in .Net), Usable and inspect.

Theory. Any Object should have a toString() and a palindromic
fromString() which restores the object state from the toString, which
would, in this scenario, create a readable but complete state, perhaps
in XML.

Any Object should have an implementable static test() method which
would create an instance of the object and run a test.

Etc. Comments welcome: flamers may flame and be damned.
.

Quantcast