This chapter is from the book
This chapter is from the book
This chapter is from the book
1.5 Architectural Principles
If at every turn we make just the changes required by the architecture at hand, we'll end up reworking the same areas of code repeatedly. To minimize rework and improve the chances of code reuse, it helps to have some guiding principles as we go. As with all object-oriented programming, one important principle to apply is to separate things that change from things that stay the same. We'll also try to introduce some "layering" of the code, and separate out code that deals with areas such as data access, business logic, presentation, and remote access. While this isn't a book on patterns, we'll apply them where appropriate and mention them wherever they're used.
Another guiding principle is the idea of "refactoring"—that is, the idea of making very small incremental changes to code, not for purposes of adding new functionality or fixing errors but merely to improve the design or readability of the code. Not all of the refactoring that took place in the sample application is visible in the finished code, because in most cases you're just looking at the finished product. However, many times there is code that changes just slightly from one version to the next; in some of those cases I'm taking advantage of an opportunity to refactor something in the code along with other changes I may be making. I'll try to point out these refactorings as they happen; I've found looking for such opportunities really improves the quality of the code I produce and I'd like to try to infect you with the habit.