People in the first group:

• Have done their main programming study at University or TAFE OR are self-taught with just the basics, generally nothing about best practices. Generally, they’ve learnt just enough to get by, nothing more
• Will copy and paste code and be happy that it works, but might not really understand how it actually works
• Don’t really consider programming a hobby
• Might be considered “code monkeys” in some situations
• Generally need help with fixing odd bugs

And people in the second group:

• May have done a University course, but their main learning is self-taught
• Write applications, scripts, websites, whatever for fun (and might actively participate in open-source projects)
• Don’t copy and paste code very often. Instead, they learn from other people’s code, and then rewrite that code in their own style
• Consider programming one of their biggest hobbies
• Aware of some of the latest trends in software development
• Might often question things, like the ways people do things, and why code is written in a specific way (or is this just me?). Usually I do that just to learn how things are done.
• Can generally investigate and solve odd bugs pretty well

Anyone else agree with me? Personally I’m proud to be in the second group, the awesome group

Anyways, I’ll write another proper blog post, eventually. I started working recently, and will definitely have to blog about that

Until next time,
— Daniel

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

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