Protected: Paper trails

This content is password protected. To view it please enter your password below:

Posted in Fundamentals, Fundamentals, Programming, Uncategorized, Windows | Enter your password to view comments.

Protected: SQL Concatenation is evil

This content is password protected. To view it please enter your password below:

Posted in Uncategorized | Enter your password to view comments.

Protected: Adventures in refactoring

This content is password protected. To view it please enter your password below:

Posted in Fundamentals, Fundamentals, Programming, Windows | Tagged | Enter your password to view comments.

Protected: Adding More Paperwork

This content is password protected. To view it please enter your password below:

Posted in Fundamentals, Fundamentals, Programming, Windows | Tagged | Enter your password to view comments.

Interfaces and other abstractions

In object orientated development, you most commonly work with objects. Objects are like little gadgets that you use to make your program do things. You do so by interacting with methods and properties of the object. That is their interface.

Think of an object like a tiny game console. You read the object’s properties (stare at the screen), and call its methods (push the buttons). (So yes, software development is exactly like playing video games.)

So, let’s say your video game interface has a property (screen), and two methods (left joypad and right button). Suppose you’re designing a robot that will play video games. You could program your robot with code that says “If you’ve got a Super GameGlab, use the screen, the left joypad, and the right button”. Then later maybe add another bit of code that says “If you’ve got a Ultra Game-o-matic, use the same approach, and if you’ve got a Mega GameTark, use the same approach”. The more game consoles you support, the more “use this one too” bits of code you need.

You wind up with a mess like this:

Java

public class SuperGameGlab {
    public void joypad(int velocity, int direction) { ... }
    public void button(int state) { ... }
    public Object screen() { ... }
}

public class UltraGameOMatic {
    public void joypad(int velocity, int direction) { ... }
    public void button(int state) { ... }
    public Object screen() { ... }
}

public class MegaGameTark {
    public void joypad(int velocity, int direction) { ... }
    public void button(int state) { ... }
    public Object screen() { ... }
}

