17

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?

Ryan Guill
  • 13,558
  • 4
  • 37
  • 48
Doug T.
  • 64,223
  • 27
  • 138
  • 202
  • 1
    You're allowed to create multiple files? Why have I been putting my entire application in 1 file this whole time? :P – Kibbee Jan 22 '09 at 17:14
  • 1
    So.. you're saying you can have more than one class? – Scott Langham Jan 22 '09 at 17:27
  • 1
    Seems closely related to http://stackoverflow.com/questions/360643/is-it-a-bad-practice-to-have-multiple-classes-in-the-same-file – Suma Apr 05 '11 at 15:26

11 Answers11

26

Personally, I suggest one class per file unless the secondary classes are private to the primary class in the file. For example, a nested class in C# would remain in the parent classes file, but utility classes that might be useful elsewhere get broken into their own file or even namespace.

The key is to understand your environment and where people will look for things. If there is an established methodology in place, think carefully before you upset it. If your coworkers expect that related, tightly bound classes will be in a single document, having to search for them could be annoying (although with modern IDEs it shouldn't be a problem).

An additional reason for breaking things into more files rather than less is version control. If you make a small change, it should change only a small file where possible. If you make a sweeping change, it is obvious looking at the logs because of all the files (and indirectly, classes) that were affected are noted.

Godeke
  • 16,131
  • 4
  • 62
  • 86
  • 1
    In C# you can stick the inner class in a seperate file. With the help of the "partial" keyword, you can divide a class up in several files (although overuse of this is clear indicator that the class has way too many responsibilities). – Spoike Jan 22 '09 at 17:15
  • Well, yes... but I'm not sure I would normally want to do that. Partial is great for the UI builder, as it hides nasty details from the programmer. On the other hand, partial ads to the complexity of the solution structure, so I would tend to avoid it *unless* it was to do metaprogramming like UIs. – Godeke Jan 22 '09 at 17:19
  • Yes, a UI designer is a form of metaprogramming. If is easy to extend the UI design surface with your own controls and write code that generates effects both design time and run time, I'm not sure how it fails the definition "a program that manipulates itself or other programs". – Godeke Jan 22 '09 at 19:27
  • The difference is that you didn't write the UI designer, you're just using it. So it's no more meta than using a text editor. –  Jan 22 '09 at 20:13
  • I think we are agreeing past one another. I said "Partial is great for the UI builder" and "unless it was to do metaprogramming like UIs". I think partial is *fine* for UI builders, but if you aren't doing metaprogamming like that I find it quite annoying. – Godeke Jan 22 '09 at 22:34
  • 1
    (To be clear: the authors of the UI builder *are* doing meta programming, which makes the use of Partial excusable. I do a similar thing with a quote builder for our insurance product: we use partials in the code generation output for the calculation/display routines.) – Godeke Jan 22 '09 at 22:37
21

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.

Ryan Guill
  • 13,558
  • 4
  • 37
  • 48
8

1 class = 2 files. An .h and a .c, you kids are so lucky :)

Robert Gould
  • 68,773
  • 61
  • 187
  • 272
  • upvote :) Unless you're writing a template class or want everything inlined. – Scott Langham Jan 22 '09 at 17:05
  • You think that's bad, .Net lets you use as many files as you want, through the magic of partial classes. Web pages classes by default have 3 files. – Kibbee Jan 22 '09 at 17:13
  • LOL, but I thought .h and .c are for C (which doesn't have classes), whereas the C++ convention is .hpp and .cpp – Dónal Jan 22 '09 at 17:19
  • Kibbee, you can do the same in C++ by putting #includes in awkward places. Doesn't mean you should. –  Jan 22 '09 at 20:14
5

There is no hard and fast rule that must always be followed (unless a particular language enforces it). There are good reasons for having just one class, or having multiple classes in a file. And it does depend on the language.

In C# and Java people tend to stick to one file per class.

I'd say in C++ though I often put multiple classes in one file. Often those classes are small and very related. Eg. One class for each message in some communications protocol. In this case a file for each would mean a lot of files and actually make maintenance and reading of the code more difficult than if they were in one file.

In C++ the implementation of a class is separate from the class definition, so each class { /body/ } is smaller than in other language and that means classes are more conveniently sized for grouping together in one file.

In C++ if you're writing a library (eg the standard template library) , you can put all the classes in one file. Users only need to include the one header file and they get all the classes then, so its easier for them to work with.

There's a balance. The answer is whatever is most easy to comprehend and maintain. By default it makes sense to have one class per file, but there are plenty of cases when it's more practical to work with a related set of classes if they are defined in one file.

Scott Langham
  • 58,735
  • 39
  • 131
  • 204
  • I like how your answer considers both sides of the issue. However, it is possible to obtain the best of both worlds in C++, by including several header files in a single file which users can include. In fact, GNU's standard library makes heavy use of this technique. – Jørgen Fogh May 05 '14 at 11:52
  • @Jørgen Fogh I'm not sure that is the best of both worlds! If you've got lots of little classes in one file, that's only one file you need to work with. If you put all the classes in separate files and use many includes, you suddenly have more work managing and navigating between those files if you want to edit them, and you need to keep all the includes in sync! I guess if you consider only from the perspective of the the user of the classes, your method might be easy, but it will be more work for the author of the classes. Consider both the user and author. :) – Scott Langham May 06 '14 at 12:01
  • True. It depends on the context. For the standard library, only the users should be considered, since there are so many users compared to the number of library maintainers. In other situations the trade-off may be different. – Jørgen Fogh May 06 '14 at 12:24
3

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 like applib.PluginManager rather than applib.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.

  • 1
    I find that for Python, particularly, you want closely related classes in the same file. This is because Python's import mechanism can get migraines if two different files both need to depend on each other, because they contain classes that are interdependent. Other languages work better with the one-class-per-file approach. Java, of course, enforces this approach, at least for public classes. – Dan Menes Nov 11 '10 at 13:31
2

One class = one file. Always. Apart from when one class = multiple files in C#, or a class contains inner classes etc of course ;)

David Arno
  • 42,717
  • 16
  • 86
  • 131
2

One per a file is our standard. The only exception is that for a class and it's typed collection we put those together.

Over time I've come to relize, that "small class" always tend to grow. And then you'll want to split them up, confusing everyone else on the team (and your self).

Glennular
  • 17,827
  • 9
  • 58
  • 77
2

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.

Lucas Jones
  • 19,767
  • 8
  • 75
  • 88
1

One class per file seems to be the standard. This is the way that I usually do it as well.

There have been a few times where I've strayed away from this. Particularly when a smaller class is a member of another class. For example, when designing a data structure, I would likely implement a "node" class within the same file as the "bigstructure" class.

Matt Flowers
  • 800
  • 9
  • 12
0

In your object-oriented language, what guidelines do you follow for grouping classes into a single file?

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 ...

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?

No. Sometimes. Yes.

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?

It's mostly based on:

  • How easy is it to navigate? A huge long source file, with many classes, is more difficult.
  • How easy is it to edit? When editing multiple, short, related classes, it may be easier if they're all in one source file with a splitter than if they're in several source files, given that I run my text editor maximized showing one source file at a time.
ChrisW
  • 54,973
  • 13
  • 116
  • 224
0

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.

Chris Nava
  • 6,614
  • 3
  • 25
  • 31