Summary

In this chapter, we learned about organizing our namespaces in folders and packages, and how good organization can help to prevent namespace classes. We then moved on to classes and responsibility and looked at why classes should only have one responsibility. We also looked at cohesion and coupling and why it is important to have high cohesion and low coupling.

Good documentation requires public members to be correctly commented on in documentation tools, and we saw how to do this using XML comments. The importance of why you should design for change was also discussed with basic examples of DI and IoC.

The Law of Demeter showed you how to not to talk to strangers, but only immediate friends, and how to avoid chaining. And finally, we looked at objects and data structures and what they should hide and what they should make public.

In the next chapter, we will briefly cover functional programming in C# and how to write clean methods that are small. We will also learn to avoid having more than two parameters in our methods, as methods with many parameters can become unwieldy. Plus we will learn to avoid duplication which can be a troublesome source of bugs when fixed in one location, but still exist elsewhere in your code.