public class Robot {
    public void PlayGame(Object gameunit) {
         if (SuperGameGlab.isInstance(gameunit) ||
             UltraGameOMatic.isInstance(gameunit) ||
             MegaGameTark.isInstance(gameunit) {
                 DoSomeRobotGaming(gameunit);
         }
    }
}

That’s all great. But then you sit down and meditate on this and realize that there are lots of different video game consoles that use this same control interface, and if you want your robot to play all of them, you have to keep expanding your “if” statement and your list of supported classes. But then you realize that you only really need to support the interface itself, not the particular game consoles that implement it.

You might think that’s a good case for a common base class, and you’d be right. You could extract a common base and make your code look more like this:

Java


public class GameConsole {
    public void joypad(int velocity, int direction) { ... }
    public void button(int state) { ... }
    public Object screen() { ... }
}

public class SuperGameGlab extends GameConsole {
}

public class UltraGameOMatic extends GameConsole {
}

public class MegaGameTark extends GameConsole {
}

public class Robot {
    public void PlayGame(GameConsole gameunit) {
        DoSomeRobotGaming(gameunit);
    }
}

That’s certainly a lot cleaner, and if the game consoles don’t actually vary much, you may not even need the descendant classes at all.

But then one day, you decide that your robot’s uncanny accuracy and lightning reflexes could be best employed to plunder a prize from one of those mechanical claw games at the mall. You look at it and realize it’s basically the same concept — a joystick rather than a joypad, and a button. But it’s not a game console, and your generic GameConsole class won’t quite work. But the way you interact with it — the interface — is the same.

So you change up your code like this:

Java


interface IGame {
    void joypad(int velocity, int direction);
    void button(int state);
    Object screen();
}

public class GameConsole implements Game {
    public void joypad(int velocity, int direction) { ... }
    public void button(int state) { ... }
    public Object screen() { ... }
}

public class SuperGameGlab extends GameConsole {
}

public class UltraGameOMatic extends GameConsole {
}

public class MegaGameTark extends GameConsole {
}

public class PlunderCrane implements IGame {
    public void joypad(int velocity, int direction) { ... }
    public void button(int state) { ... }
    public Object screen() { ... }
}

public class Robot {
    public void PlayGame(IGame gameunit) {
        DoSomeRobotGaming(gameunit);
    }
}

The difference is the IGame interface. An interface is a specification for how an object must present itself. It says “anything calling itself an IGame must have these properties and methods.” The actual class can be any kind of class it wants, and doesn’t have to extend anything in particular. This means your PlunderCrane class is free to implement its methods in whatever way it wants, with no dependency on GameConsole, since it isn’t derived from it. But your robot doesn’t need to care, it just knows it presents an IGame interface and that’s how it knows how to play it. This is because the PlayGame method no longer says what kind of class will be passed in, only what kind of interface that class must have.

This flexibility in being able to implement things in different ways is particularly important in things like Collections. For example, a very common thing to do in a collection is to walk the elements of the collection. Nearly every collection is going to implement in iterator of some sort for this purpose. But since collections can vary wildly in their implementation (stacks, queues, arrays, linked lists, etc), requiring them all to extend a common iterator could be problematic. So instead, an iterator interface is used so that any collection can present an iterator as a way to walk the elements of the collection, regardless of how the collection is actually implemented.

Another important difference between interfaces and base classes is that your class can only extend one base class, but you can implement as many interfaces as you like. So your PlunderCrane might implement IGame, and it might also implement IPlushToyDispenser or ICoinOperated, or whatever else your application called for. Or in the case of collections, a collection might implement an iterator interface, a disposable interface, a serializable interface, and so on.

Or to put it another (oversimplified) way, an interface says what an object can do. A base class says how. Generally, you should prefer and program for interfaces rather than classes. It leaves you a lot more flexibility without sacrificing coding clarity.

Posted in Uncategorized | Leave a comment

Protected: Expressive code and the Library

This content is password protected. To view it please enter your password below:

Posted in Uncategorized | Enter your password to view comments.

Java Development on Windows

This is a followup to Prepping for Java, with specifics about setting up a Java development environment on Windows.

First, you have to install the JDK. I already had a Java JRE on my Windows system, so I went through the Control Panel and uninstalled all existing versions of Java first, though I don’t know if that’s really necessary. You can get the JDK from Oracle at this link. You will need to hit the button to accept their software license agreement first, then choose the appropriate version for your Windows installation. If in doubt, use the one for 32-bit Windows.

When you install the JDK, it will ask where you want to install it, with a default location being in a folder somewhere under “c:\Program Files”. Since some java tools may balk at spaces in the path name, you should change that to a path without spaces. I put mine in c:\apps\java\jdk but you can use any path you like.

Next, you’ll want to install an IDE. I prefer IntelliJ. Just download and run the installer as usual. You can download the ‘Ultimate’ edition if you like, though you’ll need to pay for it after a trial period, or you can download the Community edition, which will work fine too, it just doesn’t have quite as many bells and whistles. You can just take the defaults on everything to start with. All the add-ons and plug-ins can be installed later if you need them.

For JavaFX GUI work, you may want a copy of Scene Builder, which you can download at GluonHQ. (It used to be part of the JDK, but Oracle spun it off as open source.) It is optional — you can define your GUI entirely in XML, but Scene Builder does make visualization much simpler. Just download and install in the usual way. Again, if in doubt of which one to choose, go for the “x86” version.

And last but certainly not least, you’ll need Maven. You can grab the Windows version at this link. Download the zip version, and unzip it to someplace convenient. I put mine as a sibling of the jdk, at c:\apps\java\apache-maven-3.3.3. You will then need to update your system environment variables to change two things: First, update your path and add the “bin” folder of the maven installation to your path. Then you will need to add an environment variable called “JAVA_HOME” and set the value to the place you installed the JDK (in my case, c:\apps\java\jdk). You do not want the JAVA_HOME pointing to the binary folder, just to the main installation folder.

Now you should be able to open a new command prompt and try these two commands:

java -version

mvn -version

The first should tell you that Java is installed and what version it is. The second should verify that Maven is working and tell you what version it is. If the “java” command fails, make sure the jdk bin folder is in your path. (The JDK also installs a JRE, but you should prefer the jdk version of java for this purpose.) If the “mvn” command fails, check that you have your JAVA_HOME set correctly and that the maven binaries are in your path.

For building native installers for your java apps, you no longer need Launch4J. It does put a pretty GUI on a bewildering number of options, but you can more easily accomplish the same thing with the native installer tools built into the JDK directly. There is a maven plugin which adds a maven build action to make native installers for JavaFX applications with a simple command line: mvn clean jfx:native. That will make your JavaFX app seem like a native app, with its own bundled JRE and everything. The user need not worry about installing Java or anything, just run your installer, then run your app. Easy. Note that for multiple platforms, you will need to build the installer on each platform you intend to target.

Posted in Fundamentals, Java, Windows | Tagged , , , | Leave a comment

Actors and Boxes

Most people think computer programming is about making computers do something. And it is that, but that’s not the important part. The important part, the real challenge in writing software, is task management.

Suppose you want to build a new room on your house. That is your task — “Add a room”. But to actually accomplish it, you need to break that down into smaller tasks. Maybe things like “take some measurements”, “get some lumber”, “drive some nails”, “paint the walls”, and so on. Then each of those will get broken into smaller tasks, like “cut a 2×4 to 94 inches”, “Align 2×4 with mark on east wall”, “Drive nails into 2×4”, and so on.

And so it goes. You have a high level task that is the goal. You break that down into sub-tasks with smaller goals, and break those down further until you get to small, simple tasks that you can actually accomplish. This is the core of software development.

Objects as Black Boxes

There are a few different ways to approach this paradigm, but the two most common software development methods are “procedural” and “object oriented”. A procedural approach will take the sub-tasks, put them in order, and do them. For example:

VB

Public Sub AddARoom()
    Dim width = MeasureWidth()  ' Dimensions are in inches
    Dim height = MeasureHeight()
    Dim length = MeasureLength()
    Dim num2x4s = (((width / 16) + 1) * 2) + (((length / 16) + 1) * 2)
    Dim haveLumber = BuyLumber(num2x4s)
    Dim haveNails = BuyNails(8 * num2x4s)
    If haveLumber And haveNails Then
        BuildWalls()
        ' and so on ....
    End If
End Sub

Java

public void AddARoom() {
    int width = measureWidth();
    int height = measureHeight();
    int length = measureLength();
    int num2x4s = (((width / 16) + 1) * 2) + (((length / 16) + 1) * 2);
    boolean haveLumber = buyLumber(num2x4s);
    boolean haveNails = buyNails(8 * num2x4s);
    if haveLumber && haveNails{
        buildWalls();
        // and so on
    }
}

The procedural approach is “top down” — you start at the top of the program and work your way down to the bottom. It’s a laundry list of instructions that you check off one by one until you’ve finished the task.

Object oriented programming takes a different approach. Instead of thinking in terms of tasks, it thinks in terms of objects. It will still have tasks, of course, but those tasks are part of the objects. That’s what an object is — a representation of some “thing”, which contains data and methods characteristic of that “thing”. An object oriented approach to the Add A Room task might be more like this:

VB

Class Room
    Public Integer Width
    Public Integer Height
    Public Integer Length

