C# is a general-purpose, type-safe, object-oriented programming language. The goal of the language is programmer productivity. To this end, the language balances simplicity, expressiveness, and performance. The chief architect of the language since its first version is Anders Hejlsberg (creator of Turbo Pascal and architect of Delphi). The C# language is platform-neutral, but it was written to work well with the Microsoft .NET Framework.
C# is a rich implementation of the object-orientation paradigm, which includes encapsulation, inheritance, and polymorphism. Encapsulation means creating a boundary around an object, to separate its external (public) behavior from its internal (private) implementation details. The distinctive features of C# from an object-oriented perspective are:
- Unified type system
The fundamental building block in C# is an encapsulated unit of data and functions called a type. C# has a unified type system, where all types ultimately share a common base type. This means that all types, whether they represent business objects or are primitive types such as numbers, share the same basic set of functionality. For example, an instance of any type can be converted to a string by calling its
ToStringmethod.- Classes and interfaces
In a traditional object-oriented paradigm, the only kind of type is a class. In C#, there are several other kinds of types, one of which is an interface. An interface is like a class, except that it only describes members. The implementation for those members comes from types that implement the interface. Interfaces are particularly useful in scenarios where multiple inheritance is required (unlike languages such as C++ and Eiffel, C# does not support multiple inheritance of classes).
- Properties, methods, and events
In the pure object-oriented paradigm, all functions are methods (this is the case in Smalltalk). In C#, methods are only one kind of function member, which also includes properties and events (there are others, too). Properties are function members that encapsulate a piece of an object’s state, such as a button’s color or a label’s text. Events are function members that simplify acting on object state changes.
C# is primarily a type-safe language, meaning that instances of types can interact only through protocols they define, thereby ensuring each type’s internal consistency. For instance, C# prevents you from interacting with a string type as though it were an integer type.
More specifically, C# supports static typing, meaning that the language enforces type safety at compile time. This is in addition to type safety being enforced at runtime.
Static typing eliminates a large class of errors before a program is even run. It shifts the burden away from runtime unit tests onto the compiler to verify that all the types in a program fit together correctly. This makes large programs much easier to manage, more predictable, and more robust. Furthermore, static typing allows tools such as IntelliSense in Visual Studio to help you write a program, since it knows for a given variable what type it is, and hence what methods you can call on that variable.
Note
C# also allows parts of your code to be dynamically typed via the
dynamic keyword (introduced in C# 4).
However, C# remains a predominantly statically typed language.
C# is also called a strongly typed language because its type rules (whether enforced statically or at runtime) are very strict. For instance, you cannot call a function that’s designed to accept an integer with a floating-point number, unless you first explicitly convert the floating-point number to an integer. This helps prevent mistakes.
Strong typing also plays a role in enabling C# code to run in a sandbox—an environment where every aspect of security is controlled by the host. In a sandbox, it is important that you cannot arbitrarily corrupt the state of an object by bypassing its type rules.
C# relies on the runtime to perform automatic memory management. The Common Language Runtime has a garbage collector that executes as part of your program, reclaiming memory for objects that are no longer referenced. This frees programmers from explicitly deallocating the memory for an object, eliminating the problem of incorrect pointers encountered in languages such as C++.
C# does not eliminate pointers: it merely makes them unnecessary for most programming tasks. For performance-critical hotspots and interoperability, pointers may be used, but they are permitted only in blocks that are explicitly marked unsafe.
C# is typically used for writing code that runs on Windows platforms. Although Microsoft standardized the C# language through ECMA, the total amount of resources (both inside and outside of Microsoft) dedicated to supporting C# on non-Windows platforms is relatively small. This means that languages such as Java are sensible choices when multiplatform support is of primary concern. Having said this, C# can be used to write cross-platform code in the following scenarios:
C# code may run on the server and dish up HTML that can run on any platform. This is precisely the case for ASP.NET.
C# code may run on a runtime other than the Microsoft Common Language Runtime. The most notable example is the Mono project, which has its own C# compiler and runtime, running on Linux, Solaris, Mac OS X, and Windows.
C# code may run on a host that supports Microsoft Silverlight (supported for Windows and Mac OS X). This technology is analogous to Adobe’s Flash Player.
C# depends on a runtime equipped with a host of features such as automatic memory management and exception handling. The design of C# closely maps to the design of Microsoft’s Common Language Runtime (CLR), which provides these runtime features (although C# is technically independent of the CLR). Furthermore, the C# type system maps closely to the CLR type system (e.g., both share the same definitions for predefined types).
The .NET Framework consists of the CLR plus a vast set of libraries. The libraries consist of core libraries (which this book is concerned with) and applied libraries, which depend on the core libraries. Figure 1-1 is a visual overview of those libraries (and also serves as a navigational aid to the book).
Figure 1-1. Topics covered in this book and the chapters in which they are found. Topics not covered are shown outside the large circle.
The CLR is the runtime for executing managed code. C# is one of several managed languages that get compiled into managed code. Managed code is packaged into an assembly, in the form of either an executable file (an .exe) or a library (a .dll), along with type information, or metadata.
Managed code is represented in Intermediate Language or IL. When the CLR loads an assembly, it converts the IL into the native code of the machine, such as x86. This conversion is done by the CLR’s JIT (Just-In-Time) compiler. An assembly retains almost all of the original source language constructs, which makes it easy to inspect and even generate code dynamically.
Note
Red Gate’s .NET Reflector application is an invaluable tool for examining the contents of an assembly. You can also use it as a decompiler.
The CLR performs as a host for numerous runtime services. Examples of these services include memory management, the loading of libraries, and security services. The CLR is language-neutral, allowing developers to build applications in multiple languages (e.g., C#, Visual Basic .NET, Managed C++, Delphi.NET, Chrome .NET, and J#).
The .NET Framework contains libraries for writing just about any Windows- or web-based application. Chapter 5 gives an overview of the .NET Framework libraries.
C# 5.0 also interoperates with Windows Runtime (WinRT) libraries. WinRT is an execution interface and runtime environment for accessing libraries in a language-neutral and object-oriented fashion. It ships with Windows 8 and is (in part) an enhanced version of Microsoft’s Component Object Model or COM (see Chapter 25).
Windows 8 ships with a set of unmanaged WinRT libraries which serve as a framework for touch-enabled Metro-style applications delivered through Microsoft’s application store. (The term WinRT also refers to these libraries.) Being WinRT, the libraries can easily be consumed not only from C# and VB, but C++ and JavaScript.
Warning
Some WinRT libraries can also be consumed in normal non-tablet applications. However, taking a dependency on WinRT gives your application a minimum OS requirement of Windows 8. (And into the future, taking a dependency on the next version of WinRT would give your program a minimum OS requirement of Windows 9.)
The WinRT libraries support the new Metro user interface (for writing immersive touch-first applications), mobile device-specific features (sensors, text messaging and so on), and a range of core functionality that overlaps with parts of the .NET Framework. Because of this overlap, Visual Studio includes a reference profile (a set of .NET reference assemblies) for Metro projects that hides the portions of the .NET Framework that overlap with WinRT. This profile also hides large portions of the .NET Framework considered unnecessary for tablet apps (such as accessing a database). Microsoft’s application store, which controls the distribution of software to consumer devices, rejects any program that attempts to access a hidden type.
Note
A reference assembly exists purely to compile against and may have a restricted set of types and members. This allows developers to install the full .NET Framework on their machines while coding certain projects as though they had only a subset. The actual functionality comes at runtime from assemblies in the Global Assembly Cache (see Chapter 18) which may superset the reference assemblies.
Hiding most of the .NET Framework eases the learning curve for developers new to the Microsoft platform, although there are two more important goals:
It sandboxes applications (restricts functionality to reduce the impact of malware). For instance, arbitrary file access is forbidden, and there the ability to start or communicate with other programs on the computer is extremely restricted.
It allows low-powered Metro-only tablets to ship with a reduced .NET Framework (Metro profile), lowering the OS footprint.
What distinguishes WinRT from ordinary COM is that WinRT projects its libraries into a multitude of languages, namely C#, VB, C++ and JavaScript, so that each language sees WinRT types (almost) as though they were written especially for it. For example, WinRT will adapt capitalization rules to suit the standards of the target language, and will even remap some functions and interfaces. WinRT assemblies also ship with rich metadata in .winmd files which have the same format as .NET assembly files, allowing transparent consumption without special ritual. In fact, you might even be unaware that you’re using WinRT rather than .NET types, aside of namespace differences. (Another clue is that WinRT types are subject to COM-style restrictions; for instance, they offer limited support for inheritance and generics.)
Note
WinRT/Metro does not supersede the full .NET Framework. The latter is still recommended (and necessary) for standard desktop and server-side development, and has the following advantages:
C# 5.0’s big new feature is support for
asynchronous functions via two new keywords, async and await. Asynchronous
functions enable asynchronous continuations, which
make it easier to write responsive and thread-safe rich-client
applications. They also make it easy to write highly concurrent and
efficient I/O-bound applications that don’t tie up a thread resource per
operation.
We cover asynchronous functions in detail in Chapter 14.
The features new to C# 4.0 were:
Dynamic binding
Optional parameters and named arguments
Type variance with generic interfaces and delegates
COM interoperability improvements
Dynamic binding (Chapters 4 and 20) defers binding—the process of resolving types and members—from compile time to runtime and is useful in scenarios that would otherwise require complicated reflection code. Dynamic binding is also useful when interoperating with dynamic languages and COM components.
Optional parameters (Chapter 2) allow functions to specify default parameter values so that callers can omit arguments and named arguments allow a function caller to identify an argument by name rather than position.
Type variance rules were relaxed in C# 4.0 (Chapters 3 and 4), such that type parameters in generic interfaces and generic delegates can be marked as covariant or contravariant, allowing more natural type conversions.
COM interoperability (Chapter 25) was enhanced in C# 4.0
in three ways. First, arguments can be passed by reference without the
ref keyword (particularly useful in
conjunction with optional parameters). Second, assemblies that contain COM
interop types can be linked rather than
referenced. Linked interop types support type
equivalence, avoiding the need for Primary Interop
Assemblies and putting an end to versioning and deployment
headaches. Third, functions that return COM-Variant types from linked
interop types are mapped to dynamic
rather than object, eliminating the
need for casting.
The features added to C# 3.0 were mostly centered on Language Integrated Query capabilities or LINQ for short. LINQ enables queries to be written directly within a C# program and checked statically for correctness, and query both local collections (such as lists or XML documents) or remote data sources (such as a database). The C# 3.0 features added to support LINQ comprised implicitly typed local variables, anonymous types, object initializers, lambda expressions, extension methods, query expressions and expression trees.
Implicitly typed local variables (var keyword, Chapter 2) let you omit the variable
type in a declaration statement, allowing the compiler to infer it. This
reduces clutter as well as allowing anonymous types
(Chapter 4), which are simple classes
created on the fly that are commonly used in the final output of LINQ
queries. Arrays can also be implicitly typed (Chapter 2).
Object initializers (Chapter 3) simplify object construction by allowing properties to be set inline after the constructor call. Object initializers work with both named and anonymous types.
Lambda expressions (Chapter 4) are miniature functions created by the compiler on the fly, and are particularly useful in “fluent” LINQ queries (Chapter 8).
Extension methods (Chapter 4) extend an existing type with new methods (without altering the type’s definition), making static methods feel like instance methods. LINQ’s query operators are implemented as extension methods.
Query expressions (Chapter 8) provide a higher-level syntax for writing LINQ queries that can be substantially simpler when working with multiple sequences or range variables.
Expression trees (Chapter 8) are miniature code DOMs (Document Object
Models) that describe lambda expressions assigned to the special type
Expression<TDelegate>. Expression
trees make it possible for LINQ queries to execute remotely (e.g., on a
database server) because they can be introspected and translated at
runtime (e.g., into a SQL statement).
C# 3.0 also added automatic properties and partial methods.
Automatic properties (Chapter 3) cut the work in writing
properties that simply get/set a private backing field by having the
compiler do that work automatically. Partial methods
(Chapter 3) let an
auto-generated partial class provide customizable hooks for manual
authoring which “melt away” if unused.
Get C# 5.0 in a Nutshell, 5th Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
