It might be a matter of preference, and thus be biased. But it's such an important matter that I find it really interesting to have some feedback on this question.
Needless to say, any language needs them. But when and why is it best to resort on them?
Is it wise to use a function just for clarity, even if it's not used more than once in the code?
Where do you usually declare your functions (in js for instance), just before you use them for the first time? at the beginning of the script? …?
The practice we use at our company is to only use functions when a piece of code is reused, were the function is located depends on what is reusing the function. If it is only used, lets say within a class then we would keep the function within that scope. If is it reused by other classes then most likely we would add it to a utility class accessible by other classes unless it is directly associated with that class object in that case we would make it public within that class.
Hope that helps!
Related
I want to dispatch events to announce the progress of an asynchronous process. The event should contain 2 properties: work done and work total.
As the name suggests ;) i could use ProgressEvent; it has bytesLoaded and bytesTotal properties that i can use. However, my async process isn't loading bytes, its processing pixels, so the property names are a bit misleading for my use case - although the class name is perfect.
The alternative is to create a custom event with two properties that i can name how i like. But this means another class added to the code base.
So my question is; Is it better to reuse an existing class where the properties are suitable but maybe the naming isn't ideal; Or to create a custom class that perfectly fits the requirement? Obviously, one extra class is no big deal, but OOP is all about reusing stuff so adding an unnecessary class does make me uneasy.
I await your thoughts...
PS: This is my first question on stack so be gentle
For clarity, I'd create a new class. Adding a new class is not much overhead at all, especially for something simple like an event. I find that code is more readable when I don't have to make mental translations (like bytesLoaded really means pixelsLoaded). To me this is akin to choosing poor names for variables.
In addition, by going the other route and re-using the ProgressEvent class, I would feel compelled to document the code to indicate that we're dealing with pixels rather than bytes. That starts to get messy if you have a lot of classes that uses the event.
Re-use is great, but I'd opt for clarity as long as it doesn't impact your productivity or the app's performance.
writing in doc clearly, using custom event or ProgressEvent is well.
It's good to split code up into functions and classes for modularity / decoupling, but if you do it too much, you get really fragmented code which is also not good.
What is the golden rule for when to split code up into functions?
It really does depend on the size and scope of your project.
I tend to split things into functions every time there is something repeated, and that repetition generalized/abstracted, following the golden rule of DRY (Do not repeat yourself).
As far as splitting up classes, I tend to follow the Object Oriented Programming mantra of isolating what is the same from what is different, and split up classes if one class is implementing more an one large theoretical "idea" or entity.
But honestly if your code is too fragmented and opaque, you should try considering refactoring into a different approach/paradigm.
If I can give it a good name (better than the code it replaces), it becomes a function
I think you generally have to think of a chunk of codes have a chance of being reuse. It comes with experience to figure that out and plan ahead.
I agree with the answers that concentrate on reusability and eliminating repetition, but I also believe that readability is at least as important. So in addition to repetition, I would look for pieces of code (classes, functions, blocks, etc.) that do more than one thing.
If the name associated with the code does not describe what it does, then that is a good time to refactor that code into units which each have a single responsibility and a descriptive name. This separation of concerns will help both reusability, and readability.
Useful code can stick around for a long time, so it is important that you (or ideally someone else) can go back and easily understand code that was written months or years before.
Probably my own personal rule is if it is more than 2 lines long, and is referenced more than once on the same page (ASP.net), or a few times spread over a couple of pages, than I will write a function to do it.
I was taught that anything you do more than once should be a function. Anything similar should have a parent class, and above all else consult your source code "standards" within your organization. The latter mostly deals with formatting.
First, write the feature you're adding. (Notice the word "First", we tend to write a function/class before writing the feature, which might lead to having too many fragmentation).
Then, review the code you just wrote/changed, find what blocks of the code that is:
3-lines or more, and..
repeated, and..
Can be grouped under a named function. Because code is written by us, people (not programs), to be read/changed later by us, people (not programs).
Personally, I've never liked the MyObject naming of classes. I would guess that the status quo would agree but I'd like to see the other side of the argument and if there's any validity to it.
'My' is already used by me, use something else
I've never seen it done in production code, although I dare say it exists.
It's like the metasyntactic variables "foo" and "bar" - it's usually used as a placeholder for a real name.
So for example, if I know that someone has their own class deriving from Form, but I don't know anything else about it, a code example would use:
public class MyForm : Form
I'd certainly take a firm stance against it for real code though :)
I suppose one instance where it would be close to acceptable is if the class you're prefixing with "My" is an inner class (i.e a private class declared within another class). I'm not sure if there are any naming conventions governing inner classes, but this could be one way to differentiate.
As far as I've ever seen, My is a prefix used in sample code that indicates "your stuff goes here".
It's kind of like foo. Teaching purposes only.
I've used My in 2 situations:
Way back when in my first programming classes in school
When I am doing basic 'hello world' applications to learn a language
but NEVER in production or even pseudo-production code.
I'd avoid it in production code, your type name should reflect the function its supposed to perform.
I've used it a couple of times when patching/hacking third party code, for instance replacing Controller with MyController to make it clear it is a hack, that should be approached with caution, and a bat.
I have problems with how to design some classes. I have three classes. One superclass, and two subclasses.
One subclass (AnimatedCharacter) is made by flash, and is used to display the object on screen. The other (CharacterPhysics) is made by myself to extend the superclass.
The problem is that the object I use, is of the type AnimatedCharacter, so I can't just put it in a variable of type CharacterPhysics.
What I tried is some sort of Decorator pattern, by giving the object of type CharacterPhysics a reference to the other object. But now I have to override all the methods of the superclass and pass the methodcalls to the reference. Not an ideal situation.
Does someone know how to solve this kind of problem?
alt text http://www.freeimagehosting.net/uploads/7a95f8352c.png
I don't quite understand the purpose of this class structure you describe (the class names confuse me), but in general a few things come to mind that might help you:
Almost always the best solution is to try and rethink your class model by evaluating whether you should for example break up the responsibilities of classes in an alternate way so that you could utilize inheritance and polymorphism in a better way.
"The problem is that the object I use,
is of the type AnimatedCharacter, so I
can't just put it in a variable of
type CharacterPhysics."
If you want to put an AnimatedCharacter into a variable of type CharacterPhysics, the former should extend the latter, or you should have a common interface (or superclass) for both and then type the variable as such. If this is not possible, my opinion is that you should probably try to rethink and refactor your whole class structure, assuming that you have a solid "object-oriented" reason for wanting to do this in the first place ;).
If the above is not possible, there are some other tricks you can evaluate in your context:
The use of mixins can work as a "poor man's multiple inheritance". Derek Wischusen has some examples on how to implement them in AS3 at flexonrails.net.
"Kind of" implementing the decorator pattern with flash.utils.Proxy. The problem with this approach is that you defer a lot of error checking from compile time to runtime, but the good thing is that you don't have to manually write the "proxying" implementations of all of the methods of the "decorated" object, but write just one (callProperty()) instead.
You can interpret a sublass as an instance of a superclass but not vice sersa. Did you state this backwards?
If so, you could use:
vas cp:CharacterPhysics;
...
var ac:AnimatedCharacter = cp As AnimatedCharacter
Off the top of my head, it seems like those 2 should be interfaces which your main class implements
I sometimes end up with a class hierarchy where I have an abstract base class with some common functionality and a couple of implementing classes that fall into two (rarely more) groups which I want to treat differently in some cases. An example would be an abstract tree node class and different branch and leaf implementations where I want to distinguish branches and leaves at some point.
These intermediate classes are then only used for "is-a" statements in flow control and they don't contain any code, although I have had cases where they "grew" some code later.
Does that seem smelly to you? In my tree example, one alternative would be to add isLeaf() / isBranch() abstract methods to the base class and implement those on the intermediate classes, but that didn't seem to be any better to me, really, unless I'd mean to have classes that could be multiple things at once.
To me, using "is-a" tests in flow control is just as smelly as using switch/case. In a good OO design, neither is needed.
Yes, deep inheritance hierarchies are a code smell anyway.
Yup, definitely a code smell -- don't code these empty classes unless you're ready to write that code into it. Think YAGNI (you aint gonna need it) -- don't do it unless you need it already.
Also, have you considered cases wherein these classes are only there to provide abstract methods, or to group them based on capabilities in terms of methods or properties?
If that's the case, maybe what you really need are interfaces, not additional abstract classes?
In general, empty classes are a code smell.
I agree your isLeaf or isBranch methods are a correct alternative.
They add information about the objects , which is helpful.
(This is because, on the super class, you can't express that subclasses are "either leaf or branch").
The two methods with opposite results might also be considered as code duplication.
You could use only one... But I would recommend return an enumerated value LEAF or BRANCH.
A class that doesn't contain any code is definitely a code-smell....
Seems alright to me, if you're going to put new functionality in later.
But if not, an enum is generally used here.
-- Edit
Though I must agree with Ber, that you shouldn't generally be using 'is-a' anyway.