The main()

The simple definition/purpose of the ‘main()’ method? It’s the starting point for every single Java application you’ll ever write, and this one and only main() makes up the entire life of the program. Once main() starts you’re program is running, and once it exits then your program dies. That’s all it does, really.

I’ll give you some background on the details here, hopefully to reduce the ‘magic’. In the “public static void” part the “public” is the signature that is required as a main() must be accessible to all interested invokers, ‘static’ signifies this method is always run in an identical environment with no worry about conflicting instances (read more on static elsewhere), and ‘void’ designates that there is no return type from the method. The args variable, or whatever you choose to name it, is the array of command line inputs that you specified beyond the name of the Java class. Easy, right?

The Constructor

Constructors are an entirely different beast: an object that is created in a runtime is created by explicit or implicit call to that object’s constructor, essentially establishing the working space for that object. You can have many different constructors, too, but only one can be called for each object that you create. The most common place you see this is in the “new Person()” call where the ‘new’ keyword indicates a new instance of this event, as created in the constructor call ‘Person()’. I know this is getting crazy, but just look at the following example.

public class Galaxy
{
public boolean isSpiral;
public boolean hasLife;
public Galaxy()
{
isSpiral = (Math.random() > 0.5); // 50-50 chance of being spiral
hasLife= (Math.random() > 0.99999999); // tiny chance of supporting life
}
public Galaxy(boolean isSpiralp)
{
isSpiral = isSpiralp; //Specified before creation, guaranteed to be what is requested
}
public Galaxy(boolean isSpiralp, boolean hasLifep)
{
this(isSpiralp); //Call other constructor
hasLife = hasLifep; //set life
}
}
class Universe
{
public static void main(String[] args)
{
Galaxy sagittariusDwarf = new Galaxy(false);
Galaxy milkyWay = new Galaxy(true,true);
Galaxy peacefulProgrammer = new Galaxy();
milkyWay = peacefulProgrammer;
}
}


In this example Galaxy cannot be started by itself, some other program with a main() method (if it’s an application) must actually create the object through the constructor. In this case, we find an example in the Universe class. The Universe ‘starts up’, creates a few galaxies (overwrites some lesser galaxies), and then flickers out and dies. I know it’s sad; pay attention!

The Galaxy object isn’t limited to being used only in the Universe class, but it’s just what we used here. Anything, in theory, could instantiate this galaxy object. I’ve met few girls with Eyes that seemed to instantiate a couple of Galaxy objects, but that’s another blog post.

Self-referential, complicating monkey-wrench.

Some situations call for main and constructor methods, and the constructor could be created inside the runtime. The reason for this is often that the object itself may be created within another program, or it could be something that stands alone. In the case of the universe example, it’s a theology question. If Universe is a class that can be independent of any other class and can suffice by it’s internal definition (a.k.a the programmer is an atheist), then you can just run Universe to create it’s own instance.

public class Universe
{
public static final int TOTAL_ATOMS_POWER_OF_TEN = 81;
public static final boolean IS_STRING_THEORY_LEGITIMATE = false;
public Sphere core;
public void Universe()
{
core = new Sphere(1,1);
for(int i = 0; i < TOTAL_ATOMS_POWER_OF_TEN; i++)
{
core.increaseDensity(10.0);
}
}
public void bang()
{
//code to cause bang
}
public static void main(String args)
{
Universe everything = new Universe();
everything.bang();
}
}

Now suppose the programmer isn't an atheist, then we've got a bit of a problem. We need somebody driving this crazy bus we call life; which will work out totally fine. In fact, not only can we create God, but we can make sure that he's got enough power to create more than one universe. Mix the following class into the Java file for the above and add water:
class God
{
public static final POWER_REQD_PER_UNIVERSE = 42;
private int power;
Vector multiverse;
public God()
{
multiverse = new Vector multiverse;
power = POWER_REQD_PER_UNIVERSE;
}
public void createUniverse()
{
power += POWER_REQD_PER_UNIVERSE;
Universe temp = new Universe();
temp.bang();
multiverse.add(temp);
}
public void getHaircut()
{
//code to get haircut
)
public static void main(String[] args)
{
God me = new God();
me.addUniverse();
me.addUniverse();
me.getHaircut();
}
}

