Now, let’s begin looking at what OOP actually means. At its core, the Object Oriented paradigm consists of classes and objects. A class is a “thing” or entity that has a purpose, and an object is an instance of this entity. For example, a Car would be a class, and my car would be an object (instance of the Car class).

Classes in C#

Before we can cover any of the OO principles with code examples, we need to go through some very simple code. A class in C# is made using the class keyword:

public class Car
{
	// ...
}

The “public” is an access modifier. The available access modifiers for classes in C# are:

• public – No restrictions on accessibility of the class. It can be used from anywhere.
• private – Can only be accessed by code in the same class.
• protected – Can only be accessed by code in the same class, or in a derived class (see inheritance, below).
• internal – Can be accessed by any code in the same assembly (basically, the same file), but not from another assembly.

Methods in the class are specified like this:

public virtual void StartCar()
{
	// ...
}

Like above, public is an access modifier. The virtual keyword means that this method can be overridden in child classes (this is explained under “inheritance” below). “void” is the return type. A method that returns void basically returns nothing (the same as void in languages like C#, or procedures [as opposed to functions] in Pascal and Visual Basic). Some common return types include string, int, uint (unsigned int), long, ulong, float (Single-precision floating point number, 4 bytes) and double (Double-precision floating point number, 8 bytes)

Core OO principles

With all that said, let’s jump into the core OOP concepts. There are three “pillars” of OOP; these are the core principles of Object Oriented Programming. These are Encapsulation, Inheritance and Polymorphism. In addition to these, there are several other core ideas.

Abstraction

An abstraction is basically an idea, something that we think about to simplify things. In our car example (which will be used throughout this portfolio), a Car is an abstraction.

Encapsulation, Inheritance and Polymorphism (the pillars of OOP) are all abstractions.

Object Composition

Object composition is basically a way to combine simpler objects into larger, more complex ones. This is known as a “has-a” relationship. For example, a Car object might contain an Engine, Wheels, etc. We don’t need to know how all these other smaller objects work, but only how to interface with them (this is directly related to Encapsulation, see below).

Encapsulation

Encapsulation is the “hiding” of internal details of a class. This makes the class “friendlier”, and hides all its internals from the user. For example, a “car” class in C# could look something like this:

public class Car
{
	public virtual void StartCar()
	{
		// Do whatever the car needs to do to start
	}
 
	// More class members here
}

We can use this class without knowing exactly how it starts the car, just that it starts it:

Car myCar = new Car();
myCar.StartCar();

This also ensures that code outside the class can’t access data that it shouldn’t be allowed to touch. Allowing free access to all fields (values that the object “knows”) could lead to data corruption, as the object could be in an unknown state. For example, the car could have a field that says how much petrol is left in its petrol tank. We want the car to know how much petrol is left, but we don’t want other classes to be able to just change this value. In C#, we use private variables for this purpose:

public class Car
{
	private int _petrol;
	// ...
}

We could then have a property to access this, and choose to only have a getter (no setter) for it, meaning that it can only be read:

public class Car
{
	private int _petrol;
	public int Petrol
	{
			get { return _petrol; }
	}
	// ...
}

Inheritance

Inheritance basically allows us to build new classes which are based on existing classes. The new (lower-level) classes inherit all the functionality of those above it, and can also add new functionality. For example, we cam make a SportsCar class that inherits from Car:

public class SportsCar : Car
{
	// ...
}

The SportsCar class will automatically have all the members that Car had (the petrol field, StartCar method, etc.), as well as any new members we define. To override a method in the Car class, we can use the override keyword. As long as the function is defined with “virtual”, this will work fine:

public override void StartCar()
{
	// ...
}

In fact, we could take this abstraction even further, and have a Vehicle class which the Car inherits from. Then we could have other vehicles (e.g. Bike, Bus, etc.) which all have common elements, and can be treated in the same way (polymorphism, described below)

Polymorphism

Polymorphism is the ability to access multiple different types of objects using the same methods. For instance, above, we defined SportsCar as a derived class of Car. We can treat SportsCar instances (objects) in the same way as we treat Cars, because the compiler knows that a SportsCar is a car:

Car myCar = new Car();
Car mySportsCar = new SportsCar();
myCar.StartCar();
mySportsCar.StartCar();

The two types of cars might start very differently, but they’re both called using the same StartCar method.

More OO stuffs

Constructors

A constructor is a function that’s called when an instance of the class is created. They’re usually used to set parameters at creation time. The constructor is a method with the same name as the class. For example, in our Car class, we could have something like this:

public class Car
{
	private int _petrol;
 
	public Car(int petrol)
	{
		_petrol = petrol;
	}
}

This means that when the Car class is created, we’d need to pass it one argument (not 0, not more than one).

Car myCar = new Car(100);

We can give a class more than one constructor. In this case, each constructor is differentiated by the number of parameters. If the class is created with one parameter, the constructor with one parameter is called. Same with if the class is created with two parameters, the constructor with two parameters is called.

public class Car
{
	const int DEFAULT_PETROL = 100;
	private int _petrol;
 
	// Default constructor
	public Car()
	{
		// They didn't pass a parameter, so assume defaults.
		_petrol = DEFAULT_PETROL;
	}
 
	public Car(int petrol)
	{
		_petrol = petrol;
	}
}

An example of using these constructors:

// This will create a car, calling the default constructor.
Car myCar = new Car();
// And this uses the constructor with one argument.
Car myOtherCar = new Car(50);

Interfaces

Interfaces are another core part of OOP in C#. An interface expresses a behaviour that a class may choose to implement. Unlike a derived class, any class may have as many interfaces as you like. For example, we could define a “IExplodable” interface:

public interface IExplodable
{
	void Explode();
}

This defines an IExplodable interface, with a single method (Explode). Interfaces are always abstract; we can’t create a direct instance of them. This means that we don’t use the interface directly, instead we have classes that use the interfaces. For example, we could make our SportsCar IExplodable:

class SportsCar : Car, IExplodable
{
	// IExplodable implementation
	public void Explode()
	{
		// ...
	}
}

This makes the SportsCar use the IExplodable interface.

We can treat anything that implements IExplodable in the same way (this is Polymorphism at work). For example, a function like this:

public void ExplodeIt(IExplodable thing)
{
	thing.Explode();
}

We can pass this any object that implements IExplodable:

SportsCar myCar = new SportsCar();
Bike myBike = new Bike();
Microwave mike = new Microwave();
Potato awesomePotato = new Potato();
ExplodeIt(myCar);
ExplodeIt(myBike);
ExplodeIt(mike);
ExplodeIt(awesomePotato);

Object design

Now that I’ve covered all the basics of object orientation, I thought I’d quickly mention some things about object design. There are several things that contribute to a good design:

• Don’t put all the functionality in the one massive class or method (“centralised”). Instead, spread the functionality across multiple classes and multiple methods. This eases development, makes testing easier (see unit testing, above), and also makes the code more reusable.
• Excessive coupling is not good, because it prevents the reuse of objects in other projects. Coupling refers to the degree to which each object relies on one of the other objects. If the objects all rely on each other too much, then changes in one will require a whole heap of changes in others, and they’re not as reusable.
• High cohesion is good. Cohesion refers to how strongly-related or focused the responsibilities of a single class are. If all the methods of the class tend to be similar, the class is said to have high cohesion. High cohesion leads to more readable code, and the likelihood of code reuse inceases. As an example, in the Car class, the methods (eg. StartCar, Drive, etc) all do something to the cat.

Culture

Talking about programming culture usually involves discussion of coding standards. Coding standards are important because we need to stay consistent throughout our code, so other developers are able to understand it. The main standards that are followed in C# (including those followed at Swinburne) include:

• Use an underscore at the start of private members of a class (e.g. _petrol in the examples above)
• Use camel casing for local variables and parameters. Camel Case is basically words stuck together, with each word except the first starting with a capital letter (e.g. myCar)
• Use pascal casing (like camel case, except with the first letter capitalised as well) for the names of Classes and Methods (e.g. Car, SportsCar)
• Use an I to prefix the names of interfaces (e.g. IExplodable)
• File names should be the same as the class name (e.g. Car.cs, SportsCar.cs)
• Use meaningful descriptive words for the names of variables, classes, methods, objects, etc. The names should be useful so we know what the class or method is without looking through all the code.

Well, that’s all for now. Hope this has helped someone

— Daniel

While I’m on the topic of blogs (including this one), it’s interesting thing to note, my “37 things a girl probably doesn’t know about a guy” blog post is still by far the most popular/accessed. And it wasn’t even mine, it was just copied and pasted from a MySpace bulletin. Maybe one day I’ll write something similar, with my own thoughts on it. I guess. Speaking of random stuff that gets passed around, I keep getting tagged in those “12/20/38/50/100/whatever Things About Me” notes on Facebook, haven’t done any yet though. I suppose I might do one of those one day. It’s hard to think of that many things about myself, though. And I also try to avoid those chain things anyways. But one day someone will be like “OMG DANIEL YOU HAVEN’T DONE THOSE ANNOYING CHAIN THINGS, I HATE YOU LALALALALALA RAWRRRRRR” and I’ll be like “OH FINE >_<” and do it.

So anyways, what’s been up with me, apart from avoiding chain “random stuff about me” Facebook forwards?? Well, Valentines Day came and went… I bought my amazing friend Ciera some flowers and a valentines day teddy… She loves them both . I wanted to do something special, seeing as this year’s the first year I’ve considered buying something for someone . Apart from that, I haven’t been doing all that much. Over the last few weeks, I worked on a few programming projects, then got bored of that and stopped working on them xD. Nothing much apart from that, just the usual chatting on Windows Live Messenger, and browsing Digg, news.com.au, and some other sites.

I go back to university on Monday… Second year of Professional Software Development at Swinburne University, should be fun . No usability this semester! Although I reeeeeeeeeeally hope that we don’t have a subject that’s as bad as Usability was, HIT2308 Software Development Practices looks like it’ll be just as bad as Usability :’(. And I have that THIS SEMESTER. We’ll have to see if it’s bad. I blame you (yes, whoever’s reading this) if it is. You’re evil

For now, I’ll leave you with this video clip by GoRemy:

<3 GoRemy

And here is a remix of “Break Up” by Kim Sozzi that I started at the start of January:

Here’s the MP3, if you want it (not that you would, it’s not too good )

Well, that’s all for now. Have fun browsing your internets.
— Daniel

Well anyways, enough of my stupid rambling… my first year of University is finally over, and geez did the time pass quickly ! It was generally enjoyable, way way more so than high school was. University life is completely different to high school, in a sense it’s a lot more relaxed. Some people take advantage of this and try to breeze through Uni without studying… And end up dropping out . I tried concentrating in class (moreso than last year at high school), but in the end I just ended up not paying attention at all, and rushing all my last assignments (isn’t this the case with everyone?). Results day is 13th December 2008, so I guess I’ll be worrying about my results until then. There’s one… no, wait, two things I really hated though:

1. Exams!

Okay, sure, everyone hates exams. Me moreso than most I reckon. I seriously HATE HATE HATE exams. On a scale from 1 to OMG I HATE THIS, it’d be on the very end. Seriously. They drive me crazy. Crazier than I normally am, and that’s a LOT. I seem to often forget everything and have a whole heap of stuff rush back to me at the last minute. I hate it, haha. At least these exams aren’t as bad as the Year 12 English Exam (or maybe Usability is that bad… I’ll get to that in a bit)
And especially one of my subjects was a subject about website development using HTML. We had to write HTML (yes, by hand) in the exam. Seriously, what is that testing? Most (hell, all) normal web developers always have references handy (HTML for Dummies, Complete All-In-One Website Reference, Garfield comic strips out of their local news paper, whatever), they don’t need to know all HTML stuff off the top of their head (and certainly don’t need to write it on paper). But this subject was nowhere near as bad as everyone’s enemy:

2. Usability

Falling over might be enjoyable. Jumping off a cliff could potentially be enjoyable. But this, usability, this subject is not enjoyable at all, it’s literally the worst subject. Ever. Well maybe not really, but it’s boring. Most of the class was common knowledge (you know, things like “red writing on a green background looks fugly”, “make sure users find your software interface easy to use”, and “don’t stab people”). I’m hoping we don’t get more subjects that are as annoying as this one was. If we do, I’m stabbing someone with a red and green paper. An easy-to-use one.

Go-karts? Did someone mention go-karts? Oh yeah, it was an idea I had when I was around 8 years old or so. I had this amazingly awesome (and by “amazingly awesome” I mean “it sounded good at the time”) idea to build a go-kart that goes along the tram lines (anyone not living in Melbourne should look up “Melbourne Trams” on Wikipedia to see these mythical “tram” thingies I’m talking about). But basically, trams are a form of public transportation here, a form of light rail. The streets have tram lines in the middle of the street, kinda like a train line except it’s on the road instead of being separate. Trams have overhead powerlines, which is what gave me this idea. Instead of the go-kart needing petrol or a battery, it could simply use the power the trams are using. Although now I realise several downfalls with this:

• The go-kart would only be able to go down certain paths. Not all streets have tram lines (while a lot of the streets in the CBD have tram lines, not many suburban streets do). This would restricts its mobility
• It’d need this giant stick thing coming off of it to reach the power. Kinda like a dodgem car
• Legalities – Would it be legal to “steal” the tram’s power? What if you hold up the trams? I can imagine my go-kart breaking down and screaming “GO AROUND!” at the trams
• Some fourth downfall that I’ve forgotten
• I like turtles

So what else can I say? There’s not much really, my life’s pretty boring right now. Oh yes, my girlfriend and I broke up, I guess just things weren’t working out. So yeah, I’m single again. And no I’m not looking for a girlfriend at the moment, so don’t bother asking (unless you like the feeling of being rejected I guess) xD. I guess that made me realise a lot more about myself, who I am and exactly what I’m looking for. I made a special friend that I’m very similar and now extremely close to, it’s like we’re soulmates or something. She knows who she is, and I’m pretty certain she’d be reading this (maybe she’s the one of the 0 readers ) . As a person I’ve changed pretty significantly over the past year or so (especially in the last few months), and it really seems like a pretty good thing. But I’ll save all of this for another blog post, this one’s getting rather long. I should try to blog more about life I guess, it’s something I like writing about. If you look through the firsts posts to this blog, they were pretty geeky. Then again, I’ve become way less geeky (still do programming though), haha . It all fits in to the whole “change” thing.

Oh, and for anyone from Australia, the NoCleanFeed protests are on the 13th December (same as Swinburne results day!). For more information take a look at NoCleanFeed.com. The protests in Melbourne are going to be at the state library, and I might be going, I’m not sure yet. Perhaps you want some No Clean Feed Posters, thanks to my friend Joseph.

Well that’s all for now…
Oh and btw, the cookie’s all gone. Sorry about that.

Until next time
– Daniel

From the official Synapse site:

This project deals with network communication by means of blocking (synchronous) sockets or with limited non-blocking mode. This project not using asynchronous sockets! The Project contains simple low level non-visual objects for easiest programming without problems. (no required multithread synchronisation, no need for windows message processing,…) Great for command line utilities, visual projects, NT services

“Installing” it

Firstly, you’ll want to download the stable release of Synapse, and place them somewhere. At the time of writing, the latest Synapse version is release number 38. Once you’ve downloaded it, extract the files somewhere (it doesn’t matter where you extract them to, as long as you remember the directory name. I’d suggest to create a directory for all your Free Pascal library code). Next, we need to edit the config file, so that Free Pascal can find these libraries. Open your Free Pascal configuration file (on Linux, this is at/etc/fpc.cfg. On Windows, this should be in the directory you installed Free Pascal to). Search for this:

# searchpath for libraries

Right before that, add -Fu followed by the path to the directory you made earlier. In my case, I added:

-Fu/home/daniel/fpc

Using it in your code

In most cases, you’ll be using the TTCPBlockSocket class. This is included in the blcksock unit, so add this unit to the uses clause of your application:

uses blcksock;

Example

Connecting to a server

This is probably the most common way you’d use a socket — Connecting directly to another server. The functionality for this is contained in the TTCPBlockSocket class. Firstly, we need to define a variable to store the socket in:

var
	sock: TTCPBlockSocket;

And then we need to actually create the socket:

sock := TTCPBlockSocket.Create;

This creates a socket named sock that we’re able to use. The next step is to connect to the remote server, using the Connect method:

sock.Connect('66.79.183.71', '80');
// Was there an error?
if sock.LastError <> 0 then
begin
	writeLn('Could not connect to server.');
	halt(1);
end;

At this point, the connection to the remote server has been established, and we may send and receive data.

Sending Data

Sending data is done via the SendString method. Note that this is slightly different to some other languages; it does not add a carriage return and linefeed to the end of the line, you have to add this manually if required.

sock.SendString('GET /blog/ HTTP/1.1'#13#10'Host: www.daniel15.com'#13#10#13#10);

Receiving Data

There are several methods for receiving data, but the two main ones are RecvString and RecvPacket. RecvString reads a single string (terminated by a carriage return and linefeed) from the socket, and returns this string without the carriage return. RecvPacket reads all data waiting to be read, and returns it unmodified (all carriage returns and linefeeds will still be there). Both commands take one parameter: A timeout. If the socket doesn’t contain any data within this timeout, it returns a blank string.

buffer := sock.RecvPacket(2000);

Putting it all together

Here’s an example application that connects to a web server, does a simple HTTP request, and writes the response to the console:

program TestApp;
 
uses
	blcksock;
 
var
	sock: TTCPBlockSocket;
 
procedure Main();
var
	buffer: String = '';
begin
	sock := TTCPBlockSocket.Create;
 
	sock.Connect('66.79.183.71', '80');
	// Was there an error?
	if sock.LastError <> 0 then
	begin
		writeLn('Could not connect to server.');
		halt(1);
	end;
	// Send a HTTP request
	sock.SendString('GET /blog/ HTTP/1.1'#13#10'Host: www.daniel15.com'#13#10#13#10);
 
	// Keep looping...
	repeat
		buffer := sock.RecvPacket(2000);
		write(buffer);
	// ...until there's no more data.
	until buffer = '';
end;
 
 
begin
	Main();
end.

The loop is needed because the data may come in multiple packets.

Not that this is not really a good example, as there’s a HTTP library built-in to Synapse. The in-built HTTP library has several advantages, including the ability to use HTTP proxies. Perhaps I’ll cover that in a future blog post