    Public Sub new(wide as Integer, high as Integer, howlong as Integer)
        Width = wide
        Height = high
        Length = howlong
    End Sub

    Public Function calculate2x4s() as Integer
       return (((Width / 16) + 1) * 2) + (((Length / 16) + 1) * 2)
    End Function

    Public function calculateNails() as Integer
        return calculate2x4s() * 8
    End Function
End Class

Class SupplyStore
    Public Function buyLumber(num2x4s as integer) as boolean
       ...
    End Function
    Public Function buyNails(numNails as integer) as boolean
       ...
    End Function
End Cass

Class Builder
    Public Function buildWalls(theroom as Room) as boolean
        ...
    End Function
End Class

' ... elsewhere...

Public Sub AddARoom()
    Dim newRoom as Room = new Room(MeasureWidth(), MeasureHeight(), MeasureLength())
    Dim store as SupplyStore = new SupplyStore()
    Dim haveLumber = store.buyLumber(newRoom.calculate2x4s())
    Dim haveNails = store.buyNails(newRoom.calculateNails())
    If haveLumber And haveNails:
        Dim mybuilder as Builder = new Builder()
        mybuilder.BuildWalls()
        ' and so on ....
    End If
End Sub

Java

class Room {
    int width;
    int height;
    int length;

    public Room(int wide, int high as Integer, int howlong) {
        width = wide;
        height = high;
        length = long;
    }

    public int calculate2x4s() {
       return (((width / 16) + 1) * 2) + (((length / 16) + 1) * 2);
    }