The best thing about designing the original universe to allow for versatile, constructor-based invocation is that we didn't have to change the Universe object to allow for God to create a Universe. In this way we create Universe to be God-agnostic.

I can't believe I wrote an entire blog post just to get to tell that joke.

My case is rather simple; programmers are trained to think in primarily object oriented environments, especially in recent years. Most, if not all, have had some formal training in object oriented modeling using UML or de facto standards in structure design (database or other). This is not coincidence. The reason for this trend is that objects can easily, and often must, be modeled for clarity in design and maintenance. But what isn’t obvious is how those models are generated.

Somewhere in our brain we can start to solve problems and make concrete these relatively abstract relationships with a certain degree of ease.  Not everyone can do it, but most people can draw a diagram of a workflow or an object model. It may be slow but it can be done by most functioning individuals; the key to success is practicing this method.

The trick to being a good modeler is a lot like being a good programmer: process, practice, and perception. You recognize relationships and patterns between past and present problems that allow for streamlining; this is the process. As you do more to practice this process then it can become easier as you have more cases to study and experience to pull from. But the mere act of this problem solving takes a certain flair for the spatial. The perception of the problem and, more importantly, the solution deals entirely with the multidimensional aspects of relationships.

So that brings us to the thesis: training the mind to recognize shapes and objects in their elemental forms will allow for a much easier command when high level design is required. Logically, the drawing tools used by architects and others to define 3-dimensional objects in 2-dimensional space would lend themselves to programmers who deal with multidimensional objects, relationships, and even data. Eventually our goal is the same: get that complex object into an understandable 2-dimensional model. At least until we get the 3-dimensional hologram projectors in the conference room.

To use a personal example, just today I was given a rather daunting task: design a class representation of elements in the TCP/IP stack and a driver that can use those classes to examine network traffic. In addition, this task is part one of three and the code generated should be usable as a larger part of an elementary IDS capable of handling Snort signature rules.

So what did I do? I reached for the notebook and drafting pencil and started sketching out an object model that would best represent the solution with plans for expansion into the second and third phase of the product.  It was elementary, but because I’ve done it before and because of some spatial techniques picked up in Art and Drafting classes, I was able to create a logical model that represented the first picture of the solution.

Of course my solution may not be ready for a text book just yet, but the original draft gives me a lot to work with. Eventually I can redistribute the objects to be a well balanced diagram. I honestly think that this skill is one of the most important ones in the programmer’s tool belt, and one of the best for limiting scope and thinning the FUD fog.

Ps. Part of my research shows a potential correlation to this concept between drawing maps and success in early programming courses (Do map drawing styles of programmers predict success…). It doesn’t have any particularly conclusive results, but it does tickle the brain a bit. Doesn’t it?

Let me know whose side of the argument you’re on. Am I adding unneccessary recommendations to a field already taxed with educational scope creep?

It boast an expansive built in syntax-higlighting library and great tools for automating some of your frequented commands. But a major problem, aside from the inability to do multi-line regex stuff, is the way comments are set up. I found out that I love the fact that it shrinks them, but I hate that it uses a non-monospaced font. But you can fix it, and fast.

First open up your %APP_DATA%/Notepad++/stylers.xml file in Notepad++. The APP_DATA variable usually points to your ‘Documents and Settings/youruser/Application Data’ folder, but I could be wrong. Then do a find and replace to find “Comic Sans MS” and replace it with “”. That’s right, nothing.  Save and restart Notepad++ and you are ready to rock.

Thanks to Nathan for pointing this out to me. I’m fairly confident that he doesn’t even know I have a website. The only place I don’t talk about it, annoyingly, is at work.