The language I use is C#.
I have a problem of architectural nature. Let Class A has the following form:
Class A
{
Class B
{
// properties goes here.
}
Class C
{
// properties goes here.
}
Class D
{
// properties goes here.
}
....
private ClassA methodX
{
// code goes here
}
private ClassB methodY
{
// code goes here
}
private ClassC methodZ
{
// code goes here
}
....
}
The classes B, C and D are classes that hold only properties. They don't express any behaviour through a public method. My problem about this approach is that the code of class A is too huge. So the future maintainance of class A will be difficult.
My question is should I remove the classes B, C and D to seperate files or should I leave them there as they are in class A?
Is there a better approach to handle the above problem?
One of my concerns, if I should put this code to separate files, is that I have also other classes like class A. So, there would be a significant increase in the number of files that my application has.
Thanks in advance for any help.
If you move them out of class A, into their own files and make them internal classes, this will achieve both keeping them private (with respect to other assemblies) and keep your classes at a more manageable size.
From experience, large numbers of files are not a problem as long as your classes are well named and the files are organised into sub-folders, with matching namespaces.
Related
I got for example two classes cross referencing each other. I want to compile these files to separate dll files.
File 1:
public class A
{
public B bObj;
public A ()
{
bObj = new B (this);
}
public void TestMethod()
{
}
}
File 2:
public class B
{
public B (A aObj)
{
aObj.TestMethod ();
aObj.bObj.CallMyself ();
}
public void CallMyself()
{
}
}
I want to be able to share only the parts of the project with other people that they are working on. They need to be able to test it out, so they have to compile to project. Is there any magic solution that can be easily automated? The solution should work on any file, I know how to resolve circular dependency with a 3rd assembly.
As I mentioned, I know how to resolve a situation like this. I just wrote a nasty example, to show that I want to create a solution that can deal with any code.
Compile B.dll with class B changed to remove dependency on A
Compile A.DLL with B.dll and class A depending on B
recompile B.DLL with complete class B
If interfaces of classes don't change you may be able to recompile just one without source of another.
Should you go this route - no.
The short answer is don't do this. In this situation, it's common to put common interfaces in a separate library that everyone can see, so they can program to those interfaces without affecting each other, and then put the private stuff in separate assemblies that rely on the first.
E.g.
// myproject.interfaces.dll
interface IA
{
void Process(IB b);
}
interface IB
{
void Process(IA a);
}
// myproject.A.dll - depends on myproject.interfaces.dll
class A : IA
{
....
}
This was a general question asked by a colleague of mine....
Is it possible to "outsource" code, and then call it in the main class (e.g. Form1.cs)?
This originates from the fact that he wants to organize his amount of code better than with regions, in the main class.
My first thought was - of course it is!
Use static Extentions, reference it to the main class, and call it through this.Method().
But he meant something like the "include" pattern in PHP....
Is that even possible?
he wants to organize his amount of code better than with regions, in the main class.
You can use partial classes to split the implementation of a single class into multiple (and perhaps more manageable) source files.
In File1.cs:
public partial class MyClass {
public void F() { ... }
}
In File2.cs:
public partial class MyClass {
public void G() { ... }
}
MyClass now has two methods, F and G.
You can externalize using partial classes or decouple it using c# assembly (dll).
I have 2 classes that have exact two functions. The difference between them is they modify the member variables of their own class.
class A
{
public hello;
public void methodA ()
{
// code to modify hello
}
}
class B
{
public hello;
public void methodB()
{
// code to modify hello
}
}
Method A and B do the exact same thing but to different hello (one in class A one in class B).
Is there any way I can avoid duplication here? I think probably delegate will be the answer, but I don't know how. Please give me guidelines, I am a student and still learning. Thanks beforehand.
EDIT: The reason the classes have the same functionality but are separate classes, is because one is in a Windows application, and the other in a console application.
If the classes share the exact same functionality, then they should be combined into one class. If you have to share this class among different applications, you can put this class into a separate assembly, and reference the assembly from both your Windows and console applications.
If we have the following situation:
namespace SomeNameSpace
{
public class Class1
{
private class NestedClass1
{
// NestedClass1 implementation
}
private class NestedClass2
{
// NestedClass1 implementation
}
}
public class Class2
{
// so on ...
}
}
What is the best way to organize folders and files for nested classes?
First of all, we have Folder "SomeNameSpace".
Then files "Class1.cs, Class2.cs, ...".
Consider nestes classes in "Class1".
Is it the right way to create files "Class1.NestedClass1.cs, ..." and place them in folder SomeNameSpace?
Or create new folder, then what name should it have, and may be it is not proper way because it looks like new namespace?
In general nested classes are somehow considered bad practice, but sometimes you do need them. Implementing a state pattern often is much easier if the states are nested classes that can access private methods of their context.
I tend to create separate files like Class.Subclass.cs if I have more than one nested class or one nested class that clutters the code of its parent class. In this case of course Class has to be declared partial.
Nevertheless this is just my personal opinion, do it as you/your team like it best.
Given your example, personally I would name them accordingly:
Class1.cs
Class1.NestedClass1.cs
Class1.NestedClass2.cs
Class2.cs
I've gotten to a point where my main code file is about a thousand lines long and it's getting un-manageable; that is, I'm starting to get confused and not know where to locate some things. It's well-commented but there's just too much stuff.
I'd really like to be able to organize my code into different files, each with its own purpose. I want to get all the help VS gives me as I type when I edit these other files. A picture can say a thousand words:
alt text http://img64.imageshack.us/img64/7848/codeorganizationscreens.png
Is what I'm trying to do even possible?
Yes, but you need to be in the same namespace and declare the class just like you did in the main file, an example:
file1.cs
namespace Names
{
public partial class Hello
{
public void DoSomething() { }
}
}
file2.cs
namespace Names
{
public partial class Hello
{
public void Go() { DoSomething(); }
}
}
Although what other people say about partial classes is true. I'd also suggest you to analyze refactoring opportunities on your class.
If you're having problems to manage it, you could try to split your single class in several classes with less responsibilities.
IMHO partial classes may not help very much. Do you have your class separated in regions? Regions improve the readability of your code.
Yes you can split any partial class across as many files as you like.
Strip out each decent size class into at least one file. Wrap each class in the same namespace.
For large classes use either:
a. Region blocks eg
#region // Members
int my_int;
// other members...
#endregion
b. partial keyword to break a single class accross several files.