I have a few (view) classes.
Table, Tree, PagingColumn, SelectionColumn, SparkLineColumn, TimeColumn.
currently they’re flat under app/view like this:
app/view/Table
app/view/Tree
app/view/PagingColumn
...
I thought about restructuring it, because the Trees and Tables use the columns, but there are some columns, which only work in a tree, some who work in trees and tables and in the future there are probably some who only work in tables, I don’t know.
My first idea was like this:
app/view/Table
app/view/Tree
app/view/column/PagingColumn
app/view/column/SelectionColumn
app/view/column/SparkLineColumn
app/view/column/TimeColumn
But since the SelectionColumn is explicitly for trees, I have the fear that future developers could get the idea of missuse them.
But how to restructure it probably?
Like this:
app/view/table/panel/Table
app/view/tree/panel/Tree
app/view/tree/column/PagingColumn
app/view/tree/column/SelectionColumn
app/view/column/SparkLineColumn
app/view/column/TimeColumn
Or like this:
app/view/Table
app/view/Tree
app/view/column/SparkLineColumn
app/view/column/TimeColumn
app/view/column/tree/PagingColumn
app/view/column/tree/SelectionColumn
Without going too much into detail regarding to your specific scenario, here are a couple of guidelines when structuring classes.
- Usually your file structure should follow the namespaces of your classes, so this question doesn’t really relate as much to file structure as you make it seem, but rather to how to organize classes and about creating the proper abstractions.
- Place classes in the least specific namespace possible. When you created a class for a certain class within a specific namespace, this doesn’t necessarily mean it’s the most logical place to place it. It might be relevant to place it higher up the hierarchy.
- When creating proper abstractions, classes become reusable in a wide set of scenarios, and the namespace should reflect that. Instead of placing a class in a specific application namespace, you could move it to e.g. a common user control namespace.
- Following the cohesion principle, place logically related classes together. E.g. when a set of classes are logically related it might be worthwhile creating a specific namespace and grouping them together within this namespace.
Applying this to your specific scenario the first thing that comes to mind is:
- Common/Layout/Columns/AbstractColumn
- Common/Layout/Columns/PagingColumn
- Common/Layout/Columns/SparkLineColumn
- Common/Layout/Columns/TimeColumn
- Common/Layout/Table
- Common/Layout/Tree
- Common/Layout/Tree/SelectionColumn (could be an inner class)
I’d recommend your first idea, with the an additional partial class “BaseColumn” from the various column classes can inherit from. This would allow you to define the common methods and properties within the “BaseColumn” and implement the differences in the Paging, Selection, Spark and Time column classes.