Click here to Skip to main content
15,879,535 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
Hi all,
years ago I used C# under VS2008 and I remember there wasn't a way to separate class definitions and their implementations in different files (similarly to what we're used to do in C and C++ with header and source files).

Does anybody know if new versions of the language allow for this completely reasonable behaviour? Excluding the creation of interfaces, which are a tool for other very specific situations.

Thanks

What I have tried:

I Binged far and wide but the results are what we all expect from a joke of search engine. Google and the rest of the web aren't accessbile from the reich company's network.
Posted
Updated 10-Jan-17 5:11am

I think you're referring to "partial" classes.

You can spread code among several files and still be in the same class.
 
Share this answer
 
v2
Comments
den2k88 10-Jan-17 11:21am    
Yes I knew them but they still keep together declaration and implementation. IMHO I'd end up hating them because instead of having a big book and an index (c and c++ way) I would end up with several booklets and no index whatsoever (partial classes).
As far as I know, not completely the same way as in C but you could achieve same kind of behaviour with abstract classes and methods. However, you'd need to tell the derived class from which base class it's inherited from so it's not that free.

Also you could use partial classes which are stored in different files but then each partial class only brings new features to already existing definition...

Depending on what you're after, perhaps MEF could be what you need? Have a look at Managed Extensibility Framework (MEF)[^]
 
Share this answer
 
Comments
den2k88 10-Jan-17 11:20am    
It's not MEF that I need (though I'll bookmark it for future needs, thanks), the whole reasoning is under OG solution. I just like to split what to expect from how it is implemented, it's a way to have better documented code (i.e I explain what a class does and the logic of it in the header, then the gory details and suggestion for a better code in the implementation. Less clutter).
Wendelius 10-Jan-17 12:14pm    
Yes I see, using abstract classes would create kind of an index but I think it's an overkill because of the cost of inheritance (which somewhat also applies to interfaces)...

I'm still wondering if partial classes are good since you cannot define the same thing twice (in different files). The compiler simply merges the files and then compiles. If you for example have the same property defined in both files you get an error.

Anyhow, if you're interested, have a look at Multiple partial definitions for a class[^]
Well, you could use partial classes, which allow you to split a class between files - the Visual Studio designer uses this to separate the design code from your code.
But... C# doesn't really have an definition which is massively separate from the implementation, not in the way that C required all functions to be declared in prototype before they were used, and there is no concept of "global variables" in C#, so (with the exception of Interfaces and abstract classes) there isn't really anything to put into a "definition file".
You could put const and readonly items in a separate file, but TBH you are probably better off using regions to "collapse" such items and separate them that way.

Or am I completely miles away from what you are trying to do?
 
Share this answer
 
Comments
den2k88 10-Jan-17 11:17am    
I normally use the header file to describe what to expect from a class, an index which me and my coworkers look and know instantly that this class has these methods, exposes those properties and defines these data types. If it's a derived class then it adds these methods and overrides these others. Then in the implementation file there are the gory details over which regions are useful and so on.

Partial classes are useful but still blocks comprising of both definition and implementation - there has been only a single instance in which I would have liked them in C++ though, splitting the implementation may lead to a bigger mess than before.

I guess I'll have to use interfaces for the needs I have but correct me if I am wrong, interfaces cannot declare nested types and data members, don't they?
OriginalGriff 10-Jan-17 12:34pm    
No, C# doesn't allow you you to declare anything concrete inside an Interface - it's just a contract, after all - and there is no mechanism to "force" you to implement a nested class (which would have to be a nested interface, I guess) so it's fraught with runtime nasties! :laugh:
I have always considered this completely unreasonable. Why would anyone want to have the definition of classes and methods in separate files so any change in one has to be also made in the other? At least the writers of Java and C# realised how ridiculous it was, and created compilers that only need a single definition.
 
Share this answer
 
Comments
den2k88 10-Jan-17 11:26am    
Most of the times the definition needs no change whatsoever. By having them separated it's fairly easy to check if different versions of the same software share the same interface to the class (single software with hundreds of branches tailored to the customers, each branch possibly coming from different versions of the base software).

One thing is the interface, the other is the code. While Interfaces solve the problem they are actually a tool thought for other purposes (defining precisely what a class MUST DO to fulfill its end of the "contract") instead of giving a quick summary of what operation does the class do, which operations are accessible from the outside world and which data does it hold.
Richard MacCutchan 10-Jan-17 11:52am    
Yes, but you were not talking about interfaces, which is a totally different issue.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900