Code reusability: don’t reinvent the wheel

--Originally published at Hermes's Blog

As the title says, it is completely unnecessary to rewrite code that it has already been written, it is, most of the time, a waste of your time and effort. With all the open source code available nowadays, it is really probable that you find whatever you are looking for on sites like github, gitlab, bitbucket or any other site, and if you don’t find it, well, then now you know what’s going to be your next open source contribution. You should really focus on writing building on top of what others have already done, also, it is worth to notice that you should be writing reusable code as well.

Some tips on writing reusable code:

  1. Don’t repeat yourself: if you find yourself writing the same code several times, probably you should move that piece of god to a module or something alike.
  2. Make a class/method do just one thing: remember the Unix philosophy? write programs that do one thing and do it well, also, write these programs to work together, the secret is in writing generic code to accomplish one simple thing, then use the output of that as input of another program to accomplish a more complex task, don’t make code too generic tough, or it will be difficult to find a purpose to it.
  3. Write unit tests for your classes and make it easy to test classes.
  4. Remove the business logic or main code away from any framework code.
  5. Try yo think more abstractly and use Interfaces and Abstract classes.
  6. Write code that can be easily extended in the future, for code leverage of course.
  7. Don’t write code that isn’t needed, if you doubt if the code is needed, then it is not, just leave it out.
  8. Try to reduce coupling, avoid modules/classes depending on each other.
  9. Be more modular, again, the Unix philosophy.
  10. Write code like your code is an External API, write everything modular and do one thing, then make these components work together to accomplish one common objective, by the end of the day you will have nice, modular and reusable code.

Code reusability: don’t reinvent the wheel

Sources:

http://hoskinator.blogspot.mx/2006/06/10-tips-on-writing-reusable-code.html

What’s the use of code reuse?

 


Code reusability: don’t reinvent the wheel

Overloading vs. Overriding

--Originally published at Orientierteprogrammierungobjekteundetwasmehr

Overloading vs. Overriding

Serendigity. “Overload” Online Image. Flickr. Octover 3, 2007. https://www.flickr.com/photos/maleny_steve/1473552769/

Overloading and overriding are two similar concepts -they both are about creating several methods with the same name- but very different when it comes to practical functionality and implementation.

Overloading (formally, static polymosrphism) is resolved at compile time, and it is when the methods with the same name are declared in the same class, distinguished only by their signatures (the parameters of the method), so when the compiler knows which method overload you are calling based on the data type of the arguments you are passing.

Overriding (or overwriting, according to ken), is resolved at runtime and it is when you define a method that is already defined in a parent class. It can be resolved because of the data type of the “implicit first parameter” (aka, the object itself).

Java implementation

Overloading

Overloading vs. Overriding

Overloading with different data types and number of parameters.

Overloading vs. Overriding

Overloading with same data types and number of parameters, but different order.

Overloading vs. Overriding

Overloading allow different return types.

Overloading vs. Overriding

The return type of the method is not considered when overloading.

Overriding

Overloading vs. Overriding

In this example of overriding I have the Person abstract class, this class cannot be instantiated, but it provides like a “template” for its children classes. For example, the Person class has a String field “name”, because every person has a name, and a public method “talk” because all persons can talk (ok, almost all), this method prints “I’m a ” to the console, because, like I said, this is like a template, and different persons have different (very interesting) things to say. The method “getName” returns the name of the person. The constructor just takes the String name, although you can’t call this constructor directly, it can be called from its children classes.

It’s children classes are not abstract and extend (are children of) the Person class. They implicitly have “name”, a method “talk” and a method “getName”. Read the code of the Student and the Teacher classes and note how the constructors have a line “super(name)”, this is a call to the parent class constructor, and it will throw an error if it’s not there. Both the Student and the Teacher class Override the talk method, the notation @Override over the talk method just tells the compiler that you are overriding a method (no shit, Sherlock), it’s not required but you should use it to enforce proper overriding of a method. The talk() methods of Student and Teacher call the “super.talk” method (unlike the constructor, you can miss this statement here and there will be no errors), it prints “I’m a “, and then it prints something else. I also included an Overload of an Overriding method (mind blown) in the Student class to show the difference, it just prints “I love” + the argument (there is no call to super.talk()).

In the main method of the Person class I declare 2 persons, one teacher and other student, also, I declare a Student as a Student, this sound stupid but actually affects in the code. The preferred way is to declare the variable with the data type of the abstract class and instantiate it as the type that you actually want to use (Declared type on the right and Actual type on the left), so your code is not dependent from a specific implementation of an interface/abstract class. You can read more about this here. You can see that when the talk method is called from both the teacher and the student they print different things. Finally, to call the Overload method “talk(String food)” of “s” (with Declared type Person and Actual type Student) you have to implicitly cast it to Student and then call the method, like ((Student)s).talk(“tacos”), this is because this implementation is not declared in the Declared type of “s”. However, with “c” this does not happen, you can call that overload method because the Declared type of “c” is Student. Anyway, this is not considered a good OO practice, you should avoid writing methods that are not in the parent class, because there is a method specific to the Children class, and therefore making the code dependent from that class, and what you want is to make the code independent from specific implementations of the children class (like explained in the previous stack overflow link).

Overloading vs. Overriding


Overloading vs. Overriding