views:

35

answers:

2

I had a talk with my professor today about the layout of the Chunklist data structure that we've been working on. Basically, it is a hybrid of a ordered circular linked list with each node containing an arraylist.

Since this is an ordered list, the add() method is pretty complicated, so I wrote a nested class to hold the helper methods, such as split a chunk into two smaller even chunks, find the insertion point, create a new node, among others. These helper methods keep the size of the method to under 30 lines, but if everything were included, the one method would be well over 150 lines.

EDIT: clarified professor's point

His position was to do without the helper class and have it only return the node and index inside it, which is used by the iterator and have everything else visible for a point of readability. I constructed a helper class as ListLoc<E> ll= new ListLoc();, and accessing methods as ll.insertItem(item) was, from his point, difficult on readability and program flow. His words "I look to ll as a object for something, not just instance methods." My position was why have these methods visible when they are both integral to the operation of the structure and should not be accessed directly.

So, when constructing a custom data structure, should the helper methods be visible to the end user even when they should NOT be used?

A: 

I don't think they should be visible if they can't be used. Making them private promotes hygiene in the API. But then they should probably not be called 'helpers' either.

Abel Tamayo
+2  A: 

Making them visible and hiding them inside a sub-class aren't necessarily the same thing. I agree with your professor in that creating a class for the sole purpose of encapsulating helper methods isn't the best way to go here. I, too, would expect a class to represent an object that I can declare and could stand alone.

If all you want to do is make functions invisible to the user, then make those methods private methods. If your user is using a pre-compiled version of the library, you don't even have to mention those functions in the class definition that you give the user. This is a much cleaner approach that keeps the functionality restricted to the class' internals without creating an unnecessary sub-class.

Also, remember that all of your helper functions don't have to be members of the class (at least not in C++, other languages may vary). You can create helper functions inside of the .c file where you create your member functions and declare those helper functions static to limit them to file scope. From what you described, it sounds like all of the functions in your helper class can be pulled down to file scope and you can eliminate the extra class.

bta