A Note Regarding Supplemental Files

Chapter 7. Architecture: Bringing Order to Chaos

You have to start somewhere, but you better pick the right somewhere! You know how to break your application up into lots of small problems, but all that means is that you have LOTS of small problems. In this chapter, we’re going to help you figure out where to start, and make sure that you don’t waste any time working on the wrong things. It’s time to take all those little pieces laying around your workspace, and figure out how to turn them into a well-ordered, well-designed application. Along the way, you’ll learn about the all-important 3 Qs of architecture, and how Risk is a lot more than just a cool war game from the ‘80s.

Feeling a little overwhelmed?

So you’ve got lots of small pieces of functionality that you know how to take care of... but you’ve also got use case diagrams, feature lists, and a whole lot of other things to think about.

Gary’s Game System Framework Feature List

The framework supports different types of terrain.
The framework supports different time periods, including fictional periods like sci-fi and fantasy.
The framework supports multiple types of troops or units that are game-specific.
The framework supports add-on modules for additional campaigns or battle scenarios.
The framework provides a board made up of square tiles, and each tile has a terrain type.
The framework keeps up with whose turn it is.
The framework coordinates basic movement.

We have feature lists...

...high-level views of what we need to build...

...the customer’s vision...

...and even some design patterns to apply.

Brain Power

Do you think it matters what you should try to do first? If you do, why? And what would you work on first?

We need an architecture

It’s really not enough to just figure out the individual pieces of a big problem. You also need to know a little bit about how those pieces fit together, and which ones might be more important than others; that way, you’ll know what you should work on first.

Architecture takes a big chaotic mess...

... and helps us turn it into a well-ordered application

You write great software the same way, whether you’re working on a small project, or a huge one. You can still apply the three steps we talked about way back in Chapter 1.

Let’s start with functionality

The first step is always to make sure an application does what it’s supposed to do. In small projects, we used a requirements list to write down functionality; in big projects, we’ve been using a feature list to figure those things out:

But which of these are the most important?

Even if we know to start by focusing on functionality, we still need to figure out which pieces are the most important. Those are the pieces we want to focus on first.

What do YOU think are the most important features?

Even though our feature list has only seven things on it, there’s a lot of work in those seven features. It’s your job to figure out which features you think are the most important, and then in what order you’d work on those things.

$image with no caption$

Note

Write down the 4 things you’d do first, in order, in these blanks.

_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

The things in your application that are really important are architecturally significant, and you should focus on them FIRST.

You gotta start somewhere!

It’s awfully hard to talk about the relationships between parts of a system if you don’t have any of the parts themselves. So say you wanted to talk about how the Board module interacted with the Units module:

To figure out how these modules interact, you’d need to have at least the basics of the two modules in place first.

So architecture isn’t just about the relationships between parts of your app; it’s also about figuring out which parts are the most important, so you can start building those parts first.

The three Qs of architecture

When you’re trying to figure out if something is architecturally significant, there are three questions you can ask:

1. Is it part of the essence of the system?

Is the feature really core to what a system actually is? Think about it this way: can you imagine the system without that feature? If not, then you’ve probably found a feature that is part of the essence of a system.

2. What the fuck does it mean?

Note

Note from marketing: suggest replacing profanity with “heck.”

If you’re not sure what the description of a particular feature really means, it’s probably pretty important that you pay attention to that feature. Anytime you’re unsure about what something is, it could take lots of time, or create problems with the rest of the system. Spend time on these features early, rather than late.

3. How the “heck” do I do it?

Another place to focus your attention early on is on features that seem really hard to implement, or are totally new programming tasks for you. If you have no idea how you’re going to tackle a particular problem, you better spend some time up front looking at that feature, so it doesn’t create lots of problems down the road.

To the right, you’ll find the feature list we figured out in the last chapter. Your job is to play like you’re the architect, and figure out what’s architecturally significant by using the three Qs of architecture we just talked about.

Gary’s Game System Framework Feature List

The framework supports different types of terrain.
The framework supports different time periods, including fictional periods like sci-fi and fantasy.
The framework supports multiple types of troops or units that are game-specific.
The framework supports add-on modules for additional campaigns or battle scenarios.
The framework provides a board made up of square tiles, and each tile has a terrain type.
The framework keeps up with whose turn it is.
The framework coordinates basic movement.