    public int calculateNails() {
        return calculate2x4s() * 8;
    }
}

class SupplyStore {
    public boolean buyLumber(num2x4s as integer) {
       ...
    }
    public boolean buyNails(numNails as integer) {
       ...
    }
}

class Builder {
    public boolean buildRoom(Room theroom) {
        ...
    }
}

// elsewhere...
public void addARoom()
    Room newRoom = new Room(measureWidth(), measureHeight(), measureLength());
    SupplyStore store = new SupplyStore();
    boolean haveLumber = store.buyLumber(newRoom.calculate2x4s());
    boolean haveNails = store.buyNails(newRoom.calculateNails());
    if haveLumber && haveNails{
        Builder myBuilder = new Builder();
        myBuilder.BuildWalls();
        // and so on ....
    }
}

While the difference in these approaches may look mostly semantic at first glance, there are actually very important design differences.

In the procedural approach, the AddARoom method is doing task management. It is keeping track of dimensions, it knows how to figure out the number of boards and nails needed, and other related housekeeping. It has to micro-manage. In the object-oriented approach, the AddARoom method only manages a few objects and doesn’t need to micro-manage them. It has a room object, and that room knows how to figure out how many boards and nails are needed. It has a store object that handles purchasing supplies. And it has a builder object that knows how to build the room.

One of the advantages of the object oriented approach is that each of the objects is a self-contained unit. The application doesn’t need to concern itself with the details that go on inside the object. When you drive a car, you don’t need to understand compression ratios, air-to-fuel mixtures, ignition timings, or valve dwell. You just turn the key, knowing there’s a motor under the hood that takes care of all those mechanical things for you. It’s the same with objects. You don’t care how a room knows the number of boards it needs, only that it does. You don’t need too worry about what goes on when you tell a SupplyStore object that you need some nails, only whether or not it delivered the nails. This simplifies your application. It also makes maintenance simpler. Suppose for example that your city planning department decrees that new rooms should have boards on 12 inch centers rather than 16. A change to the calculation function in the Room object is all that is needed. Every application that uses the room object will automatically pick up the change, without needing to change a single line of the main application code.

The fact that the objects are self-contained also gives you a big advantage in that it makes those objects testable all by themselves. If you want to check that a room calculates the correct numbers for boards and nails, for example, you can create a unit test that checks against a known value. If a certain room dimension actually needs 100 boards, you can feed those dimensions to an object and check whether it returns 100 for the number of boards. This is valuable because it proves your assumptions about how the object operates. If the object gets changed at some point and returns 103 instead of 100, your unit test will fail and alert you that something is wrong — either a bug in the object itself, or an error in your expectations of what it will return.

Objects as Actors

It is typical for a procedural program to behave as a single sequence of actions. It is like a one-person company. If that person is you, you go and measure the area you want to put a room. Then you figure out the supplies you need. Then you go to the store and get the materials. Then you start sawing boards and swinging hammers. In this scenario, nothing gets done unless you do it. You are the sole actor.

In the object oriented approach, each object may be an actor. It is like you hired a bunch of employees. When you want to build the room, you tell Fred to go measure the area. You then give those dimensions to Joe, who calculates the dimensions and materials needed. You then send Jane to the store to pick up supplies. And finally you tell Bob (the builder) to begin construction. Each object is an actor that performs a part of the overall task. All you did was manage who did what when.

In the simple scenario we’ve described so far, there may not seem to be much advantage. But when you break out of thinking in a single sequence into the possibility of multiple things happening at once, the advantages become significant. Suppose you want the room to have windows and carpeting. In the procedural example, you’re probably going to do all the steps we’ve listed, then after the walls are framed, measure for the windows, go buy them, come and install them. Then you’ll calculate how much carpet you need, go buy it, and come put it in. Then you’ll need to calculate the roof area, go buy more lumber, and so on. If you’ve ever seen a house being built, you know this isn’t how it works. (Well, sometimes it is, but most often it isn’t).

In the real world, things happen in parallel. You can have one guy hammering nails while another guy is measuring for carpet. You can have one guy laying roofing while another guy is installing windows. And you can have someone installing carpet while someone else is painting the exterior. An object oriented approach to software design makes it easier to replicate this scenario.

For example, with a few changes to your classes, your code might look something like this (class definitions omitted, you should get the idea. Explanation follows):

Java

class RoomManager {
    private SupplyStore store;
    private Builder builder;
    private Roofer roofer;
    private WindowInstaller windowGuy;
    private CarpetInstaller carpetGuy;
    private Room room;
    private Map<String, boolean> steps;
    private int problems;
    
