.NET vs COM and OOP

[Hedley Moses]

Hi
Windows Newbie question

I am new to Windows programming and trying to understand OOP, COM and .NET fundamentals as used in Windows programming. I Came across these two quotes from Juval Lowy’s book – Programming .NET fundamentals

“Separation of interface from implementation is a core principle of component-oriented programming. When you separate interface from implementation, the client is coded against an abstraction of a service (the interface), not a particular implementation of it (the object). As a result, changing an implementation detail on the server side (or even switching to a different service provider altogether) doesn't affect the client.”

“In a nutshell, object-oriented programming focuses on the relationships between classes that are combined into one large binary executable, while component-oriented programming focuses on interchangeable code modules that work independently and don't require you to be familiar with their inner workings to use them.”

Would someone be able to comment on the differences between .NET and COM and OOP and where is PB’s philosophy pitched in all of this.

In another PB thread which I cant find right now it was mentioned that PB programming does not use the .NET “architecture”. Is this correct? If so why is this so as it would appear that .NET is becoming an ever increasingly accepted standard.

thanks

[Michael Mattias]

You are comparing apples and oranges and peaches.

COM (component object model, q.v) is a series of Windows systems services.

.NET is an architecture.. how programs will actually 'do something'

OOP is a programming techinque, which must be supported by the compiler or interpreter in use.

Sometimes (well, often) you use the programming technique to implement an appliation using the architecture whilst using the COM services.

And equally often, software development products - compilers and interpreters - are designed to generate code which uses a certain architecture, and/or provides intrinsic facilities to access the COM services, and/or supports Object Oriented Programming syntax.

The PowerBASIC compilers have always supported procedural programming.

In version 7x the compiler added instrinsic features to access COM services as a client

In version 9x the compiler added two things: intrinsic statements/functions to support creating a a 'COM Component' ( aka 'COM server') AND source-code level support for object-oriented programming.

I think the discussion in the #1 "sticky" post in Programming With Objects forum at http://www.powerbasic.com/support/pb...ad.php?t=39898 probably includes the same discussion I found in the printed manual about how these various terms have been used carelessly over the years; and one of the first things you have to do if using the new 9x compiler features is learn what is meant by all the terms.

(Or maybe, "unlearn" what you have learned?)

MCM

[Edwin Knoppert]

>You are comparing apples and oranges and peaches.
Hmm, not really..

I do .NET a lot and (nearly) all parts are object based.
This is usually a dynamic class or static class.
A dynamic class is similar to the PB com class support.
A static class can be seen as a PB module (includefile)
However in .NET you have namespaces to distinct functionality.
In PB you can have only one GETTEXT() function, in .NET many if distincted by namespace and/or classname.

PB's oop is very similar to a .NET dynamic class.
And has a constructor and destructor as in .NET

In PB you could prepare a static class by using a dynamic class and keep the instance object variable as global.

This makes PB's oop very compatible (for code development)

There are differences, .NET does not do interfaces, for com this is an extra and a plus imo but makes it complexer as well.

C# allows overloading, com does not.
VB.NET can do optional parameters, com can do that as well.

Any more specific questions?

[Scott Slater]

I think Michael was referring to the runtime (framework) environment and not specifically .NET coding or objects. In other words the target platform (ie. Byte Code vs Native Code). The PB compilers all generate Native Code so they do not require that the .NET framework be installed.

[Hedley Moses]

Thanks guys, bit more clear on the differences. The .NET penny has not quite dropped yet. My very early day assumptions were that .NET was like an API library but that obviously not so. I'm still not clear on the architecture explanation on .NET. How is .NET different from non .NET and how can PB be used differently between the two. As was mentioned PB compiles to native code so there wont be any runtime dependencies or advantages to .NET. What about compile time? Is there anything in .NET I need to understand in order to give me advantage in PB programming

[Edwin Knoppert]

Using .NET is a choice.
Using VS you can use the object browser of what it contains and it is huge.

I don't see a point why to ask about .NET while you wish to work with PB?
I am using .NET with PB for some parts like when i want to use ADO.NET or webservices.
native alternatives do not alway swork handy or properly or due lack of knowledge.

Besides having an enormous set of functions there is little to gain with .NET.

Why these questions?

[Knuth Konrad]

.NET is framework, not an architecture.

Think of .NET in regards to an OS('s API) like ADO or ODBC is related to the underlying database engine.

Very oversimplified, .NET is "just a OOP wrapper + some helper functions" of the OS API.

PB and .NET have no more or no less relations to each other than other programming languages. .NET can call COM and native Win32 DLLs, produced by PB. .NET can produce COM and (with unmanaged C++) native Win32 DLLs callable by PB.