Now to try something a little different. There are still things I would like to include everyday, like notions of what it means to be a Craftsman, but I think I am going to get into the habit of adding at least two design patterns to my repertoire each day. Right now, I would like to focus on my architectural skills, and then latter on I will focus more on languages.
Notions of What It means to be a Craftsman:
* Having the Test Right Feeling: Previously, when I was spiking and trying to figure out how the text box would work, I always felt like I was hacking together some albatross of a program, and just hoped things would work. It still felt great when I got to see things work they way I thought, but more often then not... I ended up having to make several attempts to get it right, and was never completely sure something would work.
I would describe the Test Right Feeling as a sense of satisfaction from knowing that almost everything you type out is going to work just how you want it to. Its a confidence in your coding solution, because you explicit wrote out the problem. Most of the time you don't even feel the need to click the test button since you are so certain it will work, but you do it anyway because green makes you happy.
A Craftsman should be at home with the Test Right Feeling. It should be ingrained into him, and terribly important to him. Although, he can of course leave his comfort zone if need be, he always knows he has his home if he needs it.
In a way its like the difference between a carefree and reckless swordsman, hacking away at his foes in the middle of the battle field vs. the well disciplined Roman warrior who stays in formation and guards his brothers in arms. The swordsman might run out and rapidly chop up the enemy, but he is more likely to die quickly and leave his brethren hanging. The disciplined Roman will fight side by side, guarding the man on either side; and though he may not kill as quickly, he will certainly grind his enemy into nothing, while still staying alive and protecting his allies.
The Roman has safety in his shield, formation, and brethren. These are his tests. They give him the confidence in every step forward he makes. If he has he shield up, and his feet in synch with the ranks, he knows he will end victorious. And though it can be fun to hack away at your foes, recklessly but quickly getting the job done, in the long run you wont be able to match the frag count of the man who carefully and guardedly gets the job done.
* Put your Tests to the Test: Getting back into the groove of testing today, I began rapidly coding away: test, red, green ... test, red, green... test, red, green. In the process, I was constantly refactoring and keeping my production code neat, extracting methods with meaningful names, and removing any duplication. All the while, I neglected my tests. I wrote them, then made them pass, and then moved on to a new test. I forgot that it is not only important to keep your production code clean, but equally important to keep your tests clean. Since your tests are a form of documentation to your code, they better be just as easy to read, if not easier.
Design Patterns:
Bridge Pattern: The Bridge pattern is useful when you have some object, say a Text Panel, and you want to have multiple implementations of this Text Panel. You want to have a TextBoxPanel and a TextAreaPanel. So first you try out making an abstract TextPanel, and then having two implementations of it. Then you realize that you want each TextPanel to have the option of either Plain Text or Rich Text. So you then try implement another TextPanel that you call the RichTextPanel, and you implement another version of the TextBoxPanel and TextAreaPanel for the RichTextPanel. Already you notice this getting rather nasty.
The Bridge Pattern is a way to separate the Abstraction (TextPanel) from the Implementation (TextModel (either Plain Text or Rich Text)) making them both easily extendable and independent.
To do this, you create two separate abstract classes, TextPanel and TextModel, where the Abstraction will interact with the client and the Implementation will manipulate and handle the data or implementation. Next, you add some concrete derivative to each of these abstract classes to fulfill your intentions. You create a dual hierarchy where each piece on one side of the hierarchy is compatible with those on the other side. Thus you could have a TextBoxPanel with a RichTextModel or PlainTextModel, and likewise with the TextAreaPanel.
The Bridge comes through the connection between the Abstraction and Implementation. Typically the derivatives of the Abstraction call a method of the Abstraction, which then transfers the method call to the Implementation, which hands it down to an Implementation derivative; however, the system can work in either direction.
I used it in just this way except I would have, for example, the PlainTextModel calls a markAsDirty() method on the TextModel, which hands this off to the TextPanel, and then to a TextBoxPanel to indicate that this particular TextBoxPanel needs to be repainted.
The value of this is of course that it allows for easy expansion, but also that it hides the details of the TextPanel, in the TextModel, from the client.
Flip-Flop Pattern: Not an official design pattern, but still a useful one according to Uncle Bob. This pattern can be used when ever you have two concrete, or heavy abstract, classes that are cyclically dependent. In order to obey the Dependancy Inversion Principle, you don't want either of these classes depending on the other, let alone both. In order to resolve this debacle, you can add an interface on top of each of the two classes, each of which holds a reference to the methods used by the other class. Then you just draw crisscrossing dependancies to the corresponding interfaces and voila. Naturally this is why its called a flip-flop... since you flip, and then flop the dependancies. Yes. Like pancakes.
Tidbits:
Using typed arraylists: ArrayList < &type > list = new ArrayList < &type > (size)
Interfaces can only have abstract methods, no fields or data
Classes implement, not extend interfaces
Also, keep in mind the Abstraction vs. Instability graph, and the Main Sequence. Plot how abstract a class is vs. how unstable (the more classes that depend on it, the more stable it is -> the fewer the more unstable). The Main Sequence is where classes should be and is drawn something like this:
A |.\
B |...\
S |......\
T |........\ Main Sequence
R |..........\
A |............\
C |...............\
T |___________\_
.......UNSTABLE
No comments:
Post a Comment