 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2006what is a helper class ?
Hi, I want to know , what is a helper class ? i have seen this term is frequently used in EJB, JAVA ,JSP in many places. and it seems to me they have different meaning in different context. is it so ? I found normal java classes are helper classes. why they are called helper then ....does it help ? help to whom ? can you please show me an example of helper class and tell me how it helps ? >I want to know , what is a helper class ? The authors using this term are indeed to blame, because it just shows their lack of ability or desire to search for a specific designation. Sometimes, for example, it might be a class lacking proper cohesion and just containing different (static) methods for several purposes. A properly modelled class system should not have "helper classes" in this sense. Other times, it might mean something else. >why they are called helper then ....does it help ? help to whom ? Help the user of the term not to think of a better wording. > I want to know , what is a helper class ? Someone sets out to write a class C that does something. After a while, the author realizes it would be useful to have a separate class D to do some of the work. The author writes class D purely to support class C; D is never used except as part of the implementation of C. D is a helper class. I tend to agree with Stefan that if you need a helper class, you're generally better off designing the class in a generalized fashion, such that it has the potential to be useful in other contexts than the one that inspired its creation. For example, Java has an interface called FileFilter, but in my own code, I have Filter<T>, such that concrete classes can extend Filter<File>, or Filter<Integer>, or whatever, without requiring a new interface for each type of filter. If you do this successfully, you won't end up with any pure "helper" classes. The name HelperClass is not particularly useful from a documentation standpoint, either. > I tend to agree with Stefan that if you need a helper class, you're > generally better off designing the class in a generalized fashion, such > that it has the potential to be useful in other contexts than the one > that inspired its creation. This depends on the situation. If adding the new abstraction causes you to do anything differently from the way you would do it in a more specific case, then the new way is in that respect inferior for the originally intended purpose. It's then time to compare that cost against the potential for re-use, and make an informed decision. As one input into that informed decision, consider that reuse is the most over-rated of all the frequently listed advantages to object oriented programming. > If you do this successfully, you won't end up with any pure "helper" > classes. Considering that a "helper" class doesn't really have much meaning beyond a class that handles part of the work of building an abstraction, eliminating helper classes is a rather poor goal. Well-designed object oriented applications end up looking like a layered system of abstractions. From the perspective of any higher level of abstraction, *any* class belonging to a lower abstraction level can reasonably be described as a "helper" class. > The name HelperClass is not particularly useful from a documentation > standpoint, either. Certainly not as end-user documentation, nor as the only description of what a class does.  SignatureChris Smith >> I tend to agree with Stefan that if you need a helper class, you're >> generally better off designing the class in a generalized fashion, such [quoted text clipped - 8 lines] > time to compare that cost against the potential for re-use, and make an > informed decision. You have a good point, but I don't know that a generalized solution is automatically inferior to a custom solution, any more than hand-made goods are automatically superior to machine-manufactured alternatives. Implementing a class in the most general possible way has the nice side-effect of distilling the exact concept the class is meant to represent, and helps keep fundamentally separate logic wherever it really belongs. You're right that generalization isn't always worth the time, though, nor is it guaranteed to improve the product as a whole. > As one input into that informed decision, consider > that reuse is the most over-rated of all the frequently listed > advantages to object oriented programming. Is that still true? It certainly used to be. I hear more about maintainability and logical correctness than about reusability nowadays. It seems like fat interfaces were in vogue for a while, with classes trying to be all things to all people in the wan hope of potential reuse. Now we seem to have swung to the opposite extreme, with lots of tiny, immutable objects being the hallmarks of best practice. >> If you do this successfully, you won't end up with any pure "helper" >> classes. > > Considering that a "helper" class doesn't really have much meaning > beyond a class that handles part of the work of building an abstraction, > eliminating helper classes is a rather poor goal. Nonsense. By that definition, all classes are helper classes. You might as well throw the term away entirely. Do you actually find that your released code has lots of classes called DoohickeyHelper? I bet it doesn't, because you are an experienced developer, and you probably know better. > Well-designed object > oriented applications end up looking like a layered system of > abstractions. True. I think that's true of good procedural programs, too, but even more so of OOP. > From the perspective of any higher level of abstraction, > *any* class belonging to a lower abstraction level can reasonably be > described as a "helper" class. You could choose to view it that way, but I don't think it would be very useful. Primitive ints and doubles aren't just "helper types" by virtue of being low-level. I don't know whether anybody has assigned "helper class" a formal definition, but this certainly isn't the way it is used in practice. >> The name HelperClass is not particularly useful from a documentation >> standpoint, either. > > Certainly not as end-user documentation, nor as the only description of > what a class does. The end user shouldn't see the helper class at all, else it's part of the public interface, and not just a helper. I think a helper is, by de facto definition, part of the implementation code, but specifically not part of the interface. OTOH, if you really have a class that's just a place to dump some code related to Foo, then I suppose FooHelper is a reasonable name. What would bother me personally about that name is that it makes me feel the code probably belongs in Foo proper, else it should not have been factored into a separate type. > > I want to know , what is a helper class ? > [quoted text clipped - 3 lines] > D is never used except as part of the implementation of C. D is a > helper class. ok. suppose i wrote a bean class class C { D mydobject; //get // set } class D { //get //set } can we say D is now a Helper class ? look i have made D as a member variable of class C. > I tend to agree with Stefan that if you need a helper class, you're > generally better off designing the class in a generalized fashion, such [quoted text clipped - 6 lines] > name HelperClass is not particularly useful from a documentation > standpoint, either >>> I want to know , what is a helper class ? >> Someone sets out to write a class C that does something. After a while, [quoted text clipped - 24 lines] > can we say D is now a Helper class ? look i have made D as a member > variable of class C. It's impossible to tell whether D is a mere helper class from the code you have shown. The fact that C has a member of type D does not tell us whether it is a helper, or a concrete type, or just some object with which C interacts. For example, a graphical component can have a reference to its parent container, but that does not make the parent container's type a helper class for the component. >> can we say D is now a Helper class ? look i have made D as a member >> variable of class C. > > It's impossible to tell whether D is a mere helper class from the code > you have shown. The fact that C has a member of type D does not tell us Yes, Jeffrey is correct. My Java is a little rusty still, but I think this example might help: // All in file MyBean.java public class MyBean { void setA ( ... ){...}; String getA () {...}; // Many more methods... // ... } class MyBeanHelper { // Methods here to help MyBean } Note that the name is unimportant. MyBeanHelper is a private class that is only accessible from within the MyBean.java file. That means it's probably got only one function, something to do with MyBean. Since it isn't the MyBean class itself, it's safe to assume that it's a helper class for MyBean. > >> can we say D is now a Helper class ? look i have made D as a member > >> variable of class C. [quoted text clipped - 15 lines] > // Methods here to help MyBean > } How its going to help MyBean class ? whats the relationship with MyBeanHelper class and MyBean class. you told MyBeanHelper helps MyBean class...but how ? > Note that the name is unimportant. MyBeanHelper is a private class that > is only accessible from within the MyBean.java file. That means it's > probably got only one function, something to do with MyBean. Since it > isn't the MyBean class itself, it's safe to assume that it's a helper > class for MyBean. i think you can define a 'helper class' or a 'helper method' as something that's not 'conceptually' connected to your application, having no meaning attached to it, serving solely for "helping" other classes. It has nothing to do with visibility or encapsulation (public/private...) although you are not expected to use 'helper' functions from any library. maas - www.marcosaurelio.com > > >> can we say D is now a Helper class ? look i have made D as a member > > >> variable of class C. [quoted text clipped - 27 lines] > > isn't the MyBean class itself, it's safe to assume that it's a helper > > class for MyBean. > How its going to help MyBean class ? Just by being there. :) Presumably it has some methods for MyBean to call, but there might be other ways too. > whats the relationship with MyBeanHelper class and MyBean class. They are in the same file. That's all. > you told MyBeanHelper helps MyBean class...but how ? Method invocation, or instantiation. There is no formal relationship other than both classes exist and one (the helper) has no other relationship with any other part of the program. gk skrev: > Hi, > [quoted text clipped - 13 lines] > can you please show me an example of helper class and tell me how it > helps ? Rather than the interesting replies you've received so far, here's some boring, home-grown examples. I'd consider the three LocalLibrary classes are helper-classes here: http://www.edmundkirwan.com/servlet/fractal/cs1/code/all-link0.html I'd consider the FrequencyAnalysis class a border-line helper-class (border-line because it seems less transportable, somewhow; just a feeling): http://www.edmundkirwan.com/servlet/fractal/cs1/code/package100.html .ed -- www.EdmundKirwan.com - Home of The Fractal Class Composition. Download Fractality, free Java code analyzer: www.EdmundKirwan.com/servlet/fractal/frac-page130.html Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.