In your object-oriented language, what guidelines do you follow for grouping classes into a single file? Do you always give each class a seperate file? Do you put tightly coupled classes together? Have you ever specified a couple of implementations of an interface in one file? Do you do it based on how many lines of code the implementation might be or how "cluttered" it might look to the user of the class? Or would the user prefer to have everything on one place?
相关问题
- how to define constructor for Python's new Nam
- Keeping track of variable instances
- What uses more memory in c++? An 2 ints or 2 funct
- What is the best way to do a search in a large fil
- Object.create() bug?
相关文章
- 接口B继承接口A,但是又不添加新的方法。这样有什么意义吗?
- What is the correct way to declare and use a FILE
- Making new files automatically executable?
- Should client-server code be written in one “proje
- Algorithm for maximizing coverage of rectangular a
- NameError: name 'self' is not defined, eve
- How to serialize data into indented json [duplicat
- Is there an existing solution for these particular
I put classes into the same file if they belong together, either for techinical or aesthetic reasons. For example, in an application that provides a plugin interface, the classes Plugin (base class for plugins) and PluginManager I would usually put together in the same file. However, if the file grows too big for my taste, I would split them into separate file.
I note that I write code mostly in Python at the moment, and this influences my design. Python is very flexible in how I get to divide stuff into modules, and has good tools for managing the name spaces of things. For example, I usually put all the code for an application in a Python module (a directory with
__init__.py
) and have the module import specific names from sub-modules. The API is then something likeapplib.PluginManager
rather thanapplib.pluginstuff.PluginManager
.This makes it easy to move things around, which also allows me to not be so fussy when I am creating the design: I can always fix things later.
It depends. In team work I try to follow team standards; in solo work I tend more towards whatever-I-please.
In solo work, then ...
No. Sometimes. Yes.
It's mostly based on:
I prefer 1 to 1 for classes unless the inner class will be entirely private. Even then I usually break it out for ease of finding it and tracking changes in SVN.
I think best practices in all OO languages I have ever used is to have one class in one file. I believe some languages may require this but I am not sure of that fact. But I would say that one class per file, and the name of the file matching the name of the class (as well as the directory structure matching the package structure for the most part) is best-practice.
I try to keep one class per file (like most of the above), unless they are small classes. If there are a lot of them, I may split them into subjects otherwise. But usually I just keep them all in one file with code-folding in editors. For my private hacks, it just isn't worth the (minimal) effort to me.