What’s so regular about “^(XF)?(CAT|DOG)([\d]+|[^KSCBMT]+)$” anyway?
Regular expressions are an extremely powerful tool for dealing with text input of all kinds. They are “regular” in the sense that there is a very specific way of defining them, so that you can get the results you desire. Regular expressions have their roots in POSIX and Perl, but have now been adopted by many tools and toolkits across many platforms.
Continue reading
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:
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:
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:
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.
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.
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.
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:
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
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:
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
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.
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):
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:
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.
Recent Comments