Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I just am a bit confused regarding what is right and wrong or rather what is the recommeded practice.
I have a class file A.cs which contains an abstract class.
I want other classes which would be located in other Dlls to reference to this class.
Hence what is the recommended practice?
Do i create a dll which contains this class and other dll's would reference this dll.
Or do i include this class file in every dll so that references are set correct (considering all dll projects reference this cs file from same location)
What is the recommended practice? What are pros and cons of same?
Think of your Object Orientated design principles. SOLID and DRY.
Write it once and reuse it.
As for where the code resides i.e. in which assembly, it's really down to how you organise your code. Does this piece of code need to be used only by code in this assembly? Does it need to be shared with others?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have been working on a project in Unity, and was trying to figure out how to abbreviate a large number into a more readable format. I found somebody who asked the same question and got some code, but the person who gave that code had 2 classes in the same C# script. I am new to Unity and C# in general, so this was not something I had seen before.
What I would like to know is when to put classes in different scripts, when to put multiple classes in the same script, and if I do put multiple classes in the same script how that affects that script and other scripts in the project.
From a C# logical point of view, it does not matter where a class is. From the practical perspective, it is usual to put every type (class, struct) in its own code file. I often make an exception for enums and put enums belonging to the same realm into the same file, e.g. things like DisplayStyle, SortOrder, Visibilty could be in a file named AppearanceEnums.cs. Enums are mostly small and don't contain logic.
for Unity, see: How to architect code as your project scales
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
i am now developing a c# solution with 5 projects.
When i created the project under the solution, each project has its own namespace. My question is should i unify the namespaces using the solution namespace to avoid any scope problems later ?
Besides, i have a project for the Win Forms and using folders under it (to organize the forms). Each folder has several form.
When i want to use the form, i found that i have to mention the folder also.
What should i do then ?
Namespace is not related to the project structure but it is good habit follow the project structure. This make orientation in code much better. There is no need to unify namespace from scope reason. It should mirror your logical project layout. eg. your namespace can start with company (or product) name and than follow with component and then follow with your structure:
MyProduct.DataLayer
MyProduct.UI
MyProduct.Tools
MyProduct
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Assuming I was writing my own version of .Net :)
What would be the downside of such a setup?
Yes, I am talking about a new anti-pattern here to avoid creating endless tuples and EventArgs. I think such a setup would have made coding a lot cleaner.
No. The Tag property has history, it was important in VB6 and Winforms was meant to replace it. It needed to be added to make porting code relatively simple.
It is entirely unnecessary in .NET. It supports implementation inheritance, a feature that VB6 didn't have. So if you want to add extra properties then you just derive a class and add them. And you'll be able to give them a good name and a type so you don't have to cast every time you read the property. This works just as well with Winforms controls.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
due to unit-testing we create for every class an Interface. The .Net Framework coding standards say that every class, interface, enum, etc. should be located in a different file.
As these interfaces are so closely related with the class we were thinking of creating an internal coding-standards rule to put together the class and the interface.
Have you seen this approach before? What do you think about it?
PD: Always talking about interfaces used only to mock the classes, not 'real' interfaces that can have more than one implementation.
You should follow .NET coding standards and separate the interfaces into their own files. You could create a folder Interfaces within your project. I usually have Concrete, Abstract and Interfaces folders within my projects.
Developers who may be unfamiliar with your solution will have a hard time finding interfaces if they are in class files.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have a program that I am making for a friend and I don't want him to see the whole code, but I want him to be able to add classes that have attributes on the classes so he can add his own stuff to it, how would I be able to get classes using a compiled program and add them to the dictionary of methods to be called upon later?
Use MEF.
The Managed Extensibility Framework or MEF is a library for creating
lightweight, extensible applications. It allows application developers
to discover and use extensions with no configuration required. It also
lets extension developers easily encapsulate code and avoid fragile
hard dependencies. MEF not only allows extensions to be reused within
applications, but across applications as well.