Object-Oriented Programming Concepts for DBAs
This all came about when Aaron Nelson (blog | twitter) asked me a few questions about object-oriented concepts. I did the best that I could to answer his questions, but I decided that this needed a real answer that will, I’m hoping, help to bridge the language gap between DBAs and developers. Note to the reader: Please keep in mind that this is based on the .NET framework and specifically my experience with C#. If you want to highlight differences for your own language of choice in the comments, feel free.
Class
A class is a definition that we’ll be using later when we create objects. It’s a generic blueprint for building something else. It describes all of the properties that an object will have once we create one. In addition, classes also describe all of the behaviors (called methods) that an object will have. DBAs, you can think of a class as similar to DDL. Just as DDL defines a the rows of a table, a class defines the objects that we’ll create later.
Object
“An object can be said to be an instance of a class.” WTF does that mean? Well, an object is an instance of a class. That means that any time we create an object, we base if off of some kind of template. The object, whatever it may be, is just an implementation based off of some kind of blueprint. In the .NET world, an object can only be defined by one class. Once we create an object (using something called a constructor), it’s different from the class. Like a zombie, the object takes on a life of its own. Let’s take a look at an example. Cars have common properties – they all have four wheels, an engine, and a number of doors that is greater than 0. Individual cars have a lot of differences: different paint and upholstery colors, different trim levels, stereos, engines, transmissions, etc. When you go down to the car dealership (the constructor), you don’t just ask for a generic car. You have to be more specific and tell the dealer that you want a bright red 1978 Lincoln Continental with white wall tires. The dealer will get you the car (the constructor instantiates the object) and you can pimp in style. Depending on how things are set up, we can change the properties of our object after we’ve created it. Properties can be modified with new values, or we can call methods on the object to make complicated changes to the object’s state. In a round about way, an object is similar to a row. It’s a single instance of data. This is a bit of a crappy metaphor because a single object can actually contain deep structure that would be difficult to represent in a single row in the database.
Fields
A field is a basic variable – a string or number. It’s the simplest way to store data in an object. You can think of it as roughly akin to a column. You may also hear people refer to fields as member variables, instance variables, or any of a number of terms.
Properties
In the .NET world properties are wrappers around fields. They aren’t quite methods, but they aren’t quite fields. One of the interesting things about properties is that they let us enforce rules or build complex ways to describe an object from a set of simple data points.``` public class Person { // other nonsense goes here…
// some fields private string _firstName; private string _lastName;
public string FirstName { get { return _firstName; } set { _firstName = value; } }
public string LastName { get { return _lastName; } set { _lastName = value; } }
public readonly string FullName {
get { return _firstName + " " + _lastName; }
}
}
In the real world, we’d do things far more complex than concatenating first name and last name to make a full name. We’d probably use a comma and put things in the order of last name first. Or maybe we’d calculate order price based on county sales tax and order line items and shipping fees. An astute reader might notice that properties bear an uncanny similarity to constraints in a database. Let’s look at a different example. A class for a clock might look like this:
public class Clock {
private int _hours;
public int Hours {
get { return _hours; }
set {
if (value >= 0 && value <= 23) {
_hours = value;
} else {
throw NotOnPlanetEarthException();
}
}
}
}
And a similar table would look like this:
CREATE TABLE clock (
[hours] INT CHECK (h BETWEEN 0 AND 23)
);
It’s possible to create deeply nested structures of fields and properties. You can, for example, model a store thusly:
public class Store {
private List _employees;
private List _products;
// I know this isn’t how I should really model it. Shut up.
}
And this is all well and good in code. And there is a way to model this in the database that should seem relatively obvious using join tables (employees can work in more than one store and products can be sold in more than one store).
CREATE TABLE stores (
StoreId INT IDENTITY(1,1)
– real implementation left out because I don’t want to write it
);
CREATE TABLE Employees ( EmployeeId INT IDENTITY(1,1) );
CREATE TABLE Products ( ProductId INT IDENTITY(1,1) );
CREATE TABLE StoreEmployees ( StoreId INT, EmployeeId INT );
CREATE TABLE StoreProducts ( StoreId INT, ProductId INT );
#### Methods
Methods are the workhorses of object-oriented programming. These are the verbs of programming. A method is a bunch of statements that are executed in order and achieve some result. Methods are roughly analogous to stored procedures or functions (depending on your database).
### Inheritance
The programming world would be incredibly painful if we had to keep repeating code every time we want to do the same thing. Inheritance helps us solve this problem, in some cases. All cars have similar properties – they have engines, doors, wheels, seats, and various other car things. Some cars have different traits – a 1967 Plymouth Fury Station Wagon drives a lot differently than an 2010 Aston Martin DB9.```
public class Car {
// details go here
}
public class StationWagon : Car {
// more details
}
public class SportsCar : Car {
// very fast details
}
```Inheritance is a way to work with the same root data and behaviors but provide additional specialization. Our `SportsCar` class might provide a `SpinTires`or `BurnOut` method whereas the `StationWagon` is not capable of performing a burn out. Another way to think about it is to say that inheritance (and also interfaces) is a way of describing “is a” relationships. A SportsCar is a Car. Anywhere that we can use a Car, we can also use anything else that is a Car. So, we can use a StationWagon in any method that expects a car. But, since a StationWagon isn’t a SportsCar, it won’t work there. See how that works?
> If this seems like a huge set of abstractions, you’re absolutely right. A lot of the concepts of object-oriented programming can be implemented using purely procedural code. It’s considerably easier to express some concepts using object-oriented code. There is some performance overhead, but many developers consider that the performance penalty is made up by the ease of development.
### Interfaces
[](http://facility9.com/wp-content/uploads/2010/08/duckroll.jpg) Interfaces are where things get a little bit tricky for some people. An interface is a contract. When we say that a class_implements_ an interface, we’re really saying that the class has all of the methods defined in the interface. An interface is an abstract type that can’t be directly created. Interestingly enough, though, we can create classes that implement an interface and then use the class anywhere that the interface is accepted. If we create an `IWheeledVehicle` interface (interfaces in the .NET world are typically named with an I), we can define methods that accept an`IWheeledVehicle` parameter. We can use any object that provides an implementation of `IWheeledVehicle` with that method. Even if that object is a duckroll.
### In Summation
Object-oriented programming is a strange concept when you first encounter it, but it provides useful abstractions that make it easier for developers to work with data. Understanding how developers might be consuming data is going to make it easier for you to work with them and create amazing applications. If you’re going to be doing a lot of work with developers for any length of time, it would potentially be a good idea to take a look at a book or two on the language they’re using. You don’t need to become proficient, but you should understand the concepts they’re working with. _Special thanks_ to Matt Nowack ([blog](http://ihumanable.com/) | [twitter](http://twitter.com/ihumanable)) and Mike Peschka ([blog](http://atomicmike.com/) |[twitter](http://twitter.com/JudgeOfCheese)) for reviewing this and providing feedback. Also, thanks to Aaron Nelson ([blog](http://sqlvariant.com/wordpress/) | [twitter](http://twitter.com/sqlvariant)) for the original questions that sparked this blog post.
