Related
I've recently been toying with the idea of using extension methods to implement helper utilities on classes which I control (ie, are in the same program and I can modify). The rationale behind it is that many times, these helper utilities are used in very specific scenarios and don't require access to the classes internal values.
For instance, let's say I have a StackExchange class. It'd have methods like PostQuestion and Search and AnswerQuestion.
Now, what if I wanted to manually calculate my reputation to ensure that StackOverflow isn't cheating me. I'd implement something along the lines of:
int rep=0;
foreach(var post in StackExchangeInstance.MyPosts)
{
rep+=post.RepEarned;
}
I could add a method to the StackExchange class, but it doesn't require any internals, and it is only used from one or two other portions of the program.
Now imagine if instead you had 10 or 20 of these specific helper methods. Useful in a certain scenario for sure, but definitely not for the general case. My idea is changing something like
public static RepCalcHelpers
{
public static int CalcRep(StackExchange inst){ ... }
}
To something like
namespace Mynamespace.Extensions.RepCalculations
{
public static RepCalcExtensions
{
public static int CalcRep(this Stackexchange inst){...}
}
}
Note the namespace. I'd ideally use this to group extension methods within a certain scenario. For instance, "RepCalculations", "Statistics", etc.
I've tried searching for if this type of pattern is at all heard of, and haven't found any evidence of extension methods being used for anything but classes you can't modify.
What shortcomings are there with this "pattern"? Should I instead stick to inheritance or composition, or just a good ol' static helper class for this?
I would read the section of Framework Design Guidelines on Extension methods. Here is a post by one of the authors for the 2nd edition. The use case you are describing
(specialized helper methods) is cited by Phil Haack as a valid use for extension methods with the drawback that it requires extra knowledge of the API to find those "hidden" methods.
Not mentioned in that post but recommended in the book is that the extension methods go into a separate namespace from the extended class. Otherwise, they will always appear with intellisense and there is no way to turn them off.
I think I have seen this pattern somewhere else. It could quite confusing, but also quite powerful. That way you can provide a class in a library and a set of extension methods in separate namespace. Then whoever is using your library can choose to import namespace with your extension methods or provide their own extension methods.
A good candidate for this pattern would be if you have some extension methods used for unit testing only (e.g. to compare if two objects are equal in a sense you'd need for unit tests only).
You seem to be making the comparison that the extension method is equivalent to a public instance method. It's really not.
An extension method is just a public static utility method that happens to have a more convenient syntax for being called.
So first we have to ask ourselves, it it appropriate for this method to be an instance method of the class itself or is it more appropriate for it to be a static method of an external class. The fact that very few users of the class need this functionality because it's highly localized and not truly behavior that the class itself performs but rather behavior performed on the class by an external entity means that it's appropriate for it to be static. The primary drawback is that it's behavior that is potentially harder to find if someone has a User and wants to recalculate their rep. Now, in this particular case it's a bit on the fence, and you could go the other way, but I am leaning towards static method.
Now that we've decided it should be static it's an entirely separate question of whether or not it should be an extension method or not. This is much more subjective and goes into the personal preference realm. Are the methods likely to be chained? If so, extension methods chain much more nicely than nested calls to static methods. Is it likely to be used a lot in the files that do use it? If yes, extension methods are likely going to simplify the code a bit, if not, it doesn't really help as much, or even hurts. To the toy example I'd probably say that I personally wouldn't, but I wouldn't have any problem at all with someone who did (after all you can still use an extension method as if it's a regular public static method syntax wise). For a non-toy example, it's mostly a case-by-case decision. A key point is to be careful what classes you extend, and to ask yourself if a user is willing to clutter the Intellisense of a type just to call a methods slightly more conveniently (this again gets back to how much it's used per file it's used in).
It's also worth mentioning that there are a few edge cases where extension methods can be more powerful than instanced methods. In particular through utilizing type inference. With a regular instance method it's easy enough to accept a type or any sub-type of that type, but sometimes it's useful to return whatever the type is that was passed in instead of the parent type. This is used particularly in fluent APIs. This isn't a very common example though, and is only loosely related to your question, so I won't expand on that.
Extension methods could be very useful in cases where you class implements an interface and you want to avoid having to implement the same method on other "future" classes that implement the same interface. For example, StackExchange implements IStackExchange and ProgrammersExchange also implements IStackExchange. Your example extension method would be useful for implementing the CalcRep just once, and not having to re-implement it on both classes. This is exactly the reason for all the extension methods present in the static Enumerable class.
Other than this I dont see a compelling reason for using extension methods on a class you can already modify. If anything it has the disadvantage of being considered late in the overload resolution process.
I have 2 forms and 1 Class.
I made the class a Static Class.
It has two methods with public modifiers.
Ex: Public string PrintHello(), Public void Task1()
I want these methods to be accessible from both Form1 and Form2.
I understand that using "Public" modifier is not good, so I've looked at "Internal" modifier and it seems to do the job.
Basically, I want to create a secure way of accessing my class.
What would be the best way of doing so and could you provide an example of how to do so ?
Thank you
Access modifiers does not provide security to you code.
Is someone really wants to use your privet methods he can use ILDASM to de-compile your code and use them, that would be just one example of many.
Access modifiers are there to to allow you to program using with an Object Oriented code design.
In general:
Private modifiers are internal to your class implementation and other classes or layers of your code dose not NEED nor want to know about there existence.
Internal modifiers are there to provide additional functionality required for the whole assembly but again they are not required for any one else (outside of the assembly) because they are implementation specific.
And finally Public modifiers are used to define the interface of your class with the outside world, these are methods and properties that should and will be used by any one that requires some sor of functionality from your code.
Depends on where you think the code that calls this methods will likely live. If it is only going to be ever called from the class that defined this method, then it should be private. If you only want to call it from the same assembly (dll) but you don't want to call the methods from other dlls, then you should make it internal. This way you can ship your dll to other projects and you don't have to worry about supporting your methods (because they won't have access to your methods).
But if you are doing a general purpose libarary/dll etc. Then the methods should be public.
It all depends on who or what you think is going to call your methods.
Are there rules of thumb that help determine which to use in what case? Should I prefer one over the other most times?
Thanks!
Extension methods are useful, but they are harder to discover through the IDE than regular methods, since they are not attached to the original class and there are no clues as to where the code for them might reside. There are some best practice suggestions as to where to put them and how to name them, but these are only guidelines and there is no guarantee that someone will follow them.
Usually you would use extension methods if you are only adding functionality to a well known, well used class or interface such as the .Net base classes, that you don't have access to the code for. Extension methods also have the constraint in that you not only have to have the original assembly, you have to have the assembly with the extension methods in it, which must be understood by consumers of your code.
Using inheritance will allow you to add, remove or override functionality, and ensure that it is always present with the class when you build it.
Extension methods should be used when you want to provide an implementation across a variety of types that should share the same behavior, but would otherwise be disimilar. That's why you see extension methods being used on interfaces a lot, because it's a very powerful tool to ensure that any given implementation of an interface will have the same implementation of a given behavior.
For example, the Skip and Take extension methods.
Well... you can't always use inheritance. String, for example, is a sealed class. It's in those cases where an extension method really shines.
In general, extension methods are best for little utilities that you might otherwise put into a static class, but that operate against an instance of a particular type. Strings are a great example -- almost everyone has their own little string extension methods to do little operations on a string.
Another great place for extension methods is against enumerations. I almost always include a HasFlag extension method against any [Flags] enumerations I create.
Whenever possible, use inheritance instead of extension methods.
edit
I prefer to keep this short and simple, but I will of course answer follow-up questions.
In the cases where inheritance is possible, which is to say classes that are not sealed, it is almost always a better option than extension methods. In fact, this is what the best practices document that womp referenced says. It has headings such as "Be wary of extension methods", "Think twice before extending types you don't own", and "Prefer interface extensions over class extensions". In other words, it just says what my one-liner did, with greater detail.
The article does give detailed reasons, but the bottom line is that this is how extension methods were designed to be used. They were added to the language late in the game as a bit of syntactic sugar to allow MS to wedge in LINQ without having to go back and reinvent the wheel. This is the canonical example of what they are good for. Another good example is adding utility methods, such as:
public static string FormatWith(this string format, params object[] args)
{ return string.Format(CultureInfo.InvariantCulture, format, args); }
Note that, in this case, extension methods were the only way to accomplish this additional feature, since strings are sealed.
As for composition over inheritance, while this is a truism, I fail to see the relevance here. Whether we're using extension methods or inheritance, the goal is to change the interface to allow another method. How this method is implemented, whether by composition, generics or some other technique, is orthogonal.
They are very different, for example LINQ standard query operators are great example of extension methods that should be difficult to implement with inheritance, but if you have access to class and can change source it will be better to use inheritance,EDIT and here is some rules that I find here C# 3.0 Features: Extension Methods
Extension methods cannot be used to override existing methods
An extension method with the same name and signature as an instance method will not be called
The concept of extension methods cannot be applied to fields, properties or events
Use extension methods sparingly....overuse can be a bad thing!
I would stick to inheritance except in the cases that extension methods were primarily designed for - extending sealed classes or creating scope-specific extensions. Also remember that they are static, so if these are methods and behaviours that you would need to override in other classes, you can't really use extensions.
Extension methods do have one really great feature that is an inherent benefit of their implementation. Since they are static methods, you can call them on a null object.
For instance:
string a = null;
return a.IfNullOrEmpty("Default Value");
Implementations like this are great, though they are technically just syntactical sugar. IMHO, anything that keeps your code cleaner and more readable is great.
Though I don't like that they aren't really discoverable. If I copy that code from one class to another, i would then have to search for the namespace in which it was defined.
It really depends on the problem you need to solve, in most situations class inheritance and interfaces make naturally more sense than extension methods and thus should be preferred.
On the other hand, Extensions allow you to create useful methods applying not just to one class - which would otherwise be much more cumbersome to do with inheritance, if not almost impossible to achieve.
Last but not least, Extensions allow you to extend .NET Framework's builtin classes as well as 3rd party classes, even if you don't own or have no access to the sourcecode.
Here are some examples where extension methods are used for good reasons:
LinqPad uses extension methods, for example the .Dump() method with which you can dump (print) the contents of every kind of object to the output window.
The .NET framework itself uses extension methods in many places, for example in Linq:
public static TSource FirstOrDefault<TSource>(this
System.Collections.Generic.IEnumerable<TSource> source)
which returns the first element or default of any enumerable collection of any object type.
An example, where extension methods are better than inheritance is the following:
Say you want to create a method which is able to create a clone (copy) of any existing object. With Extensions (and generics, plus reflection) you can do it this way.
Extension methods break good OO design. To say they should be used on sealed classes that you do not have access to the code base is ridiculous. Classes that are sealed and you do not have access to are probably sealed for a reason (performance, thread safety) and to tag functionality blindly to these classes is down right dangerous. There is always a way of implementing the decorator pattern in a pure OO way and to not do it that way makes the code harder to read, maintain and refactor. As a rule of thumb, if a feature of a language smells bad then it should be avoided. I'm sure you could find one example where extension methods are useful however the truth is that the feature will be abused by those developers with minimal OO training.
MSDN
In the page on extension methods in the C# programming guide it says:
General Guidelines
In general, we recommend that you implement extension methods sparingly and only when you have to. Whenever possible, client code that must extend an existing type should do so by creating a new type derived from the existing type. For more information, see Inheritance (C# Programming Guide).
When using an extension method to extend a type whose source code you cannot change, you run the risk that a change in the implementation of the type will cause your extension method to break.
I'm working with a 3rd party c# class that has lots of great methods and properties - but as time has gone by I need to extend that class with methods and properties of my own. If it was my code I would just use that class as my base class and add my own properties and method on top - but this class has an internal constructor. (In my opinion it was short sited to make the constructor internal in the first place - why limit the ability to subclass?)
The only thing I could think of was to create method / properties on my class that simply called into theirs - but it's acres of code and, well, it just doesn't "feel" right.
Is there any way to use this class a base class?
You ask: "Why limit the ability to subclass?"
Because designing for inheritance is tricky, particularly if you're designing for other developers to inherit from your class. As Josh Bloch says in Effective Java, you should design for inheritance or prohibit it. In my view, unless you have a good reason to design for inheritance, you shouldn't do so speculatively.
Does the class implement an interface which you could also implement (possibly by proxying most calls back to an instance of the original)? There's often no really elegant answer here - and the best solution will depend on the exact situation, including what you're trying to add to the class.
If you're not adding any more state - just convenience methods, effectively - then extension methods may work well for you. But they don't change what data an object is capable of storing, so if you need to add your own specialised data, that won't work.
Sounds like a perfect application for extension methods:
MSDN extension method docs
"Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type. For client code written in C# and Visual Basic, there is no apparent difference between calling an extension method and the methods that are actually defined in a type."
If the class has an internal constructor, and there are no public constructors, then that suggests that the designers did not intend for it to be subclassed. In that case, you can use encapsulation, or you can use extension methods.
Only if your class lives in the same assembly as the class you want to inherit from. An internal constructor limits the concrete implementations of the abstract class to the assembly defining the class. A class containing an internal constructor cannot be instantiated outside of the assembly.
Resharper has a nice feature to create delegating members.
Here is a sample of what you can do with it. It takes a couple of seconds.
I will not discuss whether you can build your own Facade around that 3rd party class. Previous authors are right, the library could be designed in the way that will not allow this. Suppose they have some coupled classes that have singletons that should be initialized in specific order or something like this - there may be a lot of design mistakes (or features) that 3rd party developers never care about, because they do not suppose that you will use their library in that way.
But OK, lets suppose that building a facade is not an impossible task, and you have in fact only one problem - there are too many methods you have to write wrappers around, and it is not good to do this manually.
I see 3 solutions to address exactly that problem
1) I suppose that new "dynamic" types of .NET 4.0 will allow you to workaround that problem without having to write "acres of code"
You should incapsulate an instance of 3rd party class into your class as a privare member with dynamic keyword
Your class should be derived from Dynamic or implement IDynamicObject interface. You will have to implement GetMember/SetMember functions that will forward all calls to the encapsulated instance of 3rd party class
Well, c# 4.0 is a future, Let's see on other solutions:
2) Do not write code manually if you have significant number of public methods (say more then 100). I would write a little console app that uses reflection and finds all public members and then automatically generates code to call encapsulated instance. For example
public type MethodName(params)
{
this.anInstanceOf3rdPartyClass.MethodName(params);
}
3) You can do the same as 2, but with the help of existing reflection tools, for example RedGate .NET Reflector. It will help you to list all classes and methods signatures. Then, paste all this in Word and a simple VB macro will let you generate the same code as you could do in 2.
Remark: As soon as you are not copying the code, but only copying method signatures, that are publicly available, I don't think you will violate the license agreement, but anyway it worth to re-check
I am developing a set of classes that implement a common interface. A consumer of my library shall expect each of these classes to implement a certain set of static functions. Is there anyway that I can decorate these class so that the compiler will catch the case where one of the functions is not implemented.
I know it will eventually be caught when building the consuming code. And I also know how to get around this problem using a kind of factory class.
Just curious to know if there is any syntax/attributes out there for requiring static functions on a class.
Ed Removed the word 'interface' to avoid confusion.
No, there is no language support for this in C#. There are two workarounds that I can think of immediately:
use reflection at runtime; crossed fingers and hope...
use a singleton / default-instance / similar to implement an interface that declares the methods
(update)
Actually, as long as you have unit-testing, the first option isn't actually as bad as you might think if (like me) you come from a strict "static typing" background. The fact is; it works fine in dynamic languages. And indeed, this is exactly how my generic operators code works - it hopes you have the static operators. At runtime, if you don't, it will laugh at you in a suitably mocking tone... but it can't check at compile-time.
No. Basically it sounds like you're after a sort of "static polymorphism". That doesn't exist in C#, although I've suggested a sort of "static interface" notion which could be useful in terms of generics.
One thing you could do is write a simple unit test to verify that all of the types in a particular assembly obey your rules. If other developers will also be implementing the interface, you could put that test code into some common place so that everyone implementing the interface can easily test their own assemblies.
This is a great question and one that I've encountered in my projects.
Some people hold that interfaces and abstract classes exist for polymorphism only, not for forcing types to implement certain methods. Personally, I consider polymorphism a primary use case, and forced implementation a secondary. I do use the forced implementation technique fairly often. Typically, it appears in framework code implementing a template pattern. The base/template class encapsulates some complex idea, and subclasses provide numerous variations by implementing the abstract methods. One pragmatic benefit is that the abstract methods provide guidance to other developers implementing the subclasses. Visual Studio even has the ability to stub the methods out for you. This is especially helpful when a maintenance developer needs to add a new subclass months or years later.
The downside is that there is no specific support for some of these template scenarios in C#. Static methods are one. Another one is constructors; ideally, ISerializable should force the developer to implement the protected serialization constructor.
The easiest approach probably is (as suggested earlier) to use an automated test to check that the static method is implemented on the desired types. Another viable idea already mentioned is to implement a static analysis rule.
A third option is to use an Aspect-Oriented Programming framework such as PostSharp. PostSharp supports compile-time validation of aspects. You can write .NET code that reflects over the assembly at compile time, generating arbitrary warnings and errors. Usually, you do this to validate that an aspect usage is appropriate, but I don't see why you couldn't use it for validating template rules as well.
Unfortunately, no, there's nothing like this built into the language.
While there is no language support for this, you could use a static analysis tool to enforce it. For example, you could write a custom rule for FxCop that detects an attribute or interface implementation on a class and then checks for the existence of certain static methods.
The singleton pattern does not help in all cases. My example is from an actual project of mine. It is not contrived.
I have a class (let's call it "Widget") that inherits from a class in a third-party ORM. If I instantiate a Widget object (therefore creating a row in the db) just to make sure my static methods are declared, I'm making a bigger mess than the one I'm trying to clean up.
If I create this extra object in the data store, I've got to hide it from users, calculations, etc.
I use interfaces in C# to make sure that I implement common features in a set of classes.
Some of the methods that implement these features require instance data to run. I code these methods as instance methods, and use a C# interface to make sure they exist in the class.
Some of these methods do not require instance data, so they are static methods. If I could declare interfaces with static methods, the compiler could check whether or not these methods exist in the class that says it implements the interface.
No, there would be no point in this feature. Interfaces are basically a scaled down form of multiple inheritance. They tell the compiler how to set up the virtual function table so that non-static virtual methods can be called properly in descendant classes. Static methods can't be virtual, hence, there's no point in using interfaces for them.
The approach that gets you closer to what you need is a singleton, as Marc Gravell suggested.
Interfaces, among other things, let you provide some level of abstraction to your classes so you can use a given API regardless of the type that implements it. However, since you DO need to know the type of a static class in order to use it, why would you want to enforce that class to implement a set of functions?
Maybe you could use a custom attribute like [ImplementsXXXInterface] and provide some run time checking to ensure that classes with this attribute actually implement the interface you need?
If you're just after getting those compiler errors, consider this setup:
Define the methods in an interface.
Declare the methods with abstract.
Implement the public static methods, and have the abstract method overrides simply call the static methods.
It's a little bit of extra code, but you'll know when someone isn't implementing a required method.