Through Christopher Steen I found Ohad's link to 8 free e-books on the APress site.
The one that I downloaded was Dissecting a C# Application: Inside SharpDevelop. It goes into the pieces of the app and discusses how things work and what issues they ran into. Its one of those project that started out as a one man show but then grew into what it is today. One chapter I really liked (and paid most attention to) was the second chapter: Designing the Architecture. This is some good stuff for guys like me who like to know the thought processes that go into building an application. The piece of chapter two on design patterns was of special interest to me as I'm still getting my chops around design patterns. I know what they are and I'm realizing I unknowingly use them a lot; I just don't know their names or the book definition very well. Though the reviews on amazon aren't that great I wasn't looking for to much from it. So what I did get was good.
Chapert Two:
In this chapter, we will be looking at the history of SharpDevelop and its basic design concepts. Also, we
will be discussing the practices used in the SharpDevelop development process. Some of our practices and
methods might seem unusual, but we want to tell the truth about our development process; ...This chapter lays
the foundation for understanding the succeeding chapters and, in any case, it's good to know how a technology was developed.
Correcting Bad Design Decisions
In this section they discuss some of the history of the project and some decisions that were made early on that reared its ugly head as issues later on. I know this happens to all of us but its comforting to hear it too. One example they discuss is originally using an ArrayList for the editor's data structure. They then realized the editor itself had become a beast and basically rebuilt it from scratch and in doing so change the editor's data structure to a linear model. They go into the reasons behind the decision (like reviewing literature on other editors) and the advantages of the decision (like increase performance).
The Design Decisions
This section discusses their outline that defined their design. For example - ease of deployment and having few dependencies on a user's machine and using the Model View Controller (MVC) model.
As we can see from the diagram, the controller is between the view and the model and it communicates
with both of them. The view needs to display the data. Therefore, it needs to read the model. It does not
need to make changes to the model so this communication is one-way.
For example, the text editor (in this chapter we won't go into implementation details, but this is a good
example) has a data model called the 'document'. In this model, text is stored, which is broken up into
lines. We use edit actions to change this text and a Control (in Windows Forms terms) to display our text.
The Control that displays the text represents the view in our MVC model. The edit actions correspond
to the controller (even if they are implemented using more than one class) and the model is
implemented by the document layer. The edit actions see to it that the view is updated and even call for
redisplay for some actions. The document layer, however, doesn't know anything about the view. All
these parts are independent of each other. We have tried to apply this model to the whole project.
Design Patterns
The SharpDevelop team decided that the pattern oriented approch in their design. They also go through the primary design patterns they used as well as go into each with examples and describe the way they were used in SharpDevelop.
Apart from the better structure and enhanced flexibility that the pattern-oriented approach provides to
SharpDevelop, we found design patterns useful for better understanding of the structure, without having
to use UML. However, note that design patterns do not replace UML. In fact, they complement each
other well. UML is important for understanding complex systems but in case the UML diagrams are
missing, patterns make life a bit easier.
Design and Refactoring
Oh how I love refactoring. Yes, I'm serious I truly enjoy this piece of the development process. Refactoring is not new but here they discuss what trials they faced and what guidelines they used when it came to refactoring. This is a good section and I've learned a lot from it.
- If you don't understand a method, break it down into smaller ones relevant names.
- Favor readable/understandable code over code with more performance.
- Don't design too much today; tomorrow it will be so much easier.
- No amount of refactoring is too much.
- Use Assertions wherever possible.
- Solve each problem at its root.
- Last but not least an important rule: Eat your own dog food.
The point is that, whenever we felt that we had taken the wrong approach we simply restructured our design, even if it meant we had to restructure a large part project. It is not as much work as it first seems to be and in the long run it helped us a lot and didn't even hurt anybody (not even Clownfish, which is our mascot). Sometimes, because of refactoring, we had to remove a feature from SharpDevelop, but it always re-implemented again later in much better quality and in less time. Some parts were structured whiteboard; some parts have evolved from first tries. But every part has needed refactoring.
So this concludes my highlights of Dissecting a C# Application: Inside SharpDevelop. Its a free download from APress books so if you are like me and interested in the ins-and-outs of a full blown C# application then this would be a good read. Like I mentioned before I really only read chapter two because that's what interested me most about the book.