To the right, you’ll find the feature list we figured out in the last chapter. Below are the things we thought were architecturally significant, and which of the three Qs we used to make our decisions.

Gary’s Game System Framework Feature List

The framework supports different types of terrain.
The framework supports different time periods, including fictional periods like sci-fi and fantasy.
The framework supports multiple types of troops or units that are game-specific.
The framework supports add-on modules for additional campaigns or battle scenarios.
The framework provides a board made up of square tiles, and each tile has a terrain type.
The framework keeps up with whose turn it is.
The framework coordinates basic movement.

Q:
Q: I’m a little confused about what you mean by the “essence” of the system. Can you say more about that?
A:
A: The essence of a system is what it is at its most basic level. In other words, if you stripped away all the bells and whistles, all the “neat” things that marketing threw in, and all the cool ideas you had, what would the system really be about? That’s the essence of a system.
When you’re looking at a feature, ask yourself: “If this feature wasn’t implemented, would the system still really be what it’s supposed to be?” If the answer is no, you’ve found yourself an “essence feature.” In Gary’s system, we decided that the game wouldn’t really be a game without a board and some units, and there are some more examples in the Brain Power at the bottom of the page.
Q:
Q: If you don’t know what something means, isn’t that a sign that you’ve got bad requirements?
A:
A: No, but it is a sign that you might need to get some additional requirements, or at least some clarification. In the early stages, you can leave some details out to get a basic sense of a system. But at this stage, it’s time to fill in some of those details, and that’s what the second Q of architecture is all about.
Q:
Q: If I’m working on a new system, I probably won’t know how to do anything on my feature list. So won’t the 3rd Q of architecture about not knowing how to do something always apply?
A:
A: No, not at all. For instance, even if you’ve never written code to decide whether a player typed in the letter “q” or the letter “x,” you know how to write a basic if/else statement, and it’s easy to grab keyboard input from a player. So a feature like getting keyboard input isn’t something you don’t know how to do, even if you’ve never written code specifically for that task before. It’s just a few new details, really.
But if you had to write a multi-threaded chat server, and you’re new to threads and network programming, then that would be something that you don’t know how to do. Those are the things to look out for: particularly hard tasks that you’re unsure about how to handle.
Q:
Q: Doesn’t this all end up just being a judgment call, anyway?
A:
A: In a lot of cases, yes. But as long as you choose to start working on the things that seem the most important to the system, you’re going to get off to a good start.
What you don’t want to do is see some things that look familiar—perhaps you’ve solved the same problem in another project—and start there. Start with the core pieces of the system, and the things that look like they might be particularly hard, and you’ll be on the road to success.

The essence of a system is what that system is at its most basic level.

Brain Power

What do you think the essence of each of these systems is:

A weather-monitoring station?
A home automation remote control?
A beat-controlling, music-mixing DJ application?

We’ve got a lot less chaos now...

Using the three Qs of architecture, we’ve started to add some order to all that confusion we started out with:

... but there’s still plenty left to do

We’ve gotten Gary’s system down to three key features, but the big question remains: which one should you work on first?

Cubicle Argument Conversation

Jim: What in the world are you guys thinking? What good is it starting with anything that isn’t the essence of the system?

Joe: That’s ridiculous. Even if that’s the essence of the system, you’ve got to figure out what game-specific units are. That could take weeks to write if it’s harder than we think!

Frank: Maybe... but we know that coordinating movement will be tough, because we don’t have a clue how to do it! How can you possibly work on anything else when you know the movement deal is going to be difficult?

Joe: But the game-specific units might be difficult, too! We just don’t know, and that’s my point. We’ve got to figure out the parts of the system we don’t know anything about, or they could be real trouble!

Jim: You guys go on and write movement engines and deal with units. Me, I’m gonna write a board, because... well... something tells me Gary will want to see a board for his board game system. And I’m not about to leave the board for later... I’m taking it on first.

Frank: You’re both nuts. While you’re putting off the hard tasks, I’m gonna make sure the things that I don’t have any real idea about are taken care of, right away.

The reason that these features are architecturally significant is that they all introduce RISK to your project. It doesn’t matter which one you start with—as long as you are working towards reducing the RISKS in succeeding.

