McLaughlin, Brett D., Pollice, Gary, & West, David (2007).
Chapter 6 of Head First Object-Oriented
Analysis & Design. Sebastapol, CA: O'Reilly.
McLaughlin, Brett D., Pollice, Gary, & West, David (2007).
Chapter 7 of Head First Object-Oriented
Analysis & Design. Sebastapol, CA: O'Reilly.
What are some examples of other design patterns? The only one I have heard of is MVC.
Factory, Singleton, .... If there's time, I'll try to do a few lectures on design patterns.
HFOOAD 6: The book suggests breaking large problems down into smaller problems, which certainly makes sense. However, I found that occasionally when I tried to conceptualize flexible designs (creatures in our project, tiles in the book's project), occasionally I'd be so focused on making the design flexible that it was difficult to actually write a design - i.e. "let's think of all the possible ways someone could change this before writing down any version of it". In general, can we write a basic version of something first and then expand it to be flexible, or does that lead to moments when you may not be achieving goals the best way because you've already locked yourself into an implementation?
You've found part of the rationale for the XP practice of solve the problem at hand now, refactor later
.
HFOOAD 7: One thing the book didn't cover was our group situation, in which you have multiple groups working on the same task and occasionally sharing information. In a real-world setting, if this were the case, would strict adherence to the UML diagram guarantee that our code worked together? Do companies often have multiple groups assigned to the same task, or would they usually assign different pieces of it to different groups?
Companies rarely assign multiple teams to the same project. However,
it is often the case that UML diagrams (or other similar technologies) are
used to represent the agreed upon relationships between the parts. If
you don't meet the interface for your part, the other team can't connect.
I'm honestly confused about the lack of commonality in the coordinating movement example. It seems that in the example, if you use terrain as a modifier to movement (infinity if they cannot bypass), a couple of groups of movement (air, land, water), and a field modifier on groups that might be affected (air by wind speeds). This will allow for a very common solution that solves all of the problems. It seems to me that no commonality thought is nonsense.
Perhaps they have a lack of vision. Perhaps they think that once you add in other domains (e.g., space) your solution won't work.
Do programmers in the real world actually hand their (non-programmer) customers things like UML diagrams? The book says that it's what most people give the customer, but it seems like common sense not to do that. Do programmers fail at common sense, or is this book displaying a problem that doesn't really exist?
Programmers in the real world give their customers lots of things we might not expect. Translating between English and code (or vice versa) is hard for a lot of people.
Wouldn't the actors diagramed on 302 and 303 be better described as a game designer or player, and not as the designer and the game itself acting on the code?
Well, the gamer interacts with the game, so it's probably worth dividing things more this way. But it's a matter of there's no right answer
.
In the example Board class on pages 346-7, the 2D array of tiles is
stored as a nested ArrayList of ArrayLists of Tiles. What makes this
implementation superior to a 2D array? Java supports arrays of
arbitrary type, and (I think) using an array would be more memory-
efficient.
The authors could be envisioning a system in which it's possible to
grow the board. The 2D array would be slightly more memory efficient.
More importantly, it should be faster, particularly if we're iterating
the board.
After telling us to work with interfaces, the authors seem to have
coded everyting as a class (or, perhaps, an abstract class). Why?
I have no idea.
I tried to think of our project as I read through the chapters. So I'm wondering what parts of our project do you think have the highest risk?
The network portion is clearly high risk. The GUI is high risk.
On a semi-related note, I think doing a quick scenario over our project as a group could help to solve some confusion (maybe?).
Yes. It's in the plans.
Chapter 6 highlights the importance of identifying actors to creating use case diagrams and designing the system. Are there any cases in software development where you won't know (all of) the actors before you begin designing?
You might not envision all of the actors. You might end up extending the system later.
Should a use case diagram/blueprint contain all features of the system? Is it beneficial, once breaking up the project into small problems, to create individual use cases and requirements for each problem? The authors mention it is hard to envision relationships between components before coding. At what point do you start designing classes and coding instead of planning?
Yeah, the questions for which there are no fixed answers. It depends on your development methodology and your local culture.
At the end of chapter seven, the authors conclude that movement is different for every game so there is no generic solution. Why couldn't one add a "Movement Properties" map to the unit class? This would at least give the future game programs a place to put these properties and would encourage a more generic solution to the problem.
I would also make different design decisions.
On page 364 the authors make the claim that "Sometimes the best way to write great code is to hold off on writing code as long as you can", this is at odds with the Extreme Programming philosophy of "program a lot to see what works best". Are these two approaches reconcilable?
Probably not. You'll need to decide which is best for you (which depends, in part, on the local culture).
What exactly is the domain of a project? I understand the domain in terms of the war-based textual interface idea, but in terms of other projects, I'm not sure how I would determine the domain.
Maybe we'll try some practice.
What exactly is the essence of a system, is the term actually used? This chapter uses a few different terms such as architecture and and the aforementioned essence. Are these terms that we might encounter in industry, or are they simply terms for relating ideas about the readings?
You will definitely see the term architecture
. I'm not so sure about essence
.
All three "Q's of architecture" on page 332 do seem equally significant, especially when paraphrased as meaning, essence, and manner of implementation. However, the importance of "meaning" is later used to justify making the starting point of a large project whatever seems most complicated. This makes the least amount of sense to me given the other options (page 338), as well as from my own experience in this class. Is this a reasonable way to approach a large project?
HFOOAD 7: We seem to have done what this book advises against, and worked on the "easy" things (things we understand) first. I understand that we shouldn't leave giant difficult tasks until the end, when they can cause a major problem, but at the same time, if you're really stuck on something, it seems to make better psychological sense to accomplish something - anything - before spending hours trying to understand something complex. So, which is better?
Chapter 7 says we should focus on difficult tasks first on page 332. Isn't this a good way to stuck and frustrated? Wouldn't it be better to get some features implemented while letting the thoughts percolate about the more difficult features?
In The Three Qs of Architecture on page 332, the authors suggest focusing on features that seem really hard, are totally new, or things you don't understand first and building those parts of the system first. How does this relate to their other strategy, begin by building things that reduce risk? Is it better to judge risk by what system components are most essential or by components you don't know how to build?
It depends a bit on your psychological outlook and about the project scope. In the end, we don't have to implement everything in the project, so we start with the things we know we need and that we can work on. The danger of this is that we'll need to change things significantly if we've failed to take into account some aspect of the unknown parts.
;
