Type: Tutorial
Level: Beginners
Topic Category: General Programming
Main Series: Designing and Implementing Classes in C#
Topic Title: 1) An Introduction to Designing Classes in C# - Pt.1
Most books on C# (and programming in general) will usually start with the infamous "hello world" example. Although this approach is dominant in most trainings and books, I believe it can be misleading. In my opinion, an abstract introduction to the language and the programming framework is necessary before writing any code units that really works. With object oriented programming, the situation becomes tricky! Especially with a fully object oriented programming language such as C#. In this post, I try to address some concepts that I feel must be introduced abstractly before actually beginning to learn how to write code. Now, the topics I will discuss are mere introductions in most cases and they demonstrate the concepts without tying them to a specific Programming Language (PL). I put the topics in the form of question and answer, and these topics are mainly inspired by the questions I've been asked by students during training courses I gave throughout the years especially in the early introductory phases of the courses.
What is it to declare or define a class?
We mentioned earlier that classes describe types/categories of things, more vaguely, it tells us what a single thing/object of this category will look like.
To do that, a class should list the features of objects within the class. In programming, the features of an object consists briefly of the data that describes the object and the operations that the object can do. So when we define/declare classes (I personally prefer define, however declare is the most commonly used word), what we usually do is write code units that will list the features of objects created from that class. That is, when you define a class, you should use the syntax elements your PL offers to describe and list every single feature(informational and operational) of that class.
Let's take a simple example: suppose we are designing a software for mail-courier services. The software requires at some point that you represent the mail packages that the company is dealing with. The category of objects/things that we want to represent is MailPackage objects. Congratulations, you found the name of the class you will design! Now the hard part: listing features.
To list the features of a mail package we need first to identify them (that's what we call analyzing the problem to design a solution!) As we mentioned earlier, we divide features into informational/data-related features and operational features, so let's do that!
Informational Features:
First, let's see what informational features does a mail package have. At this point, we re-emphasize the importance of the context we are developing within. You need to identify what data features that a mail package has and that is relevant to our case (mail-courier services). In other words, you need to "identify what kind of data do a mail-courier service need to store about each mail pacakge" - simple, isn't it!
Let's say that after interviewing every one in the company, their wives and their children, you found out that this is what is important to the work of the company:
Size of package: in terms of width, height and depth.
Volume of package: in meter cubed
Weight of package: in kgs rounded to the nearest integer
Order number: a serial number generated for each order that contains letters and numbers
Breakable, OneSide, Sensisitive, Hazardeous, Sealed: are all flags that can be yes or no
Packaging: one of (PaperBag, PlasticBag, CartoonBox, WoodBox, MetalBox, PlasticBox, Safe)
As you can see some of the features (let's call them properties or attributes) are calculated (Volume) and some are compund (Size). Keep that in mind for later use.
Operational Features:
Now let's take a look at what operational features does a mail package posses. When doing so, we are looking for "what mail packages can do?" Again, this should be within the context we are working within. Identifying operations can be tricky, and it much depends on the situation, but usally a good approach is generally to look for "verbs" related to the object at hand within you analysis papers. For example, you might find the following statement in one of the interview papers: "I should be able to find the order for any package that I know". Actually, the one with the information on the order is the package itself, so it is supposed to be responsible for finding its parent Order object. An operation is born: "FindParentOrder". Another type of operational features are "notifications". This enables an object of the class to notify other objects of certain things (status changes, value changes, user interactions, events in general). For example, a statement like this: "when an order is delivered, the owner should be emailed" in the interview makes a great candidate for a notification called OrderDelivered. Again, it depends on the situation but generally, notifications can be found from a statement that:
- Is a rule of the form: "When ----- occurs, ------ should be done"
- Is a rule of the form: "If ------ changes/occurs, ------ should change/be done"
- Is a rule of the form: "In the case of /event of -------, ------- should be done"
No comments:
Post a Comment