Delete Your Old Resume!
The cutting-edge software project I have been working on for the past couple of years is being axed. Accordingly, I have turned my attention towards finding an exciting new software development opportunity. As you know, I put 110% into everything I do. When I’m looking for a new job, the search gets 110% of my creative energy, my personal improvement efforts, and my ground-breaking practical experimentation. This time, I learned one simple thing that will radically alter the entire process.
The New Rule of New - Internal Objects
One of the challenges in Object-Oriented Design is figuring out exactly when and where objects should be instantiated. Where is the best place to create a new instance of an object? Where is it critically important not to create new object instances? When should you return a new copy of an object, rather than an existing instance? What are the competing code attributes that must be balanced against each other?
Type Erasure is a Failed Experiment - Type Integrity
In part one, we introduced the topic of Type Erasure, looked at an imaginary conversation with C# and the same conversation with Java, and delved into some of the problems with Java Generics. If you haven’t read that, go back and read it before you read this post.
Type Erasure Is A Failed Experiment - Interface Segregation
Generics are amazing! There is something immensely satisfying about solving an entire class of similar problems, rather than just solving a single instance of a problem. Why figure out how to cache this one database call, when I could figure out how to cache an arbitrary number of varying database calls? Why merely solve authenticating one web request, when a solution to authenticating all web requests is within reach? The scope of engineering problems vary, but my tendency does not. I would rather solve something abstractly, than concretely. Creating simple, elegant, portable solutions to particular type of problems is immensely satisfying.