Creating A Class
C# is explicitly built around this templating and customization concept. We can create template objects called Classes and then customize their methods and fields/properties to do what we need.
Having learned programming mainly through building “functional” apps and websites, this templating was a new concept for me to grasp. It requires a different type of big picture thinking about the structure of your code and how it will fulfill its purpose while interacting with users. For example, will the solutions to the various questions need to be accessed later in the program? Or are they only used once and then never needed again? Will the user need to see the answer to every question in every exercise at once, or just one at a time? What are the similarities and differences between all the exercises? The answers to these questions will fundamentally affect how the program is written.
I’ll show different approaches based on different use cases.
For a thorough explanation of how Classes and Namespaces work in C# I would recommend reading the Microsoft Documentation.
When I solve the first exercise, my solution could look something like this:
Then I might add the solutions to another exercise below this, and so on, with all my code mixed together in one big .CS file.
However, this would violate the principle of encapsulation in Object Oriented Programming, which says that no code should know about or touch any other code unless it’s absolutely necessary. Read more about encapsulation in object oriented programming.
To solve this problem, I can create a class that holds all the code to solve the first exercise, and then instantiate it in the Main method.
In Visual Studio, I can go to the Project menu, then choose Add Class. Give it the name FullName2 (the second way to solve the problem), and then I’ll have a new blank template file like this:
Then in the Main method I can create a new instance of FullName2 with this line:
Now, all of the behavior that solves exercise 1 will live inside the class FullName2.
Notice there was no need to create a constructor explicitly. This is done automatically in this instance. It is necessary to create a constructor when the class requires some external information at the time of instantiation.
Another very important thing to notice is the type declaration of
fullName2. The type is actually the prototype object I created in a different file. When I declare the variable of type
I’ll be referencing the exercise from here on out without actually quoting it directly, so it may help to have a copy in front of you as you follow along.
Let’s say that the program will NOT need access to the manipulated versions of the user’s name after they are displayed. That means that after the user puts in their name and receives the uppercase and lowercase versions etc., they can be discarded.
The object-oriented implementation for this would be a method we could call on the
FullName2 class that executes these manipulations. We’ll call it
Just like in the functional implementation, it asks the user for their full name, reads that into a variable called name, and then prints the necessary strings to the Console:
Some syntactical notes:
Also, in front of the function’s name are two important words.
public is an access modifier that describes the level of accessibility for this method. In other words, how available is this method to other code in the program?
public is the most permissive of all the access modifiers, and that’s what allows the main program to access it in this case.
The next word
void describes the return value of the method.
void means there is no return value. Other possible values are
char, or any other type in C# including an instance of a class you create.
This method accomplishes the same goal as the functional version, but look at how we can start all of the computation with one line in the Main method:
Most importantly the code is more compliant with Object Oriented Practices!
There you have the first approach to refactoring the previous exercises to be more in line with object-oriented paradigms. Look for the second part of the refactoring process in a subsequent article that touches on a different approach for a different hypothetical use case.
I’m looking forward to hearing your thoughts on these subjects, so please don’t be a stranger in the comments or in notes here on Medium!