Lecture 13- The NET Framework

Outline
 In the last lecture, we continued our discussion of Objects…
 By finishing our our own custom Collection: JTrainCollection
 By inheriting from the .NET System Class, CollectionBase.
 And illustrated its use, with a generalized Multiple-JTrain Example,
 Including the addition of two Shared Members.

 We now continue our discussion with some related topics:

 The .NET Framework and .NET Framework Classes
 Which provide us with a platform for Windows Application Development;
 And supporting basis for our Object-oriented approach:
 Namespaces
 Which place a hierarchical structure on all .NET Classes…
 Both the Framework Classes, and Developer Classes
Inheriting From Object
 Think back to when we first defined JTrain…
 We used a default New() Constructor provided ‘by the System’.
 So…where did this Constructor come from?

 Recall that we later used JTrain’s default Constructor…

 When we made our first instance of JFreightTrain:
 We used the Inherits Keyword to get this functionality:
 JFreightTrain Inherits from JTrain
 So, this type of behavior implies Inheritance.
 However, we did NOT use the ‘Inherits’ keyword when we defined JTrain.

 In turns out that all VB Objects automatically inherit from Object…

 So that the Class Object serves as the universal Base Class.
 Even though the VB Keyword ‘Inherits’ is not necessary, for this.
 Several useful methods are thus available from Object, including:
 ToString() : returns a String representation of the Object (we’ve used this).
 GetType() : returns a Type Object, representing the Object’s data type

 This brings us to a discussion of the .NET Framework Classes

 To discuss this, we first need to discuss the .NET Framework.
 Windows Application Development
 In this class, we have discussed Windows Application Development
 Now, let’s talk a little bit about the underlying systems…
 The .NET platform and how it relates to Objects.
 The Windows O.S. and its interface with developed software.

 All software written by developers must communicate with Windows:

 To store data, a block of memory must be reserved:
 The Windows Memory Manager is called.
 To write data to the disk:
 The Windows Disk Subsystem is called.
 To draw a Window on the screen:
 The Windows Graphics Subsystem is called.

 This communication is supported by the Win32 API

 The Windows 32 Abstract Programming Interface.
 The Windows 32 API
 The Win API provides a layer of abstraction via a set of interfaces…
 And a set of associated programs for implementing these interfaces.
 Each of which provides a standard hand-shake with a Windows Subsystem.

 Examples:
 When a file is to be written or read, a standard DialogBox is provided:
 From the API’s Common Dialog Box Library.
 When a Window is to be drawn on the screen:
 The API’s User Interface is used, together with the Common Control Library.

 In the past, Windows developers used the Win32 API directly…

 Using a Software Development Kit (SDK) which included:
 The Win32 API.
 Tools to assist in use of the Win32 APU.

 However: the API is difficult to learn and tricky to use!

 Ex: Roughly 100 lines of code required to draw a basic Window.
 VB: Abstracting away the API
 VB helped by providing developers with a big simplification:
 Tricky API functions were packaged in an user-friendly way.
 In VB, a Window can be drawn with only a few lines of code…
 Which provide many more details, ‘hidden underneath’…

 Thus, VB provides an Abstraction Layer on top of the Windows API

 So users don’t have to deal with the API directly.
 This was greatly responsible for the big success of VB.

 This situation was quite frustrating for non-VB developers…

 C++ and Java developers have their own advantages:
 C++ provides lots of control over program function...
 Java makes programs extremely portable.
 However, development tasks that are easy in VB
 e.g., GUI development.
 Take a really long time in Java, for instance.

 This VB-Windows dependency was also dangerous for Microsoft:

 What happens if Windows is no longer dominant in 20 years?
 The .NET Framework Classes
 In 1992, Microsoft improved this situation quite a bit....
 By introducing the Microsoft Foundation Classes (MFC)…
 A set of C++ Classes, each of which provides a wrapper:
 Encapsulating and simplifying an API function.
 Essentially, providing an Object Oriented layer of abstraction on the API.
 Along with the Visual Studio IDE.
 Later, Microsoft recast this concept within the larger .NET Framework.

 The .NET Framework is completely object-oriented:

 Anything done in .Net will be done using an Object.
 Ex: To to open a file, you use a System Object designed for this purpose.
 This set of objects is actually a huge set of Base Classes (approx. 3500)
 called the .NET Framework Classes.

 All .NET developers will use this same set of classes…

 Regardless of the platform they are on!
 Windows, Linux, Pocket PC, Mac…
 Very developer-friendly!
 Regardless of the high-level language (HLL) they choose!
 VB .NET, C++, C#, J# (.NET version of Java), etc.
 Common Language Infrastructure
 This is accomplished by compiling HLL code in two steps:
 First to Microsoft Intermediate language:
 CIL (Common Intermediate Language; also called MSIL).

 All high-level languages are compiled to this same CIL code.

 This language is NOT dependent on any processor or platform.
 Then to platform-specific native (machine) code later on…
 At runtime, by the Common Language Runtime (A Virtual Machine):
 So-called ‘Just-In-Time’ (JIT) Compilation.
 So, the Common Language Infrastructure, CLI = CIL + CLR
 In this way, Microsoft freed itself from its dependence on Windows…
 As well, in principle, as its dependence on Intel Chip sets.

 Note that the Java concept is similar:

 It is also compiled to an intermediate language, called ‘Byte Code’.
 Which then runs in the Java Virtual Machine.
 However, while Java is “One Language / Many Platforms”…
 .NET started as ‘Many Languages / One Platform’ (and then expanded).
 Common Language Runtime (CLR)
 The Heart of the .NET Framework is the CLR, which handles:
 Loading and Executing Code: The primary task of JIT Compilation
 (Most) languages supported by the CLR are referred to as ‘Managed Code’.

 Application Isolation:
 Individual applications should run separately :
 So that they may crash separately from the OS.
 Idea: Prevent software-based system crashes (Blue Screen of Death)
 Applications now have built-in security:
 Code requires ‘evidence’ to run in CLR (determined via programmer-set policies).
 In contrast, old Windows applications have unlimited access to system data.

 Inter-language Interoperability:
 Available Data Types are shared by all managed languages…
 Exception Handling and Memory Management:
 Provide appropriate structures for error recovery (we’ve discussed this).
 Formally, the CLR consists of 4 elements:
 A JIT Compiler and a Virtual Execution System (VES, or Virtual Machine)
 The Common Language Runtime (CLR) and Specification (CLS)
 Achieving Language Interoperability
 Language interoperability in .NET goes beyond common compilation:
 The idea is really much more general:
 It would be best if classes which are defined/extended in one language…
 Are then freely available to all.
 Example: Our JTrain Class should be extendable by a C# Programmer
 So that the Classes will function properly in a C# program (!)

 .NET introduced the Common Type System (CTS) to support this:

 Primitive data types are handled the same in all managed languages…
 Integers, Doubles, Strings, etc are defined consistently.
 Previously, they were defined differently, in different HLLs.
 This simplifies the job of interoperability between languages.

 .NET also introduced the Common Language Specification (CLS):

 Along with managed code comes the concept of managed data…
 Nearly all CLR-managed Data are represented as Objects.
 Specifically: Classes in the .NET Framework and derived Classes
 These can be passed between managed languages.

 This brings us back to the .NET Framework…