    public RoomManager(int width, int height, int length) {
        store = new SupplyStore();
        builder = new Builder();
        roofer = new Roofer();
        windowGuy = new WindowInstaller();
        carpetGuy = new CarpetInstaller();
        room = new Room(width, height, length);
        steps = new Hashmap<String, boolean>();
        steps.put("walls", false);
        steps.put("roofing", false);
        steps.put("windows", false);
        steps.put("carpet", false);
    }

    public boolean isFinished() {
        boolean allDone = true;
        for(Map.Entry<String, boolean> entry : steps.entrySet())
            if(entry.getValue() == false) {
                allDone = false;
                break;
            }
        return allDone;
    }

    public void AddThisRoom() {
        roomIsFinished = false;
        problems = 0;
        Map<String, int> shoppingList = new HashMap<String, int>();
        shoppingList.put("lumber", room.calculate2x4s());
        shoppingList.put("nails", room.calculateNails());
        shoppingList.put("roofing", room.calculateRoofing());
        store.buy(shoppingList, this::lumberDelivered);
        while(!roomIsFinished) {
            goHaveCoffeeAndDonuts();
            if (problems > 0)
                handleProblems();
        }
    }

    private void lumberDelivered() {
        Map<String, int> shoppingList = new HashMap<String, int>();
        shoppingList.put("windows", room.calculateWindows());
        store.buy(shoppingList, this::windowsDelivered);
        builder.frameWalls(this::finishedWithWalls);
    }

    private void windowsDelivered() {
        windowGuy.installWindows(this:finishedWithWindows);
    }

    private void carpetDelivered() {
        carpetGuy.installCarpeting(this::finishedWithCarpet);
    }
   
    private void finishedWithWalls() {
        steps.put("walls", true);
        roofer.buildRoof(this::finishedWithRoof);
    }

    private void finishedWithWindows() {
        steps.put("windows", true);
    }

    private void finishedWithRoof() {
        steps.put("roofing", true);
        Map<String, int> shoppingList = new HashMap<String, int>();
        shoppingList.put("carpet", room.calculateCarpeting());
        store.buy(shoppingList, this::carpetDelivered);
    }

    private void finishedWithCarpet() {
        steps.put("carpet", true);
    }
}

For the moment, assume that each of the actors involved (roofer, builder, etc) will put themselves on a background thread and run in the background. They are each given a method to call when they get done. This is equivalent to you telling the store guy to deliver a load of lumber and call you when he gets there and gets it off the truck. You’re just directing objects. And they are all free to operate on their own schedules while you go have coffee and donuts. The control flow goes like this:

  1. You make a shopping list with details from the room object, and hand it to the store object.
  2. When the store delivers the materials, they call and interrupt your donuts. You order the windows and tell the builder to frame the walls.
  3. While the walls are built, the windows are delivered. When they get there, you get another call, and you then tell the window guy to go install the windows. (Note that you probably need a check to make sure the walls are in before you put in the windows, but that’s omitted for the sake of brevity here.)
  4. When the framer gets done, he calls you and you tell the roofer to get busy while you go back for more coffee.
  5. When the roofer finishes, he buzzes you, and you order the carpet, still munching on donuts.
  6. When the carpet is delivered, you tell the carpet guy to go to work.
  7. After every few donuts, you check to see if everything is done yet. If not, you check for any problems and handle them, then go back to waiting.

This is obviously simplified but you should get the idea. You (the application) don’t need to know or care how each of the actors (objects) involved does their job, only that they do it, and let you know when they’re done. You don’t care if the windows go in before the carpet, or if the roof is done before the windows are in. And for those things where order does matter (for example, you don’t want carpet installed before the roof is done), you handle those in the methods that handle the various tasks getting completed. All you really have to do is make sure all the steps actually get done, and you can come back and lay on the new carpeted floor and snooze from the sugar coma you put yourself into with all those donuts.

An added advantage of this approach is it unhooks the steps from the process. If you want to add a patio, or some hedges, or whatever, all you do is add calls to some additional objects, add them to the list of steps, and make sure they get checked off when they’re done. No need to worry about the details of each task. Your application stays nice and tidy while you let the actors do their jobs.

Posted in Fundamentals, Programming | Leave a comment

Prepping for Java

Java logo and wordmark

So you want to write some Java — now what?

Tools

First you need some tools. Every Java developer is going to have their own preferred tool set, so don’t be upset if my list doesn’t include your favorite. It’s nothing personal. Here’s how I’d set things up.

