Most of the questions you’re asking are handled in Chapter 1; so if I miss something, you can probably find it there. In both OOP and Design Patterns, there are no simple explanations that will cover everything; especially the good questions that you are asking, and so I’ll also have some links to other posts on this blog that will help out. If you haven’t done so already, download the AIR app with all of the major design pattern principles. The principles make up the bulk of the “whys”—each of the principles is discussed in detail, and you can find them all in the Index of this blog. The AIR app is just a handy reminder of them that you can put on your desktop.

The simple answer for using the private accessor is to encapsulate properties or functions. In this particular case, the OOP programmer wants to use the MovieClip in the Library. However, he just needs the image aspects of it; so he types it as the parent class, Sprite. Had he needed to use timeline methods, he would have typed it as a MovieClip. His Warrior class provides a set of behaviors (methods) for all warriors; but to have flexibility, the Warrior class does not include images. Therefore, the developer can subclass the Warrior and then add sprites that provide a visual representation—in this case the Red and Blue warriors.

As for keeping track of the x and y values in the positions, you’re right. It doesn’t do that. All this example is doing is setting up a straw man (of sorts) to show how this approach (even though using OOP) will fail as soon as more behaviors are added. In Part II here, you see that there’s no movement at all. Instead, using a Strategy design pattern, the behaviors are encapsulated in a separate set of classes around a common interface (Fire).

However, you will notice that a couple of commented-out statements hint to the possibility of encapsulating both movement and communication. The latest Golden Lunch Bucket Contest also shows these tantalizing possibilities. You can create any kind of movement you want by setting up a Movement interface (either as an abstract class or interface) and then using composition, have your warriors move as you like. As you say, the way to go may be with an array. Why not try it out with your ideas and enter the contest? Later, you and KKCosmo can implement the Communication interface and have the Lieutenant bark orders that will set the platoon in motion! (Give the Lieutenant that redneck accent that Brad Pitt uses in Inglourious Basterds.)

Kindest regards,
Bill

Be well.

This is all about extending existing programs; so you can make it anything you want. Why not start with something simple?

Take care,
Bill

Glad to hear it. As for suggestions, let’s see something a bit more… Maybe you can add a light mortar crew… I realize they’re not part of the platoon TOE, but we’ll pretend that the platoon receive a light mortar crew (3 members) to provide added defense against an attack by hordes of Unencapsulated Code Zombies. (How’s that for motivation?) Check out:
http://www.jhu.edu/rotc/Basic_Army_Knowledge/Military_Symbols.htm
for a military symbol for mortars.

Cheers,
Bill

Yeah, the Lieutenant sounds like Rambo on steroids. Actually, the sounds from the Team Leaders, Squad Leaders, Platoon Sergeant and Lieutenant represent the unit firing on a command. Of course, we might want to think about the addition of a class that would handle different commands. How would be go about that, and instead of a booming sound of all of the platoon’s weapons going off at once, we’d hear a command to that effect and all of the weapons would then sound off? Something like, “We’re being attacked by Sequential Programmers! Blast ‘em!” — then we’d hear a platoon firing sound.

Cheers,
Bill

Chandima and I are glad to hear it. We’re also looking for new ideas. Where do you think this application should go next?

Kindest regards,
Bill