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 6 years ago.
Improve this question
I want to create many Service classes that use a common set of functions. All these classes will inherit ClientBase class which is provided by Microsoft. Currently I have written those common functionalities as private methods in class. What is the best way to do it to avoid code repetition and efficiency. I cannot add those common methods to base class as it cannot be modified.
Have your own abstract base class that inherits ClientBase<T>, call it MyClientBase<T>, move the common methods to it and make them protected so that successors could access them. Then make your service classes inherit MyClientBase<T>.
If all other classes are directly inheriting from ClientBase<T>I would try to define the additional functionalities via extension methods of ClientBase<T>.
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 20 hours ago.
Improve this question
I need peace of advice. In .net we use extension methods to extend the functionality of our types.
These static methods look good to me when they are simple and clear. Sometimes I create private static methods to encapsulate some hidden logic. But I thought to create a class (internal to have logic within a single assembly) and put all private methods inside it (making public) to reduce static private methods from the extension.
My question is, what is the best practice or what is the proper way to write extensions from clean code and performance perspective - should I leave private static methods within the extension class or create an internal class and put logic into it?
I have 5 static private methods. I can leave them in extension class or put in separate internal class.
Not sure what is better.
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 1 year ago.
Improve this question
I've got two types of users, both have the same properties but each one will be able to do specific operations. Can I have the same class for both type of users and implement different interfaces for each role or should I use inheritance instead ?
For example: class User implements IBuyer and ISeller.
yes you could but, why wouldn't you have two different user classes? Like, class Buyer implement IBuyer and class Seller implement ISeller, I think that would make your code clearer. You could also add a class User with the basic properties they both share, even if they are all of them as you said, which implements an interface called IUser with the shared methods it could have and then your classes Buyer and Seller could inhered from User and have their own separated and independent methods. Anyway, yes, what you commented is possible as well.
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 6 years ago.
Improve this question
I have an entity that contains a list of claims (System.Security.Claims.Claim, MS-docu). Serialization works all fine but when it comes to deserialization I am stuck because of the following exception:
Raven.Imports.Newtonsoft.Json.JsonSerializationException : Unable to find a constructor to use for type System.Security.Claims.Claim. A class should either have a default constructor, one constructor with arguments or a constructor marked with the JsonConstructor attribute.
Since this is not my own class I cannot simply add a default constructor, remove all but one constructor or add the JsonConstructor attribute.
Is there any way to tell ravendb/Newtonsoft.Json what constructor to use by e.g. adding a convention for this particular datatype?
If this should not be possible, what would be the best approach? Options that came to my mind:
Add a custom JsonConverter for this datatype
Create a wrapper for the Claims class and hide all but one constructor
Create a custom Claim class and convert it later to MS-Claims
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
i used an interface class and make an object from that class (having method with return type void). now that object has too many information and i want to get only some required information .
interface:
public interface Iclass
{
void OnEventReceived(event ev);
}
now that object has too many information and i want to get only some required information
This means that your design is wrong. You have polluted the interface with some un-necessary methods/or methods that should have been a part of some other interface. You should re-consider your design and breaking the interface to multiple interfaces. So that your classes implement only the required interface.
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.