Take another look at our key features:

The point here is to REDUCE RISK, not to argue over which key feature you should start with first. You can start with ANY of these, as long as you’re focused on building what you’re supposed to be building.

Find the risk in your own project.

Think about the project you’re working on in your day job right now. Now write down the first thing you started working on when you started the project:

_____________________________________________________________________

Now think about the 3 Qs of architecture that we talked about back in The three Qs of architecture. If you applied those to your project, write down a few features that you think would be architecturally significant:

_____________________________________________________________________

If you look at those features closely, you’ll probably see that they all have a lot of RISK connected to them. They’re the things that could cause you lots of problems, or delay you getting your project done. In the blanks below, write down which of those features you think you should have worked on first, and why. What risks did it create? What risks could you have reduced by working on it first?

_____________________________________________________________________

For Gary’s game system, let’s start out by working on the board module. Your job is to write a Board interface that game designers can then use and extend to build their own games.

The problem:

You need a Board base type that game designers can use to create new games. The board’s height and width are supplied by the game designers for their games. Additionally, the board can return the tile at a given position, add units to a tile, and return all the units at a given X-Y position.

Note

Here are some detailed requirements that we got from Gary and his design team.

Your task:

Create a new class called Board.java.
Add a constructor to Board that takes in a width and height, and creates a new board with that height and width. The constructor also needs to fill the board with square tiles, one at each X-Y position.
Write a method that will return the tile at a given position, given that tile’s X- and Y-position.
Write methods to add units to a tile based on that tile’s X- and Y-position.
Write a method to return all the units on a tile, given the X- and Y-position of the tile.

Answers in Architecture Puzzle Solution

This week’s interview: Scenarios help reduce risk

HeadFirst: Hi there, Scenario, we appreciate you taking the time to talk with us today.

Scenario: I’m really happy to be here, especially in a chapter that isn’t just about use cases.

HeadFirst: Well, yes, to tell the truth, I was rather surprised when I was told we’d be interviewing you. We’re really focusing on architecture here, and working on features that would reduce risk.

Scenario: Absolutely! Well, that sounds like a very good way to approach big problems.

HeadFirst: Yes, well... ahem... then why are you here?

Scenario: Oh! I’m sorry, I just assumed you knew. I’m here to help reduce risk, also.

HeadFirst: But I thought you were just a particular path through a use case. We haven’t even written any use cases yet!

Scenario: That’s no problem, I can still be a real help. I mean, look, let’s be honest, lots of developers just don’t ever really take the time to sit down and write out use cases. Good grief, it took you something like four pages in Chapter 6 to convince people to even use a use case diagram, and that’s much easier to draw than it is to write a use case!

HeadFirst: Well, that’s true... there is a lot of resistance to writing out use cases. But they’re really helpful, I thought they saved the day with Todd and Gina’s dog door.

Scenario: Oh, I agree! But in cases where developers just don’t have the time, or a use case is too formal for what’s needed, I can really give you a lot of the advantages of a use case, without all the paperwork.

HeadFirst: Hmmm, that is appealing. So tell me how that works.

Scenario: Well, take that board you’ve been writing. Suppose you wanted to reduce the risks of Gary seeing it, and thinking of something important you forgot to add to it...

HeadFirst: Ahh, yes, forgetting an important requirement is always a risk!

Scenario: Well, you could come up with a simple scenario for how the board would be used—that’s where I come in—and then make sure the board works with everything in your scenario.

HeadFirst: But there’s no use case... what steps do we pick in the scenario we make up?

Scenario: It doesn’t have to be that formal. You might say, “The game designer creates a new board 8 squares wide by 10 squares high,” and “Player 1 kills Player 2’s troops at (4, 5) so the board removes Player 2’s troops from that tile.”

HeadFirst: Oh, so just little descriptions of how the board is used?

Scenario: You’ve got it! Then you run through each description, and make sure your board handles those cases. It’s not quite as thorough as a use case, but I really can help you make sure you don’t forget any big requirements.

HeadFirst: This is fantastic! We’ll be right back with more from Scenario.

Write a scenario for the Board interface you just coded.

Reducing risk is the name of the game in this chapter. You’ve coded a Board interface based on a few requirements we gave you, but it’s your job to figure out if we forgot anything—before Gary sees your work and finds a mistake.

