p988 said:
Why people say that C# is a component-oriented language?
To understand components, it's best to see simple GUI (graphical user
interface) examples, since this is one of the first places where
component programming come from. In C# or VB, you can produce a piece
of software in the form of DLL (dynamically-linked library). You can
re-use this DLLs, often in a visual manner. That is, you can
drag-n-drop your ActiveX OCX "component" visually into your program.
That was the ideal dream of component-based programming, and all what
the initial hype of Java beans was about. Before .NET, component
programming in the commercial world basically meant COM (Microsoft) or
CORBA (Java), although Apple MacIntosh was probably the first
well-known system to use component technology. Remember the first time
you were able to cut and paste an image from a paint program into a
word processor document? That's what components are all about: you
have "software components" ("program libraries" in reality) installed
in your system, and you can re-use these components from different
applications. So, magically, a word processor that does not understand
images can all of a sudden have an embedded image displayer. This
library sharing process is later standardized: the libraries must meet
some rigid specifications to facilitate binary communication across
language barriers (C++/VB/etc.) and location barriers (remote
objects). And there you have COM and CORBA. The arrival of .NET brings
a new way of making components, quite different from COM. For
instance, there are no longer registry entries to keep track of the
components. Hence, in the new Windows world, you have to manipulate
both the old COM components and the new .NET components.
C# is a component-oriented language because the language and the IDE
(Integrated Development Environment) help you to use/create
components.
What differences there exist between an event and a method in C#?
That's a good one. Remember how SUN sued Microsoft? Well, one of the
issues was Microsoft "tainted" the Java language by introducing new
features in J++. One of the new features was the introduction of a new
beast called "delegate", unheard of in the Java world. In the Java
world, events and event listeners are separate concepts/objects. What
Microsoft did was some sort of unification, hence in C#, there is one
single beast: "event delegate" to take care of events and event
listeners. Moreover, events are fired by using the () operator,
(that's why your question: event firing looks just like a regular
method!) so Microsoft's "event delegate" actually does three jobs at
once. Is this good or bad? I don't know. I know that when I was doing
Java, it was kind of confusing to juggle all the event-related
objects/methods. So, Microsoft's approach does appear to be a lot more
simplified. This simplification nonetheless could be confusing on its
own. So, in short, an event delegate in C# is: (a) an object to
represent the concept of an event, (b) an event listener queue that
holds references to the event handlers, (c) a callable object for
firing an event. You get three for the price of one.
What differences there exist between a properties and an attribute in C#?
Properties are for program objects (as in objects created from a
class), basically they are dynamic data fields, and are used for
normal programming. Attributes are like meta-tags, they are for
meta-programming purposes. They add additional information, which I
guess you should be able to ignore/postpone until you get into
advanced programming, e.g. making .NET components.
regards,
Hung Jung