CodeSOD: A Pointer to your References

John C works at a defense contractor, and his peers are well versed in C. Unfortunately, many years ago, a lot of their software started being developed in Java. While references are often described as "pointers, but safer," they are not pointers, so your intuitions about how memory gets allocated and released are likely to be wrong.

Which is definitely the case for John's peers. For example, in C, you generally want really clear understandings of who owns a given block of memory. You don't want to allocate memory and hand it off to another module without being really clear about who is responsible for cleaning it up later. This means that you'll often write methods that expect buffers and other blocks of memory passed into them, so that they don't have to worry about memory ownership.

Which is how we get this block of code:

Set<UniqueArray> myArrays = UniqueArrayUtils.getUniqueArrays(new LinkedHashSet<UniqueArray>());public static Set<UniqueArray> getUniqueArrays(Set<UniqueArray> pUniqueArraySet) { ... for (sensor in getSomeSensors()) { if (blah == blahblah) { pUniqueArraySet.add(new UniqueArray(sensor.special_id, sensor...)); } } ... return pUniqueArraySet;}

"Arrays" here don't refer to arrays in the programming sense, but instead to arrays in the "sensor array" sense. This method is called only once, like you see it here, and could easily have been private.

But what you can see here is some vestige of "who owns the memory". getUniqueArrays could easily create its own Set, return it, and be done. But no, it needs to accept a Set as its input, to manipulate it.

In the scheme of things, this isn't terrible, but this pattern reasserts itself again and again. Methods which could easily construct and return objects instead expect empty objects passed into them.

As John writes:

I imagine an angry C programmer saying, "What do you MEAN there's no pointers?!"

[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.