How to avoid confusion with method names between layers of a package

Laszlo Nagy gandalf at shopzeus.com
Sun Jul 31 06:38:25 EDT 2011


   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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110731/b81af3b9/attachment.html>


More information about the Python-list mailing list