Parts 5 and 6 of the 4-part series 50
The title says it all. I was bothered by a few things in the Shunting Yard Algorithm (actually many more things), but I felt compelled to fix two of those things.
So if you have a look at the album, you’ll notice 2 more videos:- Video 5 of 4: Remove the need for spaces between tokens.
- Video 6 of 4: Remove duplication of operators in algorithm and tokenizer.
Hope these are interesting or at least entertaining.
Some Rough Draft TDD Demonstration Videos 203
I’m doing a series of videos on TDD. The ultimate result will be a much more polished version with embedded slides, and such. But as a part of the development process, I’m creating scratch videos.
Much of what you see in these videos will be in the final versions, but those are far in the future relative to this work.
Hope you find them interesting.
Comments welcome.
Here is what is already available:- Getting started
- Adding Operators
- Removing violation of Open/Closed principle
- Removing duplication in operations with a combination of the Strategy pattern and the Template Method pattern
- Adding new operators after the removal of duplication.
- Reducing coupling by using the Abstract Factory pattern, Dependency Inversion and Dependency Injection
- Adding a few more operations
- Allowing the creation of complex “programs” or “macros” by using the Composite pattern – and avoiding Liskov Substitution Principle inherent in the GoF version of the pattern
- Driving the calculator via FitNesse + Slim
Anyway, that’s the plan. I’ll try to add each of these videos over the next few weeks.
Improving Testability of GUI Code, an Eample 82
Just finished first draft. More to come, questions/comments appreciated.
http://schuchert.wikispaces.com/tdd.Refactoring.UiExample
Are "else" blocks the root of all evil? 79
So, I’m pair programming C++ code with a client today and he makes an observation that makes me pause.
The well-structured, open-source code I’ve looked at typically has very few else blocks. You might see a conditional test with a return statement if the conditional evaluates to true, but not many if/else blocks.
(I’m quoting from memory…) Now, this may seem crazy at first, but one of the principles we teach at Object Mentor is the Single Responsibility Principle, which states that a class should have only one reason to change. This principle also applies to methods. More loosely defined, a class or method should do only one thing.
So, if a method has an if/else block, is it doing two (or more) things and therefore violating the SRP?
Okay, so this is a bit too restrictive (and the title was a bit of an attention grabber… ;). We’re not talking about something really evil, like premature optimization, after all!
However, look at your own if/else blocks and ask yourself if maybe your code would express its intent better if you refactored it to eliminate some of those else blocks.
So, is there something to this idea?