Is Dot Net Really belongs to Object Oriented ?

  • Thread starter Thread starter Reny
  • Start date Start date
R

Reny

Correct me if I am wrong. In an Object Oriented environment each and
everything are objects. That means we cannot directly instantiate a class
nor we can directly reference a member belongs to a class i.e.
ClassName.MethodName ()

If I am right in that sense, we are doing the just opposite in .NET.

For example in the sample Hello World Application given below



Imports System

Class HelloWorld

Public Shared Sub Main ()

Console.WriteLine (“Hello World”)

End Sub

End Class





As per MSDN Console is a Class defined inside the System Namespace. Here we
are directly calling the Method () defined inside the Class Console. How is
this possible in an OO environment?



Reny
 
Reny said:
Correct me if I am wrong. In an Object Oriented environment each and
everything are objects. That means we cannot directly instantiate a class
nor we can directly reference a member belongs to a class i.e.
ClassName.MethodName ()

If I am right in that sense, we are doing the just opposite in .NET.
Click to expand...

Yes, .NET is fully OO but a selfrespecting language, also must support
static methods (because of class factories for instance).

But Java uses the *same* idea! How in the universe, would the runtime where
to **start** if the Main method is not static?
For example in the sample Hello World Application given below
Click to expand...

You are using VB.NET. The code below, is inside a visual basic module. By
definition, all methods in a module are static, and that's why your 'Main'
method is executable.

(if you want a real understandable OO language, use C#, and now I'm having
some people looking angry at me!)


Imports System

Class HelloWorld

Public Shared Sub Main ()

Console.WriteLine (“Hello World”)

End Sub

End Class





As per MSDN Console is a Class defined inside the System Namespace. Here
we are directly calling the Method () defined inside the Class Console.
How is this possible in an OO environment?
Click to expand...

These are all static methods. Static methods are not bad at all, only, use
them well.

I'll explain you why. If a method is static, you cannot instantiate it
right? (using Console myCons = new Console) etc

But why on earth do you want to open more than 1 console if there is only
one console -per process-?


Take this code below. It's using StreamWriter which implements the abstract
class TextWriter. Here you have your OO.

class Test
{
public static void Main()
{
// Create an instance of StreamWriter to write text to a file.
// The using statement also closes the StreamWriter.
using (StreamWriter sw = new StreamWriter("TestFile.txt"))
{
// Add some text to the file.
sw.Write("This is the ");
sw.WriteLine("header for the file.");
sw.WriteLine("-------------------");
// Arbitrary objects can also be written to the file.
sw.Write("The date is: ");
sw.WriteLine(DateTime.Now);
}
}
}
 
The code below, is inside a visual basic module.

Not that it really matters, but no it clearly says Class.


Mattias
 
Reny said:
Correct me if I am wrong. In an Object Oriented environment each and
everything are objects. That means we cannot directly instantiate a
class nor we can directly reference a member belongs to a class i.e.
ClassName.MethodName ()

If I am right in that sense, we are doing the just opposite in .NET.

For example in the sample Hello World Application given below



Imports System

Class HelloWorld

Public Shared Sub Main ()

Console.WriteLine ("Hello World")

End Sub

End Class





As per MSDN Console is a Class defined inside the System Namespace.
Here we are directly calling the Method () defined inside the Class
Console. How is this possible in an OO environment?
Click to expand...

Object oriented languages have long (dare I say always?) supported the
concept of "class methods" and "instance methods", going clear back to the
earliest flavors of SmallTalk (at least). Console.WriteLine, as well as you
HelloWorld.Main are what's known in .NET (and C++) lingo as static methods -
or "class methods" in SmallTalk. Such functions belong to a class
(HelloWorld), but can be called without an instance of that class since
they're "class methods".

-cd
 
Mattias Sjögren said:
Not that it really matters, but no it clearly says Class.
Click to expand...

you are right.

This is because Sub Main is -shared- (this is the same as static)

Public Shared Sub Main ()

Console.WriteLine ("Hello World")

End Sub


If you would put Sub main in a module, the shared attribute would not be
needed.
 
Reny said:
Correct me if I am wrong.
Click to expand...

You are wrong on a number of points, actually.
In an Object Oriented environment each and
everything are objects.
Click to expand...

Not necessarily - languages like C++ or Delphi are hybrids. You can
have fully object-oriented code, but you can also have flat functions
and global variables. .NET could get away with a full object
orientation because it didn't have to be backward compatible.
That means we cannot directly instantiate a class
nor we can directly reference a member belongs to a class i.e.
ClassName.MethodName ()
Click to expand...

No. Encapsulation does not mean that everything is private; it means
that you have full control over visibility. You can make
implementation internals private, while building a public face that
other classes can see. The public face is outsiders can rely on; the
private members are details that are subject to change.
As per MSDN Console is a Class defined inside the System Namespace. Here we
are directly calling the Method () defined inside the Class Console. How is
this possible in an OO environment?
Click to expand...

A public method.

--

<http://www.midnightbeach.com> Contracting, consulting, training

..NET 2.0 for Delphi Programmers <http://www.midnightbeach.com/.net>
Being printed - in stores by June
 
You are confusing the purists definition of Object Orientation with the much
more usable definition implemented in .NET. The purist definition requires,
among other things, that all methods of a class be associated with an
instance of that class. The reality is that this makes a language nearly
impossible to work with. The pragmatic approach, in this particular case,
is to allow class methods that don't require an instance of the class.
Note, however, that a class method (Static in C# and C++ and Public Shared
in VB) cannot refer to any private implementation of the class as this would
then require that an object be instantiated for that class.

Having worked in a pure OO environment and in the mixed OO/Procedural
environment of .NET, I'll take the mixed environment any day at it resolves
the OO issue of excessively deep object trees that become nearly as hard to
debug as speghetti code.

Mike Ober
 
Back
Top