Note

This is the risk we’re trying to reduce or eliminate using a scenario.

Your job is to take the fragments of a scenario from the bottom of this page, and put them into an order that makes sense on the bulletin board. The scenario should run through a realistic portion of a game. When you’re done, see if you left out anything on the Board interface, and if you did, add the missing functionality into your code. You may not need all the scenario fragments; good luck!

This week’s interview: Scenarios help reduce risk (cont.)

HeadFirst: We’re back with Scenario, again. Scenario, we’re getting quite a few calls. Would you mind taking some of our listener’s questions?

Scenario: Sure, I’d be happy to.

HeadFirst: Great. First, here’s one we’re getting a lot. This is from Impatient in Idaho: “So you’re saying I don’t need to write use cases, anymore, right? I can just use scenarios?”

Scenario: Oh, thanks, Impatient, I actually get that question often. I firmly believe you should still write use cases whenever possible. I’m helpful for quick problems, and to find the most common requirements, but remember, I’m only one path through a use case. If there are lots of alternate paths, you might miss some important requirements if you used just a scenario for your requirements.

HeadFirst: That’s right, we’ve actually had Happy Path and Alternate Path on our show before.

Scenario: Well, they’re really just specialized versions of me, if you want the truth. We try not to talk much about our family relationships, we all wanted to make it in this world on our own. But we’re really all part of the Scenario family. And you really need all of us to be sure you’ve got a system completely right. But if you’re just getting started, and a use case seems like it might be premature, just using me is a good way to get started.

HeadFirst: OK, here’s another question, from Nervous in Nebraska: “You said you would help me reduce risk, and I hate risk. Could you tell me exactly how you can help me avoid risk?”

Scenario: Another good question. Remember, when you’re figuring out requirements, whether you’re using a use case, a use case diagram, or a scenario, you’re trying to make sure you are building just what the customer wants. Without good requirements, the risk is letting down or upsetting the customer by building the wrong thing.

HeadFirst: So you’re reducing risk in the requirements phase?

Scenario: A lot of the time, yes. That’s when you’re writing use cases, putting together a requirements list, and using lots of scenarios to chart out all the paths through a use case.

HeadFirst: But you also help out in big project architecture, right? That’s why we’re interviewing you now?

Scenario: Exactly. Sometimes, you don’t have a complete requirements list and a bunch of use cases, but you still need to get some basic work done to see how a system is going to work. That’s what we’ve been doing here: using a scenario to get the basics of a module or piece of code down, so you can get the basic building blocks of your application in place.

HeadFirst: So you’re really a handy guy, aren’t you?

Scenario: I’d like to think so. I help in gathering requirements, in being sure your use cases are complete, but also in architecture, helping you reduce risk and reduce the chaos and confusion around what a particular module or piece of code does.

Q:
Q: Where did those requirements for the Architecture Puzzle in Architecture Puzzle come from?
A:
A: From Gary, with some common sense added in. If you think about what Gary’s asked for, a game system framework, and then read back over the customer conversation in Chapter 6, you could probably come up with these requirements on your own. We did add a few specifics, like being able to add a unit to a specific tile, but that’s really just thinking through the problem.
Q:
Q: But why didn’t we write a use case to figure out the requirements?
A:
A: We could have. But remember, we’re not trying to complete the Board module, as much as get the basic pieces in place. That’s all we need to reduce the risk of completing this piece of Gary’s system. In fact, if we got into too much detail, we might actually add risk to the project, by working on details that really aren’t important at this stage of things.
Q:
Q: Now you’re telling me that use cases add risk? That can’t be right!
A:
A: No, use cases don’t add risk when used at the right time. Right now, we’ve come up with some key features that could cause us headaches if we don’t figure them out. But that doesn’t mean we need to perfect the Board interface; we just need to get an understanding of how it works, so if there are any potential problem spots, we can catch them and avoid problems down the line. So at this point, the details you’d need to write a good use case are a bit of overkill.
But once we’ve got the key features sketched out, and handled the major risks, we’ll go back to each module and really start to add detail in. At that point, a use case is very helpful.
Q:
Q: So that’s why we used a scenario, right? To avoid getting into lots of unnecessary detail?
A:
A: Exactly. A scenario gives us lots of the advantages of a use case, without forcing us to get into lots of detail that we don’t need to worry about right now.

