Time for another dose of developer zen. This time I’ll try to take a
quick look at OOP (object oriented programming) and some issues which
can occur if you are transitioning from procedural languages (AML) or
pseudo OOP languages (VB6 & Avenue). To start with, I think it’s
worth noting that just because you are using an object oriented
language (Java,C#, VB.NET etc.) does not mean you are writing /
designing your code in an object oriented manner. I think this may be
an afront to some people, but it’s just the truth. You can write
procedural code in any OOP language. And it can work. But there’s just
so many reasons not to.
In this article, I am simply listing 3 things you should try to avoid. For more detail on
Object oriented programming,
hit Google. Of course, you can ignore these warnings, but if you have
to try to maintain or grow your code, you will run into problems.
Design As You Code
This is also known as “no design”, or
hacking. Honestly, if you ever take anything away from this blog, I
hope it is this: Always design before you code. The level to which you
take this typically depends on what you are doing. If it’s a quick
one-off VBA script to rename a set of files, then just jotting down a
bullet list of “requirements” is enough. If you are trying to create
complex workflow managment system for a diverse set of users, you may
have several 1000 pages of requirements. In either case, having a
design is critical, if for no other reason that it can tell you when
you are done (i.e. all requirements are met). At some point I’ll post
about our design process, which tries to do “enough” design without
going crazy with UML, but that’s a little past the fundamentals.
GIS Data Objects “Special”
Many times I’ll see code where the
developer has used objects for all kinds of things, but when it comes
to the actual GIS datasets (feature classes etc), they are alway
treated differently. It’s important to understand that in most cases,
you can use these types just like any other types (string, int,
arraylist etc). The reason we model things as objects is that there is
some inherent relationship between them. And if one of the items that
particpates in the relationship is a featureclass, then add it as a
property of the class. Granted, you’re not going to be able to
serialize the class out to an XML file and expect the featureclass to
go along, but you can work around those cases. The point here is to not
be shy with these things. It’s also a departure from typical GIS
thinking, which can be hard for people just beginning to make the
shift.
Side Effects (or Why Globals are Evil)
Unlike special effects in movies, these are bad things to encounter. A
“Side Effect” occurs when something effects the internal
implementation, in a way which is not expected. The end result is code
which may “look” correct, but acts incorrectly in certain situations.
The code below show a pretty contrived example. It has a property
“ShoeSize” and a method “Add”. Add takes two integers, and returns an
integer. The developer would expect that add would simply return the
sum of the two numbers. However, if ShoeSize is set, it returns the sum
of the two numbers plus shoesize.
1 Public Class SuperClass
2
3 Private _shoeSize As Integer = 0
4 Public Property ShoeSize() As Integer
5 Get
6 Return _shoeSize
7 End Get
8 Set(ByVal Value As Integer)
9 _shoeSize = Value
10 End Set
11 End Property
12
13 Public Function Add(ByVal firstNumber As Integer, ByVal secondNumber As Integer) As Integer
14 Return firstNumber + secondNumber + _shoeSize
15 End Function
16
17 End Class
This is a very extreme example, but I think it shows the general idea.
The method Add does not indicate that anything else is involved, yet in
some cases (ShoeSize != 0) it will return an unexpected result, which
will be very difficult to track down. A very common way to end up with
a mess of side effects is through the use of “global” variables. In
this case, a the variable gets set in one place, and then used in some
other location which is not apparent to the developer. These sort of
problems are really tough to track down. I’ve seen projects where it
cheaper and faster to delete the application and start again rather
than trying to sort out what was going on. Good Luck!