Object-Oriented Programming in C# Succinctly®
CHAPTER 7
Other Paradigms
By now I hope you’ve realized that Object-Oriented design is pretty awesome. It’s not the only way to write software out there though. In fact, C# is a multi-paradigm language. Knowing other paradigms helps to identify the strengths and weaknesses of OOP.
Procedural Programming
Procedural Programming has been around for a long time. The name comes from procedures or subroutines, also known as methods. Procedural languages, like OO languages, have methods (procedures), variables, data structures, and even some sort of modularity. Procedural languages have no notion of classes, though. If two methods need access to the same variable that variable must be declared on a global level. In larger applications this becomes problematic as it’s very easy to accidentally manipulate such a variable and mess up your entire application. Well known procedural languages are C, Pascal, FORTRAN, and BASIC.
Functional Programming
Even though Functional Programming has been around since the 50’s, it has recently seen an uptick in popularity. The first functional language, in 1958, was LISP. In Functional Languages functions, closely related to mathematical functions, have a central role, as just like in mathematics a function can only work with the input it has been given. This makes it possible to reason about functional programs because you know functions will not alter any program state. Since functions are so important, it is easy to compose new functions from existing functions, to return functions from functions, and to pass functions as input to other functions. We say that functions are first class citizens. Functional languages often have a sophisticated type system which makes it unnecessary to declare variable types, yet type safety is guaranteed.
C# has some functional constructs. For example LINQ and lambda’s have been borrowed from functional languages. Other popular functional languages are F#, ML, Erlang, and Haskell.
Stateless programming
One big difference between Functional and OO Programming is the notion of state. Every OO language has state, variables inside a class that determine the state of a class. Having state does more for a language than you might think. For example, consider the following Incrementer class:
Code Listing 105: The Incrementer Class
public class Incrementer { private int counter = 0; public void Increment() { counter += 1; } public int GetIncrement() { return counter; } } |
The state of any Incrementer instance is determined by the value of counter. When we call the Increment function we cannot know the state of our instance unless we knew the state before we called Increment. This makes it very hard to reason about programs. When we call GetIncrement, we don’t know what it will return because we don’t know the state of the object.
Let’s check out an example. Suppose we have a class Math with a function Add.
Code Listing 106: A Math Class
public class Math { public int Add (int a, int b) { return a + b; } } |
In this case, we know that if we call the function with parameters 1 and 2 the result will be 3. However, and this is very important, in an OO language we can never be sure.
Code Listing 107: Add with Side Effects
public class Math { private int something; public int Add (int a, int b) { something += 1; return a + b; } } |
Nothing stops us from writing an Add function that changes the internal state of our Math class. The change of a class’ internal state is called a side effect.
Functional Programming forbids such side effects. This makes it possible to predict the outcome of a function given the input parameters. It’s difficult though; try writing an application without state or side effects.
Aspect-Oriented Programming
OOP is great for many things. One thing it isn’t very good at is handling so-called cross-cutting concerns. A cross-cutting concern is a general responsibility that is used throughout the application. Think of logging, for example, which you might want to implement in just about any method in every layer and every project. The result is that all your methods start with something like Logger.Log(currentMethodName, inputParameters). Another example is something like the INotifyPropertyChanging and INotifyPropertyChanged interfaces in .NET. They can be implemented on a class, which should then raise the PropertyChanging and PropertyChanged events whenever a property changes its value. The implementation is rather tedious:
Code Listing 108: INotifyPropertyChanging and INotifyPropertyChanged
public class SomeClass : INotifyPropertyChanging, INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; public event PropertyChangingEventHandler PropertyChanging; private int someProperty; public int SomeProperty { get { return someProperty; } set { if (value != someProperty) { RaisePropertyChanging("SomeProperty"); someProperty = value; RaisePropertyChanged("SomeProperty"); } } } private void RaisePropertyChanging(string propertyName) { if (PropertyChanging != null) { PropertyChanging(this, new PropertyChangingEventArgs(propertyName)); } } private void RaisePropertyChanged(string propertyName) { if (PropertyChanged != null) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } } |
That’s a lot of boilerplate code! A class that would need one line of code now has over thirty!
Aspect-Oriented Programming aims to fix this issue by altering existing code dynamically. The Proxy or Decorator Patterns are often used to accomplish this. One of the most known AOP frameworks is probably PostSharp[6]. Another is DynamicProxy by Castle Project[7].
- 1800+ high-performance UI components.
- Includes popular controls such as Grid, Chart, Scheduler, and more.
- 24x5 unlimited support by developers.