#Less is more
NOTE: This gist is a translation from an article by Marcos Douglas. Here is the original version, in Brazilian Portuguese: http://objectpascalprogramming.com/posts/menos-e-mais/.
Have you ever wondered what would be the ideal quantity of arguments in a method? And how about the number of methods on an interface or class? And how many classes would you put inside a single unity?
Let's try and get some numbers.
##Introduction
The length of a class, i.e. the number of methods it implements speaks volumes about it. A class with many methods is doing too much, it has too many responsibilities.
We can apply the same principle to arguments in methods. More arguments, more information, more communication with other objects. So, theoretically, the method is doing too much.
In this article, I'm going to show you some ideal numbers.
I don't assume that you'll agree with everything you'll read but, agreeing or not, these are my numbers.eros.
##Methods
Interfaces should be small, with few methods. Just because the Interface represents a Car, it doesn't mean that it should contain all imaginable methods to implement the car's behavior.
Each interface should have the number of methods that represent an entity in a very delimited context.
The ideal number of methods is something in between 1 and 5 for Interfaces, and, consequently, for classes as well.
However I don't include method overloads in this counting, so, if the class has 3 overloaded Save methods, I count that as just 1. But, even though there may be a lot of overloaded methods, that doesn't mean that the intelligence is in those methods. No. Almost everything can be delegate do other, more expert objects.
##Constructors
The primary and secondary constructors will always be overloads. So you can have how many you want.
But I'd rather have just one constructor and many New methods. That way I get two benefits: a) The class will have just one way to create Objects, and b) The New methods force other developers to use Interface instances and not Class instances.
##Arguments
Use as few arguments as possible in your methods. A method with too many arguments is hard to write, reason about, and read. Remember that, for the most part, a programmer's job is to read code, not to write it.
The same rule should be applied to arguments for the class constructors.
The ideal number for arguments is between 0 and 4.
##Local Variables
Before I began to utilize the New method technique, I used to need a greater number of variables, only to have the reference count working without memory leaks.
Not anymore.
Nowadays I use fewer and fewer local variables and this is evidence of a more objected oriented code. Local variables are used in procedural code. You need a variable to store some value, while you await for another procedure, and then you use the variable you stored in another procedural...procedure.
The ideal number for variables is between 0 and 3.
##Attributes An object's attributes should be in conformity with what the object represents. If you have a method that returns the object in XML format, for instance, but you don't use this format in any other method, then you shouldnt't have this attribute. Instead, create the object only when it's needed, i.e. when the method that request an XML is called.
The ideal number for attributes is between 1 and 7.
Here, however, you can break this rule temporarily if you need to, due to deadlines, complexity, etc. You can increase the number of attributes and refactor lately without any problems, because they will be encapsulated inside the class.
No one knows what happens inside an object, right?
What can't happen is an object that doesn't encapsulate any attribute. An object should always encapsulate something, because it represents something. It must have some state that is implemented by its attributes.
The Object Pascal language was one of the first to implement the concept of packages or namespaces.
Yes, I'm talking about units.
Each unity can contain public or private classes.
The ideal number of classes inside the same unity is between 1 and 11.
I rarely use private classes, because I always think they can be used in other modules. However, if necessary, private classes - it doesn't matter if they're private at the class or unity level - can be implemented following the same rules for the attributes. Since they're private, they can be changed without future problems.
To define maximum numbers of usability is the same as to constrain. And constraints can be good things. Constraints make us think about how to make things more effective and with less waste.
Think about. If you're going to travel overseas, for instance, you must plan carefully what to put in your bag. You must choose what is more important and essential, and nothing else. That way you can travel light and enjoy it to the fullest , without having to worry about countless objects or bags full of stuff that you'd had to carry around.
It's way harder to think about what is essential instead of "putting everything on the bag", but it's an exercise worth doing. You'll be astonished when you see how little you really need.
The same goes for your code. Keep everything light and simple. Just the essential. Because less is more.
See you.