Both C# and Java Are
"Pure" Object-Oriented Languages
Any class in either language implicitly (or explicitly) subclasses an
object. This is a very nice idea, because it provides a default base class for
any user-defined or built-in class. C++ can only simulate this support through
the use of void pointers, which is problematic for many reasons, including type
safety. Why is this C# and Java addition good? Well, for one, it allows the
creation of very generic containers. For example, both languages have
predefined stack classes, which allow application code to push any
object onto an initialized stack instance; then call pop later, which
removes and returns the top object reference back to the caller—sounds like the
classic definition of a stack. Naturally, this usually requires the developer
to cast the popped reference back to some more specific object-derived class so
that some meaningful operation(s) can be performed, but in reality the type of
all objects that exists on any stack instance should really be known at
compile-time by the developer anyway. This is at least because it is often
difficult to do anything useful with an object if the class's public interface
is unknown when later referencing some popped object. (Reflection, a
very powerful feature in both languages, can be used on a generic object. But a
developer would be required to strongly defend its use in this scenario
Both C# and
Java have support for formal exception handling, like C++. Why do people feel
the need for exception handling, though? After all, languages exist that do not
have this support, and developers are able to write code with these languages
that works correctly. But just because something works doesn't mean that it's
necessarily good. Creating functions using formal exception handling can
greatly reduce code complexity on both the server and client side. Without
exceptions, functions must define and return some invalid value in place of a
valid one just in case preconditions are not met. This can be problematic since
defining an invalid value may remove at least one otherwise valid item in the
function range. And it can be messy because the client must then check the
return value against some predefined invalid one. (Other solutions have been
tried, among them: 1) add an extra non-const Boolean reference to every
function call, and have the method set it to true if success else false. 2) Set
a global parameter, for at least the calling thread's context, which defines
the last error that a client can test after function calls. These are far from
satisfying, and they may require an application developer to have too much
knowledge about how things work "under the covers.")
No comments:
Post a Comment