Beginning C#: Part 3 – Programming Principles

Coming from a PHP programming background, I think I can improve on my understanding of solid object oriented programming concepts. Given that C# is 100% object oriented, and the fact that understanding some key principles will help me in my general programming knowledge, I thought it would be good to go over some of these concepts in this article.

If you notice that I use a term incorrectly, please let me know. I’m still learning the different concepts with object oriented programming, so forgive me if I use any terms incorrectly or in the wrong context.


Abstraction is at the core of object oriented programming. In simple terms, abstraction is what makes objects, well objects. An object has generalized properties and attributes that define the object, and this is what abstraction is. The ability to define properties for a an object, and allows the object the capability of being used and customized in each instance gives us a lot of power that we do not have in non object oriented programming languages.

In C# each object is a type. Each variable in an object is called a member. Each member can be defined with an access modifier (public, private, protected, internal or internal protected) that allows us to restrict who can access which members. Members are also sometimes referred to as instance variables. One key concept to understand is that instance variables are different than properties. Properties are methods meant for getting and/or setting a value for an instance variable. Typically instance variables are set to being private in scope.

Abstraction also refers to the ability to make classes so general that they are not designed to be instantiated directly. An example of this would be a vehicle class. A car class or a van class may inherit from the vehicle class, but the vehicle class is probably not designed to be its’ own object on its’ own. C# provides an excellent tool in this scenario with Abstract Classes, which enforces this concept by throwing an error.


Encapsulation is the ability to limit access to members and methods by making them private or protected. These are not the only available access modifiers…but are the most common ones that you will see. A well encapsulated class refers to the fact that the class was designed efficiently in protecting its’ members and methods in a way that makes the most sense and makes it easy for data to be accessed by those that should be accessing it (which also helps other programmers work with your code and also protects the code from people intentionally or unintentionally changing things they shouldn’t change).

Here is a good description of encapsulation:


Inheritance is where a class extends or grows from another class. It makes a lot of sense to me when I think of it like a hierarchy. You could have a vehicle class at the top, and then a car class, and then a compact car class, etc… For me, this is where the true benefit from object oriented programming comes in to play. If the system you are working with is built efficiently, using an objected oriented system should prevent you from have to re-write code and it should make it easy for others to re-use the code that you’ve written as well. So if you have a vehicle class and want a car, you should be able to use the vehicle class by extending it and accessing all of the members and methods. From that you should be able to create a car much more efficiently and effectively.


An interface gives a client application access to an object, without actually giving them access to the specific details of the object. In other words, an interface only gives us enough information to be able to access the members and methods of the object effectively…without having to know how everything works, and without having any implementation code in the interface. Only methods, properties, events, and fields that are declared public in scope are included in an interface.

This also allows the client application to not be effected if the object is ever changed…just as long as the interface does not change (the items that are public in scope). This allows us to change how the object is implemented, while making sure we do not break any client applications that are currently using the code. This is a phenomenal feature of object oriented programming languages.


Polymorphism refers to the ability to have an object upcast or downcast. So if a car class inherits from a vehicle class, and an object that instantiates a car object….it can be specified as a vehicle type. This is very useful if you want to create an array of vehicles that could potentially work with objects that are cars, vans, buses, etc….just as long as all of those object inherit from the vehicle class.


The more I learn about C#, the more I realize how simple PHP was designed. This is not necessarily a bad thing, but I’m falling in love with the complexities of C# and the advanced capabilities I was missing in what I was doing in PHP.