First, you have to install the Java Developer Kit (JDK). You can download it from Oracle at this link. Install the version appropriate for your platform.

Next you need a development environment. Well, technically, you don’t need one, but you’ll want one. Java source files are just plain text files, so you can edit them in notepad or vi or emacs or whatever you like. But that’s like rubbing two sticks together to start your campfire when there’s a lighter in your pocket. So install an IDE. I like the IntelliJ IDE from JetBrains. There is a free version and a paid version, and you can try the paid version before you buy it. When you install, you can just take the default settings. You don’t need to install any of the optional components, at least not at this point.

The next thing you’re going to want is Maven. Maven is a build tool and package manager, among other things, and you can get it from the Maven site. If you’re installing on Windows, you might want to take a look at this page for information specific to Windows. If you’re on Mac, you can install it from the site, or via Homebrew or Macports. For Linux, use your package manager (ie, apt-get install maven).

With those tools you’ll have a good foundation to start making Java projects. If you’re going to deploy to Windows, you can make it easier for your users with a tool like Launch4J, which will wrap your jar file in a Windows executable, prompting the user to install the required Java version if necessary.

Tutorials

Next, if you haven’t already, you should work through some Java tutorials covering the basics. Just start at the top and work your way down. Don’t be tempted to skip ahead — especially if you’re not already familiar with object-oriented development. If some of it is review for you, so much the better — you’ll get through it quickly. You don’t need to do every tutorial, but you should do all the basics up until you get to the GUI section. You can then skip the Swing section and go straight to JavaFX for GUI work.

Here are some random things that may bite you if you’re coming from VB or similar languages.

  1. Everything is an object
    If you’re coming from a procedural language or background, you’ll want to get your head around Object Orientation. In Java, programs are built from objects. There are no standalone procedures, and there are no global variables. Programs are entirely built from objects talking back and forth to each other.
  2. Everything has a type
    All variables and parameters have a type, and that type has to be declared in the source file. You can’t just say “foo = 5” without first having said what foo is. For example, “int foo;” declares foo to be a variable of type int (integer). It’s the same with parameters. You can’t declare “function bar(arg1, arg2)”, but you can declare “String bar(int arg1, String arg2)”. That says that “bar” is a function which takes two arguments, an integer and a string, and returns a String. Everything is declared at compile time.
  3. Equals is not a comparison!
    In some languages, most notably VB and VB.Net, the equals sign is both an assignment operator and a comparison. You can say “foo = 5” to assign foo the value of 5, or you can say “if foo = 5 then …” which will compare foo to 5. Java does not work that way. The equals sign is always for assignment. If you want to compare, you use two equals signs. Saying “if (foo = 5)” in Java will always evaluate as true, even if foo is never 5, because that statement assigns 5 to foo. You would need to say “if (foo == 5)”.It is not uncommon to see assignments written “backwards” because of this. For example, “if (5 == foo)”. The reason is to prevent accidental errors. If you mean to code “if (foo == 5)” but you accidentally type “if (foo = 5)” then you will have a bug. And depending on where it happens, those kinds of bugs can be pretty hard to spot later. By typing it as “if (5 == foo)” you will cause a compile error if you leave out one equals sign, since 5 isn’t a variable and can’t be assigned to.Also note that for more complex objects (including Strings), you’ll want to use the .equals() operator instead anyway. See your Java tutorials for more detail about that.
  4. Case Matters!
    Java is case sensitive. Two variables named “Bar” and “bar” are entirely separate and have no inherent relationship to each other.
  5. Exceptions are the rule!
    Error handling in Java is done with exceptions. There is no such construct as “on error goto …” (In fact, not only is there no “on error goto”, there is no “goto” of any kind.) Not only that, but if you call a method which is declared as throwing an exception, you must handle that exception. You can turn around and re-throw it if you like, but you can’t just ignore it.
Posted in Fundamentals, Programming | Tagged , | 2 Comments

Thinking about Objects

Last time we looked at cleaning up the global space. We cleaned up the clutter in the global namespace by encapsulating lots of little bits of data into user defined types.

But even after doing that, there are times when there are lots of different routines that need access to that data. You might be tempted to go ahead and make the user-defined type global so you don’t have to keep passing it around to everything. But there is a better way. Continue reading

Posted in Fundamentals, Programming | 1 Comment