Re: Question concerning object-oriented programming

On Mar 8, 10:25 am, spinoza1111 <spinoza1...@xxxxxxxxx> wrote:
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.

If you close your eyes and someone puts something in your hand, would
you be able to tell what it is? Without fingering it, you might
determine that it is heavy. However, without any other indicator, you
really can't say what it is. That is the point of an object; it is
just a way of handing something to someone. When they are ready to
perform a task on it, they can look at it, feel it, other metaphorical
actions, and determine what it is. This is similar to testing with the
keyword "is". The same goes for interfaces. In my experience, object
is more of a placeholder for a real object, or for syncronization;
someone puts it into something else with the understanding that
someone later will know how to get it back to something useful.


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.

I totally disagree. It is horrible to think that my code would
continue to run in an error state. I would prefer an exception thrown.
Any class I write has a constructor that verifies the input prior to
instantiating the object. It should be IMPOSSIBLE to create an invalid
object. Your example doesn't even handle the more realistic option
where objects become invalid after construction. Again, to inspect
could cost significant time, or be impossible. The main idea behind
algorithms is to find constraints that must ALWAYS be true across all
actions. Classes should be written with the assumption that such
constraints will always be held as true, or exceptions thrown
otherwise. Another option is for methods to return error indicators
and for the class to correct itself (or never be invalidated).
Practice has shown error indicators to be unrealistic for most
projects.


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?

It shouldn't. You should throw an exception. Code is only as mindless
as the person who wrote it, since it doesn't have a mind of its own.
Don't assertions throw exceptions?


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

I'm not sure if you are saying assertions are good or bad, here. I
assume you are saying they are good and should be listened to. Unless
you catch the exception, the assertions are listened to. But again,
you code should be smart enough to detect an error early on and bomb
out.


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

Object would have to be abstract for this to be true. I am sometimes
amazed that you can say new Object() in C#. However, given that the
ToString() method returns a perfectly valid string makes everything
dandy. Again, not all object in C# are Dispose-able. Dispose has a
very special meaning in .NET. It is NOT a destructor! Again, I use
Object as more of a placeholder or even as an indicator. Object is
just where C# says, "This is what all things are guarunteed to
implement. It may not be overly feature rich, but it will make other
things, such as HashTables, easier to implement."


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.

Exposing the state of an object breaks encapsulation. You shouldn't
store and retrieve state information for an encryption algorithm. God
forbid! ToString is more often used than not to display user-relevant
information. It is almost never used to spew out the class's internal
state. Most classes should use the default behavior of ToString.


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

Different testing environments perform testing differently. Some
objects are non-constructable (private ctor or static class). You
can't be so static about something like a test method since it may not
work for everyone. That is a decision better left to the standards
within a company.


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

You must get a lot of people arguing with you. That is probably
because you make statements that are far reaching and too concrete. In
your case, I would listen to what other people are saying. Programming
languages don't pop up overnight. There are well-paid professionals,
with more years of experience than I have been alive, who spend
thousands of man-hours developing such systems. It can be somewhat
easy to make a list of rules that work well for an organization, but
it is almost impossible to make them for a global community. I was
able to find multiple reasons why your statements above could be
problematic for some people.

If I didn't reply to any of your statements correctly, it is because
you have bad sentence structure. A big part of making yourself heard
is to speak well. I'm not saying you need to work on your commas and
semicolons, just that you need to make more structured arguments.
Sorry if you think I am being rude.
.