Hi All,
I have a package with more layers of code. Bottom layer contains classes
and methods for dealing with tabular data. Second layer works with
multi-dimensional data. It provides a data model with unified API for
accessing multi dimensional databases. Top layer is responsible for
displaying views of the data model.
The data model can be used in other (non-GUI) applications as well. When
I was developing the data model, I have tried to follow PEP 8. For
method names, it says:
"Use the function naming rules: lowercase with words separated by underscores as
necessary to improve readability."
I also tried to follow Demeter's law.
(http://en.wikipedia.org/wiki/Law_of_Demeter)
Here are some classes from different layers:
Facts - access facts data (non-visual)
Query - query facts with cache, holds a reference to a Facts (non-visual)
Cube - drill facts for any number of dimensions, holds a reference to a
Query (non-visual)
CubeGrid - displays a cube in a pivot grid (visual component)
Some methods in one class are also useful in another. For example, a
Facts instance can tell the number of measures in the database. A Cube
instance indirectly "owns" a Facts instance (through a Query). So
Cube.get_measure_count() is a wrapper for Query.get_measure_count()
which is a wrapper for Facts.get_measure_count(). This is good, because
- given a cube instance - you can call *cube.get_measure_count()*
instead of *cube._query._facts.get_measure_count()*. The latter would be
ugly, and require extra knowledge about the inner structure of the Cube.
So far so good. The problem is that a CubeGrid instance is also a
wx.Grid instance. However, different naming conventions apply there. All
method names in wxPython are coming from C++. They use CamelCase method
names. There is a naming conflict. What should I do?
Solution #1: Mix CamelCase and PEP 8 names in the CubeGrid class. Very
ugly, inconsistent.
Solution #2: Convert old PEP 8 names in the CubeGrid class, so every
method in CubeGrid will have CamelCase names. Very inconsistent! Who
would understand that CubeGrid.GetMeasureCount() is the same as
Facts.get_measure_count()?
Solution #3: Drop Demeter's law here, and always use
*CubeGrid.GetCube().get_measure_count()* - doesn't look very nice.
Any other ideas?
Thanks,
Laszlo
--
http://mail.python.org/mailman/listinfo/python-list
