What are the best practices in OOP?

Hi, my best answer to your question would be giving you a list of bad practices – what you shouldn’t do: Worst practices This post enumerates some of the worst practices which you will have to be carefull NOT TO USE. From the category of “do not even think to do this” here are some bad examples of code encountered: Finder method returns Object Problem: Depending on the number of occurrences found the finder method returns a number representing the number of occurrences – or! If only one found returns the actual object. Don’t do this! This is one of the worst coding practices and it introduces ambiguity and messes the code in a way that when a different developer comes into play she or he will hate you for doing this. Solution: If there’s a need for such 2 functionalities: counting and fetching an instance do create 2 methods one which returns the count and one which returns the instance, but never a single method doing both ways. Problem: A derived bad practice is when a finder method returns either the one single occurrence found either an array of occurrences if more than one found. This lazy programming style is done alot by the programmers who do the previous one in general. Solution: Having this on my hands I would return an array of length 1(one) if only one occurrence is found and an array with length >1 if more occurrences found. Moreover, finding no occurrences at all would return null or an array of length 0 depending on the application. Programming to an interface and using covariant return types Problem: Programming to an interface and using covariant return types and casting in the calling code. Solution: Use instead the same supertype defined in the interface for defining the variable which should point to the returned value. This keeps the programming to an interface approach and your code clean. Classes with more than 1000 lines are a lurking dangerr Methods with more than 100 lines are a lurking danger too! Problem: Some developers stuff too much functionality in one class/method, being too lazy to break the functionality – this leads to low cohesion and maybe to high coupling – the inverse of a very important principle in OOP! Solution: Avoid using too much inner/nested classes – these classes are to be used ONLY on a per need basis, you don’t have to do a habit using them! Using them could lead to more problems like limiting inheritance. Lookout for code duplicate! The same or too similar code could already exist in some supertype implementation or maybe in another class. If it’s in another class which is not a supertype you also violated the cohesion rule. Watch out for static methods – maybe you need an utility class to add! Methods having less parameters or not at all are best Problem: Lazy programmers add one more parameter instead to overload a method or just create another different method for a more complex functionality. Solution: Remember delegation could also be used on methods in same class not only in methods in different classes. It’s better to overload a class which 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. Naughty programmers use reflection to access non-accessible goods Problem: As you know, using reflection permits you access non-accessible fields and/or methods and there are a class of developers using that more than on an exceptional-case only. Solution: Quit doing it! The modifiers were put there for a reason, don’t try to use the api crossing over the boundaries fixed by the original developers since they were put there for a reason and it’s not your job to do theirs. Do use generics. Don’t create a stew instead of some code. Problem: Quit using non-type safe expression, quit inserting mushrooms along with birds and wine because you’re not supposed to create a special dish for dinner, but a well written code. Solution: Use generics – they are a level of security in plus for writing good clean code. They are going to be stripped after the compiling process, so no performance overhead there. Use collections instead of naked arrays or custom made data structures. Don’t reinvent the wheel. Problem: Some developers like reinventing the wheel. There’s nothing wrong in loving to create, but there’s a thin line between creation and re-creation just for the sake of creation. Solution: Instead of using arrays you could use specialized collection classes which have specialized algorithms for various needs: sorting, inserting, queuing, parsing etc. It saves you the time of re-implementing them, they are already tested and proven to work without problems and they are based on well known algorithms for best performance. Do rewrite your personal implementations only if you are strictly obligated by your application requirements and there’s no implementation already existing in the api. More at http://centraladvisor.com B/