Q:
Q: Doesn’t using an array of arrays limit you to a square board?
A:
A: No, although it does limit you to a board that uses (x, y) coordinates. For example, you can use (x, y) coordinates in a board made up of hexagon-shaped tiles, if you structure the hexagon tiles correctly. But for the most part, an array of arrays is more ideally suited to a square-tiled, rectangular board.
Q:
Q: So isn’t that limiting? Why not use a graph, or even a Coordinate class, so you’re not tied to (x, y) coordinates and a rectangular board?
A:
A: If you wanted maximum flexibility, that might be a good idea. For this situation, though, our requirements (back in Architecture Puzzle) actually specified (x, y) coordinates. So we chose a solution that wasn’t quite as flexible, but certainly was simpler. Remember, at this stage, we’re trying to reduce risk, not increase it by going with a solution that is a lot more complex than we really need.

The Tile and Unit classes

To actually make Board compile and work, we need to create a Tile and Unit class. Here’s how we wrote those classes:

Keep the right focus

You don’t need to worry about everything that Tile and Unit will eventually need to do. Your focus is on making Board and its key features work, not on completing Tile or Unit. That’s why we left Unit so bare, and added only a few methods to Tile.

Focus on one feature at a time to reduce risk in your project.
Don’t get distracted with features that won’t help reduce risk.

Q:
Q: If the Tile class handles adding and removing units, and you can get the tile at a coordinate from the Board using getTile(), why add those addUnit() and removeUnit() methods to Board. Couldn’t you just call getTile(), and then use the Tile to do those things?
A:
A: You could take that approach, and let all the Unit-related operations be handled directly through the Tile object returned from getTile(). We decided to add the Unit-related methods to Board, and have Board be the entry point for game designers. In fact, you’ll see on the next page that we made Tile’s methods protected, so that only classes in the same package as Tile—like Board—could call addUnit() and removeUnit() directly. So we’ve really ensured that Board is the object used to work with tiles, units, and eventually terrain.
Q:
Q: I still think it would be easy to go ahead and add some more of the methods we know we’ll need to Unit and Tile. Why not spend a little time on those classes now?
A:
A: You’re not trying to code the entire game system framework at this point; you’re just trying to tackle a few key features, and reduce the major risks to your project. Spending time writing the Unit class, or fleshing out the Tile class, really isn’t going to help you reduce risk. Instead, do just enough to get the Board class working, because it’s the Board class that we decided was part of the essence of the system, and where we had a risk of failing if we didn’t get that piece in place.
Once you’ve handled your key features, and reduced or eliminated the big risks to your project, then you’ll have plenty of time to work on other features, like the Unit class. At this stage, though, you’re trying to avoid spending time on anything that doesn’t help you reduce the risks to your project succeeding.

Get online

You can download these Board-related classes for Gary’s framework at http://www.headfirstlabs.com. Just look for Head First OOA&D, and find “Gary’s Game System - Board classes.”

More order, less chaos

Our architecture and key feature list has helped us get the basic Board in place, and make sure we’re capturing the essence of the system for the customer. Let’s look back at our key feature list:

We’ve got structure now, too...

Even better, we’ve got some basic classes in place, and we can start to think about our next key feature, and how it fits into this structure.

Which feature should we work on next?

Build on what you’ve already got done whenever possible.

When you’ve got nothing but requirements and diagrams, you’ve just got to pick a place to start. But now that we do have some code and classes, it’s easiest to pick another key feature that relates to what we’ve already built. And remember our definition for architecture?

You really can’t talk about the relationships between parts if you don’t have two parts that have a relationship. We know Board and Unit are related, and that “game-specific units” are a key feature, so that’s the obvious thing to work on next.

Game-specific units... what does that mean?

The simplest way to understand a bit more about what “game-specific units” means is to talk to some of Gary’s customers, the game designers who will be using his framework. Let’s listen in on what they have to say:

What does “game-specific units” mean?

Now that you’ve heard from several of the game designers who want to use Gary’s game system framework, you should have a good idea of what our second key feature is all about. Write down in the blanks below your idea of what you need to do to support “game-specific units.”

