Worst practices in OOP.

This post enumerates some of the worst practices which you will have to be careful
NOT TO USE.
From the category of do not even think to do this here are some bad examples of code
encountered:
1. Finder method returns Object
roblem: !epending on the number of occurrences found the finder method returns a
number representing the number of occurrences " or# $f only one found returns the actual
object.
!on%t do this# &his is one of the 'orst coding practices and it introduces ambiguity and
messes the code in a 'ay that 'hen a different developer comes into play she or he 'ill hate
you for doing this.
(olution: $f there%s a need for such ) functionalities: counting and fetching an instance do
create ) methods one 'hich returns the count and one 'hich returns the instance* but never
a single method doing both 'ays.
roblem: + derived bad practice is 'hen a finder method returns either the one single
occurrence found either an array of occurrences if more than one found. &his la,y
programming style is done alot by the programmers 'ho do the previous one in general.
(olution: -aving this on my hands $ 'ould return an array of length 1.one/ if only one
occurrence is found and an array 'ith length 01 if more occurrences found. 1oreover*
finding no occurrences at all 'ould return null or an array of length 2 depending on the
application.
). rogramming to an interface and using covariant return types
roblem: rogramming to an interface and using covariant return types and casting in the
calling code.
(olution: 3se instead the same supertype defined in the interface for defining the variable
'hich should point to the returned value. &his keeps the programming to an interface
approach and your code clean.
4. 5lasses 'ith more than 1222 lines are a lurking danger
1ethods 'ith more than 122 lines are a lurking danger too#
roblem: (ome developers stuff too much functionality in one class6method* being too la,y
to break the functionality " this leads to lo' cohesion and maybe to high coupling " the
inverse of a very important principle in OO#
(olution: +void using too much inner6nested classes " these classes are to be used O789
on a per need basis* you don%t have to do a habit using them# 3sing them could lead to more
problems like limiting inheritance. 8ookout for code duplicate# &he same or too similar code
could already exist in some supertype implementation or maybe in another class. $f it%s in
another class 'hich is not a supertype you also violated the cohesion rule. :atch out for
static methods " maybe you need an utility class to add#
;. 1ethods having less parameters or not at all are best
roblem: 8a,y programmers add one more parameter instead to overload a method or just
create another different method for a more complex functionality.
(olution: <emember delegation could also be used on methods in same class not only in
methods in different classes. $t%s better to overload a class 'hich takes the parameter and
delegates the same functionality to an already existing method instead of adding an extra
parameter to a method or " do a different method if that%s the case.
=. 7aughty programmers use reflection to access non>accessible goods
roblem: +s you kno'* using reflection permits you access non>accessible fields and6or
methods and there are a class of developers using that more than on an exceptional>case
only.
(olution: ?uit doing it# &he modifiers 'ere put there for a reason* don%t try to use the api
crossing over the boundaries fixed by the original developers since they 'ere put there for a
reason and it%s not your job to do theirs.
@. !o use generics. !on%t create a ste' instead of some code.
roblem: ?uit using non>type safe expression* Auit inserting mushrooms along 'ith birds
and 'ine because you%re not supposed to create a special dish for dinner* but a 'ell 'ritten
code.
(olution: 3se generics " they are a level of security in plus for 'riting good clean code. &hey
are going to be stripped after the compiling process* so no performance overhead there.
B. 3se collections instead of naked arrays or custom made data structures. !on%t
reinvent the 'heel.
roblem: (ome developers like reinventing the 'heel. &here%s nothing 'rong in loving to
create* but there%s a thin line bet'een creation and re>creation just for the sake of creation.
(olution: $nstead of using arrays you could use speciali,ed collection classes 'hich have
speciali,ed algorithms for various needs: sorting* inserting* Aueuing* parsing etc. $t saves
you the time of re>implementing them* they are already tested and proven to 'ork 'ithout
problems and they are based on 'ell kno'n algorithms for best performance. !o re'rite
your personal implementations only if you are strictly obligated by your application
reAuirements and there%s no implementation already existing in the api.