Re: Question concerning object-oriented programming

spinoza1111 wrote:

On Mar 9, 12:41 am, santosh <santosh....@xxxxxxxxx> wrote:
spinoza1111 wrote:

<snip>

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.

Better yet the constructor could throw an exception.

What if the object creator ignores the exception?

Then this is a gross programming error. In the interim the unhandled
exception (if it is of a properly chosen type) will most likely
terminate the program, but in the only real solution is to fix the
program to handle the InvalidObject exception.

Object-orientation gives code a new level of awareness. A stateful (as
opposed to stateless) object can know if it is in an invalid state.
Why not use this fact?

Yes, but we are debating about how the object should act upon this
knowledge. Should it raise an exception and put the burden on the
caller? Should it take crude and drastic action like say, calling
exit() or abort()? Should it merely mark itself as invalid?

And what exactly does this marking itself as invalid do? How will this
invalid object respond if it's creator ignores this and calls a method
on it? Should the compiler automatically invoke the destructor for the
object?

Basically, when I started OO, I was disturbed by the prospect of
object instances with failed constructors littering memory, like the
melting watches in Salvador Dali's painting "Persistence of Memory",
or T. S. Eliot's "voices singing out of empty cisterns and abandoned
wells".

This won't happen in good code. The handler for CorruptObject or
whatever exception the object raises would presumably destroy the
object or drop all references to it, so that the Garbage Collector can
reclaim it at it's next activation.

But because of the (proper) consensus that garbage collection should
be centralized, objects, like Hamlet, are forbid to self-slaughter:
there is no facility in .Net or Java, that I know of, in which an
object can say destroyMe().

Therefore the object should mark itself Unusable, and any attempt
subsequent to constructor time to use the object should Throw an
error.

How is this any different from the constructor throwing an exeption. As
far as I can tell, it merely delays the moment at which this exception
is thrown.

In any case, a failed object is a serious problem that the rest of the
system must know about, just like the processor in an aircraft must
know about a drop in cabin pressure or another malfunction.

The component can try a corrective action, if possible, but in any case,
it must, I believe, signal the caller that it has failed. This should
occur as soon as possible.

<snip>

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

What exactly would this test method do?

It would create an instance and run a standard series of tests. The
GUI of the class, if it exists, could then have a nifty Test button
which would test the object at any time. Electronic equipment has
nifty test buttons. Why cannot software?

Should the test, as far as possible, be automatic and a matter of
course, rather than dependent upon the operator pressing or not
pressing the Test button?

.