_____________________________________________________________________

When you’re done, compare your answers with ours on the next page.

Exercise Solutions

What does “game-specific units” mean?

Each game based on the framework has different types of units, with different attributes and capabilities. So we need to be able to have properties for a unit that are different for each game, and support multiple data types for those properties.___________

Commonality revisited

We’re starting to learn more about what “game-specific units” means, but we still need to figure out how to actually add support for this feature to our game system framework. Let’s start by taking a look at the different types of units the customers mentioned, and figure out what’s common between them.

Solution #1: It’s all different!

At first glance, you might have come up with a solution that looks something like this:

Commonality is about more than just the names of properties... you need to look a little bit deeper.

It might seem like there’s not anything common across all the units used in different games, but let’s take a step back from focusing on the actual names of the properties for each unit. What’s really the same for each unit?

Solution #2: It’s all the same!

At first glance, you might have come up with a solution that looks something like this:

Commonality analysis: the path to flexible software

Wondering why we spent all that time on commonality analysis? Look back at the first solution in Which feature should we work on next?, and then again at the second solution, on the left, and then fill out the table below to see what commonality has really bought us in terms of our design:

Note

This first row is what we’ve looked at so far: 3 different unit types.

Number of unit types	Number of unit classes - Solution #1	Number of unit classes - Solution #2
3
5
10
25
50
100

Note

100 may seem like a lot, but in massive war games, it’s not so far-fetched.

Which solution do you think is better? _______________________________________

Why? _______________________________________________________________

_____________________________________________________________________

We identified what was common, and put it in the Unit base class. The result was that game designers now only have to keep up with ONE unit class, instead of 25, 50, or 100!

Q:
Q: I can see how this would help me with my design, but what does any of this have to do with reducing risk?
A:
A: Good design always reduces risk. By figuring out how best to design the Unit class, we can get it right the first time... before we’re deep into working on the entire game system framework, and might have to make drastic changes to Unit that affect lots of other code.
Not only have we figured out what “game-specific units” means, but we’ve defined the basic Unit class, and now other classes like Board can relate to it without worrying about its design drastically changing in the middle or near the end of the project’s development cycle.

Good design will always reduce risk.

And still more order...

We’ve figured out another key feature, reduced risk to our project even further, and only have one feature left to worry about.

We’re focusing on doing just the things that reduce risk.

Remember, the point of architecture is to reduce risk, and to create order. There are plenty of other things to work on in your application, but those are for after you’ve got a handle on how your application will be structured, and have the major risks reduced to the point where they are manageable.

We were trying to get a handle on the Unit class, and what “game-specific units” meant; at this point, we’ve done that:

Q:
Q: When we worked on the Board, we did code the Board class, but now you say we shouldn’t code the Unit class. What gives?
A:
A: The question you need to be always asking at this stage of a project is, “Will this reduce the risk to my project succeeding?” If the answer is yes, you should go ahead; if it’s no, you probably can leave the task for a later stage of the project.
In the case of the Board, we needed to have a basic understanding of what the game board does, so we went ahead and coded a basic implementation. But for Unit, a class diagram and understanding its basic functionality was all we really needed to do. In both cases, we were reducing risk to our project, rather than focusing on coding or not coding a certain class or package.
Q:
Q: But couldn’t we have just done a class diagram for Board, like we did for Unit, and stopped there?
A:
A: You probably could have just done a class diagram. It’s really a judgment call, and as long as you feel you’re focusing on reducing the risk in your project, it’s OK to stop with a class diagram, or take things a level or two deeper.
Q:
Q: Is it really good to ask the customer and users of a system about what it should do? Couldn’t they lead us astray, or distract us?
A:
A: It’s usually a good idea to ask the customer, because it is their system that you’re building. And really, the customer is only going to confuse you, or get you working on the wrong thing, if you’re unsure of what you’re supposed to be working on. As long as you go into a conversation clear on what your goals are, and you’re listening for something specific, you should be able to filter out anything that might confuse or distract you.
Q:
Q: I’m still not sure I would have ever come up with using a Map for storing properties in the Unit class on my own.
A:
A: That’s OK; that’s what tools like commonality and the three Qs of architecture are for. They help you get to solutions that you might not think of on your own, in a way that works on any type of project.
In the case of the Unit class, the point isn’t that we used a Map to store properties. It’s that we figured out that all units are basically just a unit type and a set of name/value pairs. Once we figured that out, the details about how we stored those name/value pairs were a piece of cake.
Q:
Q: So there’s really not a lot of code involved in OOA&D, is there?
A:
A: OOA&D is all about code—it’s about writing great software, every time. But the way you get to good code isn’t always by sitting down and writing it right away. Sometimes the best way to write great code is to hold off on writing code as long as you can. Plan, organize, architect, understand requirements, reduce risks... all these make the job of actually writing your code very simple.