Overview of the CLI
 The .NET Framework Classes
 The .NET Framework consists of two components:
 The Common Language Runtime (Actually, the CLI).
 The .NET Framework Classes.
 A huge set (> 3500) of Base Classes for developer use.
 A bit hard to navigate…

 Fortunately, the Framework Classes are conveniently divided into

related groups.
 Each group is associated with a specific Namespace.
 The overall collection of namespaces is hierarchical:
 Namespaces can contain other namespaces.
 Created by stringing together the namespaces with the dot (.) operator
 Each class must belong to exactly 1 namespace:
 Its ‘containing’ namespace, followed by its specific Class name.
 The System Namespace
 Most Framework Classes are contained in the System namespace.
 In fact, we have already been using System Classes extensively…
 Examples:
 System.Windows.Forms – Classes for drawing Forms
 System.Console – A Class for designing Console Applications
 System.Object – Here, we see that Object derives from Class System.

 We were allowed to use abbreviated versions…

 Ex: We used Console.ReadLine() rather than System.Console.ReadLine()

 Now, we talk about finding Namespaces and Namespace Creation:

Finding the Current Namespace
Using the Object Browser
Creating Your Own Namespace
 Multiple Inheritance
 Some languages support Multiple Inheritance
 By which Objects can combine behaviors from several ‘superclasses’.
 Sounds interesting…but this can cause ambiguity troubles.
 Examples:
 C++ permits multiple inheritance
 Java technically does not…
 but supports the use of multiple interfaces, instead.

 In the .NET Framework, Multiple-inheritance is not allowed.

 Each Class must be derived (directly inherit) from exactly one Class.
 In other words, only 1 Class can be included in a Class’s Inherits Clause.
 Recall: all Objects ultimately inherit from System.Object
 For derived Classes, there will be a chain of inheritance-relationships:
 JFreightTrain inherited from JTrain…
 JTrain inherited from System.Object.
 Preview: Software Engineering
 In the next course, we continue with our tour of VB .NET:
 Advanced topics in OO Programming, including:
 Partial and Abstract Classes
 Interfaces and Generics

 Creating Class Libraries

 Which encapsulate related sets of Classes for re-use.
 Registering your Libraries…
 So that you can find the classes of your library with the Object Browser.
 Creating Custom Controls
 Custom Graphics
 Then, some related technologies:
 Database Access (ADO.NET)
 Server-Side Programming (ASP.NET)

 In the Software Engineering Seminar, we will discuss using C# ....

 This will allow us to do Embedded Programming ( Course 4 )
 You may not get much C# until the seminar.
 We will probably look at J# concurrently (Microsoft’s version of Java)
 Conclusion and Final Project
 In this Course, we discussed Application Programming
Fundamentals:
 Specifically: development for Windows Applications.
 Along the way, we discussed:
 The most frequently-used Controls.

 Basic and Advanced topics in Object Oriented Programming.

 In the next course, we will continue with a more VB .NET:

 Advanced OO Topics
 Creating Class Libraries
 Creating Custom Controls
 Custom Graphics.
 Then, some related technologies:
 Database Access (ADO.NET)
 Server-Side Programming (ASP.NET)

 The C# language will be discussed in my seminar…

 To allow us to do Embedded Programming ( Course 4 )