Packaging Code

When Mihai Budiu interviewed Brian Kernighan in 2000 (http://www.cs.cmu.edu/~mihaib/kernighan-interview/index.html), Brian Kernighan was asked the following question:

"Can you tell us about the worst features of C, from your point of view?"

He responded with the following:

"I think that the real problem with C is that it doesn't give you enough mechanisms for structuring really big programs, for creating firewalls within programs so you can keep the various pieces apart. It's not that you can't do all of these things, that you can't simulate object-oriented programming or other methodology you want in C. You can simulate it, but the compiler, the language itself, isn't giving you any help."

Developers should be warned when they feel that code is being pushed into arbitrary places. This generally implies that the code base does not have a coherence or a sense of purpose distilled from the architecture. This is not just aesthetics or traceability; good packaging is the first step to a maintainable code base.

As we saw in Chapter 1, Building Big with Go, managing complexity is one of the main objectives of architecture. One way of doing this is encapsulation—packaging code into a higher level of abstractions, which create the firewalls that Kernighan described earlier.

This chapter delves into ways of organizing code at two levels:

Object-orientation in Go
Code layout of packages, dependencies, and so on

But before we go there, we need to define crisply a key aspect of module design—contracts.

Table of Contents for Packaging Code

Create new playlist

Sign In

Sign Up

Table of Contents for
Packaging Code