Sometimes the best way to write great code is to hold off on writing code as long as you can.

What does it mean? Ask the customer

Note

Want to see the answers to the BE the Author exercise? Read the next four pages and see how close your pages are to what we did.

When you’re not sure what a feature really means, one of the best things you can do is ask the customer. We did this with the game-specific units, so let’s try the same thing for figuring out what coordinating movement means.

Do you know what “coordinating movement” means?

Listening to the customers should have given you a pretty good idea of what the third key feature of Gary’s game system framework is all about. Write what you think that feature really means in the blanks below:

_____________________________________________________________________

Now do some commonality analysis

Next you need to try and figure out what’s common about the different movement scenarios that the customers in Solution #2: It’s all the same! have been talking about. Are there some basic things that apply to all the different types of movement? If you think that there are, write those common things in the blanks below:

_____________________________________________________________________

So now what would you do?

If you have an understanding of what “coordinating movement” means, and you know what things are common across all games, you should have an idea about what you need to do to the game framework to make this feature work. Write your ideas down in this final set of blanks:

_____________________________________________________________________

Is there anything common here?

Here’s what we thought we needed to do based on what Gary’s customers were saying about movement:

Units should be able to move from one tile on the board to another. Movement is based on a calculation or algorithm specific to each game, and sometimes involves the game-specific properties of a unit.

So what exactly is common among all the different possible movement scenarios? Remember what the customers said?

It’s “different for every game”

Did you see what kept showing up in our chart? Every time we found some commonality, the variability column had the same words: “different for every game.”

When you find more things that are different about a feature than things that are the same, there may not be a good, generic solution.

Q:
Q: How is this really that different from game-specific units?
A:
A: With units, we did find some commonality: every unit had a type, and then name/value properties. With movement, every single game looked like it would handle things differently. So it made sense to leave movement to the game designers, rather than come up with a solution that was so generic that it was essentially useless.
Q:
Q: But there is some commonality, isn’t there? A movement algorithm, and a check to see if a move is legal, right?
A:
A: You’re right. So, in theory, you could write a Movement interface, with a method like move() that took in a MovementAlgorithm and a LegalMoveCheck, or something similar. And then each game designer could extend MovementAlgorithm and LegalMoveCheck. If you thought of something like this, nice work! You’re really ahead of the game.
But then ask yourself: what does this really gain? Game designers are going to have to learn your interfaces, and if they don’t have a legality check, they might pass in null for the LegalMoveCheck parameter, and what would the interface for MovementAlgorithm look like, and... well, you’re probably adding complexity, rather than really removing it.
Your job is to reduce risk and complexity, not increase it. We decided that it would be simpler to let game designers handle movement, and just change the position of units on the board (using methods on Board, which we did take care of for them).

Customers don’t pay you for great code, they pay you for great software.

Absolutely! Remember, great software is more than just great code.

Great code is well-designed, and generally functions like it’s supposed to. But great software not only is well-designed, it comes in on time and does what the customer really wants it to do.

That’s what architecture is about: reducing the risks of you delivering your software late, or having it not work like the customer wants it to. Our key feature list, class diagrams, and those partially done classes all help make sure we’re not just developing great code, but that we’re developing great software.

Reducing risk helps you write great software

With all three key features figured out, we’ve got a handle on the major risks to our project succeeding. Look at how each step we’ve taken in this chapter has reduced the risks to our project:

