This week in Software Engineering, we finished discussing method overriding in Java and emphasized the fact that the type of arguments must match in order for the method to be overriden in a child class. One of the potential issues with this is that a change in the method signature in the parent class would result in incorrect behavior for classes who override that method. This issue can be avoided by declaring methods as abstract so that child classes are forced to override them.However, doing so is impractical in many scenarios because Java does not allow abstract methods to implement any behavior, so this may result in a duplcation of code in the child classes.

We also discussed the singleton pattern, which is to have only one instance of the object in order to avoid the cost of creating an object every time one its instance methods is needed. We implemented both the lazy and eager versions of this pattern. One of the interesting things we learned was that Java has a Class object to represent each of the classes as well as a map of class name to that class’s Class object. This is useful in dynamically determining which object is required given only a string instead of having to use a switch statement.

The last thing we learned this week was about using factory methods as a way to not duplicate complicated logic in code but still have the flexibility to specify which objects/behavior should be used. The factory would define a method to create the object that may differ for different classes. (On a side note, here’s a slightly overboard example of using factories).

For the software tip of the week, check out RxJava if you ever need to use asynchronous and event-based programs. This is especially useful in Android development in making code that is normally deeply nested callbacks a lot easier to understand and maintain.