Tech Tips Digest: 8
In today's post we'll be dealing with some important issues related to class design as well as other useful tips.
Previous Tips: Tip No. 1 | Tip No. 2 | Tip No. 3 | Tip No. 4 | Tip No. 5 | Tip No. 6 | Tip No. 7
Tech Tip No36: Avoid using libraries that aren't standard, or commonly accepted. They might not be dependable!
The main idea here is that you might be tempted to use certain classes from certain libraries that are not fully mature or might change frequently or be retired all together. If you end up using such libraries, especially on critical parts of your system, you might end up facing lots of problems in case something happens to those libraries.
An example of such libraries would be the sun.* library (read more).
Always research your alternatives enough before proceeding, cause generally speaking, there are many alternatives for any kind of problem you wanna solve using a certain library.
A very good source of not only libraries but also components and systems is http://www.apache.org/
Tech Tip No37: Avoid having long inheritance trees, this'll make maintaining the classes a bit complicated & may lead to confusion
Having inheritance trees spanning more than let's say three generations will make your life miserable. Navigating the inheritance chain to find the proper implementation and trying to figure out which class is which.
In the end it's all about proper design, think about the hirarchy well enough at first, see what needs to be generalized and then proceed.
Tech Tip No38: Don't get carried away with lazy loading, it might be better to pre-load certain classes sometimes
Sometimes it might be better to pre-load and not to lazy-load certain componenets in your system. Lazy loading is such a fancy concept that people tend to abuse it, thinking they're doing their system good.
But you have to keep in mind that it comes with a penalty or two. First of all, if the class you're lazy loading is expensive in terms of construction time or space, then it might just be better for you to pre-load it. Second of all, this concept might prove disastrous when used with Singleton having not setup the code properly. You'll end up with multiple instances and not just one real single instance.
Tech Tip No39: When designing classes, make sure they are very well defined. Don't give them more responsibility than is required!
I've often come accross classes that I call huge! Classes so big it blows your mind away. Your best bet is to really think of what your class is for and make sure it serves a very well defined purpose, think about what it has to do and what other classes can do for it.
A very good tool that'll help you with this process is CRC cards. The idea is fairly simple, you write down the name each class and list down its responsibilities and the names of other classes that it has to collaborate with. You'll have to do this for all required classes within a certain subsystem or module. Then, you'll start dealing and presenting the cards based on the expected execution flow and through this process you might end up making changes ranging from simply splitting a card into two classes, dropping a whole card (class!) adding more responsibility to a card or shifting responsibilities to another card.
Tech Tip No40: Don't settle with workarounds, cause most of the time you'll never have the time to make things right later on
This tip is specially valid when you're working on a product. There might be a tendency to perhaps make a quick fix or a workaround, working under aggressive deadlines, this might be OK given you'll truely come back later and fix it properly. But it's usually not the case when you really just keep on moving forward and there's not a team big enough to cater for maintaining two different versions (The latest branch and the trunk).
New features coming in, new requirements and life goes on, then one day the whole thing just blows up in your face and you'll wish you had spent five extra minutes to think it through properly :)
Hope you enjoyed this post and found it useful, drop a comment.
Previous Tips: Tip No. 1 | Tip No. 2 | Tip No. 3 | Tip No. 4 | Tip No. 5 | Tip No. 6 | Tip No. 7
Tech Tip No36: Avoid using libraries that aren't standard, or commonly accepted. They might not be dependable!
The main idea here is that you might be tempted to use certain classes from certain libraries that are not fully mature or might change frequently or be retired all together. If you end up using such libraries, especially on critical parts of your system, you might end up facing lots of problems in case something happens to those libraries.
An example of such libraries would be the sun.* library (read more).
Always research your alternatives enough before proceeding, cause generally speaking, there are many alternatives for any kind of problem you wanna solve using a certain library.
A very good source of not only libraries but also components and systems is http://www.apache.org/
Tech Tip No37: Avoid having long inheritance trees, this'll make maintaining the classes a bit complicated & may lead to confusion
Having inheritance trees spanning more than let's say three generations will make your life miserable. Navigating the inheritance chain to find the proper implementation and trying to figure out which class is which.
In the end it's all about proper design, think about the hirarchy well enough at first, see what needs to be generalized and then proceed.
Tech Tip No38: Don't get carried away with lazy loading, it might be better to pre-load certain classes sometimes
Sometimes it might be better to pre-load and not to lazy-load certain componenets in your system. Lazy loading is such a fancy concept that people tend to abuse it, thinking they're doing their system good.
But you have to keep in mind that it comes with a penalty or two. First of all, if the class you're lazy loading is expensive in terms of construction time or space, then it might just be better for you to pre-load it. Second of all, this concept might prove disastrous when used with Singleton having not setup the code properly. You'll end up with multiple instances and not just one real single instance.
Tech Tip No39: When designing classes, make sure they are very well defined. Don't give them more responsibility than is required!
I've often come accross classes that I call huge! Classes so big it blows your mind away. Your best bet is to really think of what your class is for and make sure it serves a very well defined purpose, think about what it has to do and what other classes can do for it.
A very good tool that'll help you with this process is CRC cards. The idea is fairly simple, you write down the name each class and list down its responsibilities and the names of other classes that it has to collaborate with. You'll have to do this for all required classes within a certain subsystem or module. Then, you'll start dealing and presenting the cards based on the expected execution flow and through this process you might end up making changes ranging from simply splitting a card into two classes, dropping a whole card (class!) adding more responsibility to a card or shifting responsibilities to another card.
Tech Tip No40: Don't settle with workarounds, cause most of the time you'll never have the time to make things right later on
This tip is specially valid when you're working on a product. There might be a tendency to perhaps make a quick fix or a workaround, working under aggressive deadlines, this might be OK given you'll truely come back later and fix it properly. But it's usually not the case when you really just keep on moving forward and there's not a team big enough to cater for maintaining two different versions (The latest branch and the trunk).
New features coming in, new requirements and life goes on, then one day the whole thing just blows up in your face and you'll wish you had spent five extra minutes to think it through properly :)
Hope you enjoyed this post and found it useful, drop a comment.
Comments