Architecture helps you turn all your diagrams, plans, and feature lists into a well-ordered application.
The features in your system that are most important to the project are architecturally significant.
Focus on features that are the essence of your system, that you’re unsure about the meaning of, or unclear about how to implement first.
Everything you do in the architectural stages of a project should reduce the risks of your project failing.
If you don’t need all the detail of a use case, writing a scenario detailing how your software could be used can help you gather requirements quickly.
When you’re not sure what a feature is, you should ask the customer, and then try and generalize the answers you get into a good understanding of the feature.
Use commonality analysis to build software solutions that are flexible.
Customers are a lot more interested in software that does what they want, and comes in on time, than they are in code that you think is really cool.

The march of the crossword continues. Have you gotten every answer so far? Here’s another set of clues to help you store all this architectural info in your brain for good.

Across	Down
6. Focus on the things in your system that are architecturally ___________ first. 9. These are the features that you should focus on first. 11. Use cases add risk when used at this time. 12. The essence of a system is what the system is at its most ________. 13. Focusing on more than one feature at a time does this to the risk in your project. 15. Use this type of analysis when you’re not sure how to implement a confusing set of features. 16. Architecture highlights these parts of your application. (2 words) 17. Commonality analysis is one path to this type of software.	1. Always start a project by focusing on this. 2. The second Q of architecture is about the ___________ of a feature. 3. The first Q of architecture is about this. 4. You focus on key features to reduce this in your project. 5. These are a way to get basic requirements without the detail of a use case. 7. This is not the same as great code. 8. You usually trade off flexibility for this in your project’s design. 10. You use architecture to turn a mess into this kind of application. 14. You write this type of software the same way, whether it’s a big system or a small one.

Across

Down

6. Focus on the things in your system that are architecturally ___________ first.

9. These are the features that you should focus on first.

11. Use cases add risk when used at this time.

12. The essence of a system is what the system is at its most ________.

13. Focusing on more than one feature at a time does this to the risk in your project.

15. Use this type of analysis when you’re not sure how to implement a confusing set of features.

16. Architecture highlights these parts of your application. (2 words)

17. Commonality analysis is one path to this type of software.

1. Always start a project by focusing on this.

2. The second Q of architecture is about the ___________ of a feature.

3. The first Q of architecture is about this.

4. You focus on key features to reduce this in your project.

5. These are a way to get basic requirements without the detail of a use case.

7. This is not the same as great code.

8. You usually trade off flexibility for this in your project’s design.

10. You use architecture to turn a mess into this kind of application.

14. You write this type of software the same way, whether it’s a big system or a small one.

What’s missing in Board.java?

Look closely at the scenario on the last page. Did the requirements we used in Architecture Puzzle cover everything in the completed scenario? If you think something is missing, write it in the blank below, and then add code to Board.java to handle the missing functionality.

Note

We added a removeUnit() and removeUnits() method to Board.java to handle this requirement.

The scenario talks about removing units, but there is no requirement to remove units in Architecture Puzzle.

Previous Chapter

6. Solving Really Big Problems: “My Name is Art Vandelay... I am an Architect”

Next Chapter

8. Design Principles: Originality is Overrated

Table of Contents for Head First Object-Oriented Analysis and Design

Chapter 7. Architecture: Bringing Order to Chaos

Feeling a little overwhelmed?

Gary’s Game System Framework Feature List

Brain Power

We need an architecture

Architecture takes a big chaotic mess...

... and helps us turn it into a well-ordered application

Let’s start with functionality

But which of these are the most important?

Note

The three Qs of architecture

1. Is it part of the essence of the system?

2. What the fuck does it mean?

Note

3. How the “heck” do I do it?

Gary’s Game System Framework Feature List

Gary’s Game System Framework Feature List

Brain Power

We’ve got a lot less chaos now...

... but there’s still plenty left to do

Cubicle Argument Conversation

Note

Note

The Tile and Unit classes

Keep the right focus

Get online

More order, less chaos

We’ve got structure now, too...

Which feature should we work on next?

Game-specific units... what does that mean?

Commonality revisited

Solution #1: It’s all different!

Solution #2: It’s all the same!

Commonality analysis: the path to flexible software

Note

Note

And still more order...

What does it mean? Ask the customer

Note

Do you know what “coordinating movement” means?

Now do some commonality analysis

So now what would you do?

Is there anything common here?

It’s “different for every game”

Reducing risk helps you write great software

Note

Highlight

Highlight

Table of Contents for
Head First Object-Oriented Analysis and Design