Class naming conventions I have the following scenario:

The (web-) application is built with Java/Spring. I have several REST-endpoints which deliver data prepared to be consumed by a frontend by datatables.net. Each of this endpoint has a somehow similar signature (sEcho, iDisplayStart, iDisplayLength etc.) which are standardparameters necessary to work with datatables. Some of the controllers need additional Information, which are provided in extra variables.

So I made a DatatablesOptions class for the general usecase and if I need additional fields I extend the DatatablesOptions class. 

My question is now about the naming of the extended classes.

There are two approaches:


I have a package for each of the endpoints, where all additional classes for a topic are stored: e.g. "CustomerComplaints". In such a package you would find the derived class which is used for the additional fields exactly for the usecase of "customer complaints". Hence it is in the "CustomerComplaints"-package the name of e.g. "ViewOptions" would be enough to say what it is used for: »This object is used for the options of a view in the context of "CustomerComplaints"«.

So my code in the Controller looks like this:

@Controller
@RequestMapping("/")
public class CustomerComplaints {

[...]
    @RequestMapping(value="/customercomplaints/datatable", method= RequestMethod.GET)
    @ResponseBody
    public AjaxTableModel getCustomerComplaintsForDataTable(@RequestParam (value="sEcho")int echo,
                                            @RequestParam (value="iDisplayStart")int startLine,
                                            @RequestParam (value="iDisplayLength")int linesPerPage,
                                            @RequestParam (value="iSortCol_0")int columnToSort,
                                            @RequestParam (value="sSearch", required = false) String searchString,
                                            @RequestParam (value="statusfilter")FilterOptions filterOptions,
                                            @RequestParam (value="sSortDir_0")String sortingDirection
[...]
ViewOptions o = new ViewOptions()
            .setLinesPerPage(linesPerPage)
            .setStartLine(startLine)
            .setSortColumn(getSortingKeyForColumnNumber(columnToSort))
            .setSortingDirection(sortingDirection)
            .setFilterOptions(filterOptions)
            .setSearchString(searchString);


The job of the ViewOptions-class is in every controller the same and for the understanding of the code neglectable.

So a further specification via the classes name is not necessary. It seems to me like some kind of "Hungarian Notation". The name CustomerComplaintsViewOptions provides not more Information in this context. And the package makes it unambigous enough. Every smart IDE should resolve the definition for that.
The second approach, which is more texteditor-friendly, is to make it easy to find the definition of this class and name it CustomerComplaintsViewOptions. So a coworker sees from the variable name, where to look, when he wants to know more.


What kind of naming is better style?
Actually #1 is called smurf naming (here is a question about it on Programmers.SE). 

One thing to consider: Do you have to work with more than one ViewOptions at the same time (or at the same source file)? If that's true having a more specific name would help. Two possible advantages of smurfier names:


There aren't multiple editor tabs with the same filename.
You don't have to use full package names to declare two ViewOptions in the same source file.


  So I made a DatatablesOptions class for the general usecase and if 
  I need additional fields I extend the DatatablesOptions class. 


Check Effective Java, Second Edition, Item 16: Favor composition over inheritance if you don't know already.
Try to format the code in a way which avoid unnecessary horizontal scrolling. It would make it esasier to read.
@RequestParam (value="iDisplayStart")int startLine,
@RequestParam (value="iDisplayLength")int linesPerPage,
@RequestParam (value="iSortCol_0")int columnToSort,
@RequestParam (value="sSearch", required = false) String     searchString,


Some of the parameters have a space between the closing parentheses (...false) String) , some of them doesn't (...th")int linesPerPage). You can find another inconsistencies too. It should be consistent. Modern IDEs have autoformat, they do a really good job here, use them.