Can something be initializable? - interface

I've created an interface called Initializable, but according to Dictionary.com this is not a word. Searching Google only gives about 30k results and they are mostly API references.
Is there another word to describe something that can be initialized (which is a word)?
Edit:
Thanks for the questions about it being in the constructor, that may be a better way. Right now they are static classes (as static as can be in Ruby) that get loaded dynamically and have some initilization stuff to do.

Technical people create new words all the time. (see example below) But this isn't a case of creating a new word. This is a case of a "derivation". You have take a perfectly good word ("initialize") and added a perflecty good derivative suffix to it ("able"). The resulting word initializable is a derivative word.
In short, if something can be initialized, it is initializeable. Just like it can be runable, or stopable.
Now, I don't think it will be long before a grammar Nazi points out the error of my ways here. But English is rich and expressive language. A word doesn't have to be listed on "dictionary.com" for it to be valid. Nor even on m-w.com (which I believe is a better site).
One of my favorite books is Garner's Modern American Usage. Its a great book and is more than a dictionary - it is a reference and guide on how American English is used.
"Atomic" is a good example of a word we use in software development all the time that is somewhat of a "made up" word. In a development context something that is atomic either happens, or does not happen - it cannot be divided into separate operations. But, the common definition for this word doesn't take this usage into account.
Bah! Here is a better one.... "Grep" Not in the dictionary - but yet, a perfectly good word. I use it all the time

How about -
interface ICanBeInitialized
or...(and I had a little xmas drinky...so sorry)
interface ICanHazInitialization

I think the question --- other than the pedantic one about the word, which I'll mention below --- is what the behavior you intend to identify by this "Initializable" tag might be.
It's not an uncommon style to write a private method init() in, eg, Java to do complicated initialization; since that code may be needed in several places (what with copy constructors, clone operations and so on) it's just good form. Its less common, but a valid thing to so, to have a "Forward" class that is constructed, but that is waiting for some asynchronous operation in order to be fully initialized (eg, the Asynchronous Completion Token pattern). So it's not necessarily so that this should be just in the ctor, but I'm curious what the actual behavior you want would be.
On the word, English is a somewhat agglutinating language, like German: there are grammatical rules that construct works from base words and ther syllables in patterns. one of those is the one here, "Initial" -> "initialize" => "initializable". Any native speaker will recognize "initializable" as something that has the property of being able to be initialized. So it is a value word, but one they don't have in the dictionary for the same reason that don't have separate entries for the plurals.

I see nothing wrong with making up a word for an API-like thing if the invented word is clear.
I think worse words than Initializable have been invented - such as 'stringize' and 'RAII' (I nkow it's not a word, but it's still a term that's used often, and makes me cringe every time - even though the concept is doubleplusgood).
The problem I might have with Initializable is that it sounds like an interface that does what a constructor should be doing.

If Google gives back API references for "Initializable", it seems to me like a valid name for an interface, even though it might not be a valid English word. There's nothing wrong with using a made-up word, as long as it's descriptive.
The only thing I get confused about is classes are typically able to be initialized through their constructor. How does your interface provide functionality not available through the use of a constructor? The answer to this question may provide a more descriptive name than simply "Initializable". (i.e. in what way is it initializable?)

If Initializable most clearly describes what the interface is about, I wouldn't care about trying to find another word just so it is a valid English word. As long as it's not a UI string, the priority should be in naming clarity not validity of the word in the English language.

Yes, it's fine. Programming terms don't have to be in the dictionary. Dictionary.com also doesn't like "Serializable", and we all know that one's OK.

Yes. Don't let the lack of an existing word spoil your creativity if the meaning is clear

For those questioning the use of initialize - you may want to put constructor logic in a void method so to avoid race conditions when constructing weakly coupled classes through factories.
Example Factory:
public static T CreateSingleInstance<T>(string providerName, string sectionName)
{
//create the key
ProviderKey key = new ProviderKey(providerName, typeof(T));
//check key
if (!_singletons.ContainsKey(key))
{
object provider = _singletons[key] = CreateInstance<T>(providerName, sectionName);
IInitializable initializableProvider = provider as IInitializable;
if (initializableProvider != null)
initializableProvider.Initialize();
}
return (T)_singletons[key];
}
Example Implementation Constructors that would cause a race condition
public class Class
{
public Class()
{
Factory.CreateSingleInstance<OtherClass>(null, null);
}
}
public class OtherClass
{
public OtherClass()
{
Factory.CreateSingleInstance<Class>(null, null);
}
}

To echo what other's have said, it's valid English since English, like many languages, is formulaic and you're just applying a valid linguistic formula. Looks like there's precedence in what you're doing. The SQL Server team thinks what you're doing is valid since they came up with the same IInitializable Interface (see here). It looks something like this:
public interface IInitializable {
public void Initialize (IServiceProvider serviceProvider);
}

Related

How to define a class whos only role is to perform an action

This is a question about the definition of a class.
Of course I have read the endless examples on the Internet of what should be called a class. I have read that it is all the verbs and nouns that make up a thing. I understand the concept of a car class with properties like size, colour, and methods like drive
I also understand the idea that a class should have only one responsibility and adhere to the other SOLID principles
My problem relates to a program I have developed.
The responsibility of the program is to extract all the similar words from a document. It is therefore not a 'noun' like a car or animal but a verb type class I suppose.
In order to do this the program iterates through a folder of text files, extracts all the text, splits the text up by line and then 20 characters, compares each of the chunks in one file to all of the others by similarity, keeps only the words that are similar between two files, cleans the words to get rid of various characters and then added the words to a text file and repeats this for all the files in the folder.
So I have one responsibility for the class and I have written methods for each of the phrases between the commas.
Having read more about class design then it could to me that some of these methods might be classes in their own right. If a class is defined by having a single responsibility then presumably I could define more classes instead of these methods. E.g. why don't I have a class to find word similarity with only one method....
So my question is how do I define a class on a single responsbility basis if a method also has a single responsibility and the class doesn't define a thing but more of an action. What are the boundaries of what defines a class?
Please no...'Have you read'...because I have read them all. A simple explanation with a well illustrated example (conceptual example is fine)
The term "single responsibility" is very nebulous. I find it much easier to think of it in terms of cohesion and coupling. In short, we have to get things that tend to change together (i.e. are strongly cohesive) into one class and things that don't (i.e. are loosely coupled) into separate classes.
In practice that means things that tend to work with the same "data" belong to the same class. This can be easily enforced if data does not leave the object. Even more pragmatically that means avoiding "getter" methods that return data from an object.
Regarding your problem. You're saying it's not a noun, but only because you don't think of it that way. What is your "business logic"? To collect SimilarWords from a Document. Both are nouns. Your phrases are all about what steps should be taken. Rethink your application in terms of what things are involved and what actions those things would be able to do for you.
Here is a short/incomplete design for the things you describe:
public interface Folder {
public SimilarWords extract();
}
Meaning: I want to extract SimilarWords from a Folder.
public interface TextFile {
public void chunk(Consumer<Chunk> chunkConsumer);
}
Meaning: TextFile chunks the text.
public class Comparison {
public Comparison(TextFile file1, TextFile file2);
public SimilarWords extract();
}
Meaning: Two TextFiles are compared where the SimilarWords come from. You didn't use the word "Comparison" explicitly, I made that up.
And of course SimilarWords need to be added together for all file pairs (?) and then written to some output:
public interface SimilarWords {
public SimilarWords add(SimilarWords other);
public void writeTo(OutputStream output);
}
So that would be a proper OO design. I didn't catch all the details of your domain, so this model may be not exactly what you want, but I think you get the point.
Let's think a little about both your problem, problems in general, and SRP.
SRP states that a class should be concerned with one thing. This doesn't mean exactly to have a single method that does only one thing.
Actually this can be applied outside OOP too: a function should do only a single thing.
Now imagine your program has to implement 200 features. Imagine they are so simple that a single function is enough to implement any feature. And suppose you are using only functions. By the same principle you have to write (at least) 200 functions. Now this is not so great as it looks. First you program structure looks like an endless list of micro-sized pieces of code. Second if they are micro-sized, they can't do much by themselves (this is not bad per see). As you suspected a feature doesn't usually map to a single function in real world. Third if they do almost nothing, they have to ask everything to someone else. Or someone is doing that somewhere else. So there is some place where a function, or a class, is calling all the others. That place centralizes a lot of knowledge about the system. It has to know about everything to be able to call everyone. This is not good for an architecture.
The alternative is to distribute the knowledge.
If you allow those functions or classes to do a little more, they ask less things to others, some of those things are solved locally. Let me guess. As all this classes are in the same application, some of them are related to each other. They can form a group and collaborate. Maybe they can be the same class, or inherit from others. This reduces communication paths. Communication becomes more local.
Comunication paths matter. Imagine there are 125 persons in your company, and the company needs to take collective decisions. Would you do a 125 people meeting, or you group people say in 5 groups, each with 5 teams of 5 people and have small meetings instead, and then the team and group leaders meet themselves? This is a form of hierarchy or structure that helps things.
Can you imagine the fan-in and fan-out in the new structure? 5/5/5 is much better than 1/125.
So this is about a trade-off. You are exchanging communication paths by responsabilities. What you want in the end to have a reasonable architecture, with knowledge distributed evenly.

Is the word "Helper" in a class name a code smell?

We seems to be abstracting a lot of logic way from web pages and creating "helper" classes. Sadly, these classes are all sounding the same, e.g
ADHelper, (Active Directory)
AuthenicationHelper,
SharePointHelper
Do other people have a large number of classes with this naming convention?
I would say that it qualifies as a code smell, but remember that a code smell doesn't necessarily spell trouble. It is something you should look into and then decide if it is okay.
Having said that I personally find that a name like that adds very little value and because it is so generic the type may easily become a bucket of non-related utility methods. I.e. a helper class may turn into a Large Class, which is one of the common code smells.
If possible I suggest finding a type name that more closely describes what the methods do. Of course this may prompt additional helper classes, but as long as their names are helpful I don't mind the numbers.
Some time ago I came across a class called XmlHelper during a code review. It had a number of methods that obviously all had to do with Xml. However, it wasn't clear from the type name what the methods had in common (aside from being Xml-related). It turned out that some of the methods were formatting Xml and others were parsing Xml. So IMO the class should have been split in two or more parts with more specific names.
As always, it depends on the context.
When you work with your own API I would definitely consider it a code smell, because FooHelper indicates that it operates on Foo, but the behavior would most likely belong directly on the Foo class.
However, when you work with existing APIs (such as types in the BCL), you can't change the implementation, so extension methods become one of the ways to address shortcomings in the original API. You could choose to names such classes FooHelper just as well as FooExtension. It's equally smelly (or not).
Depends on the actual content of the classes.
If a huge amount of actual business logic/business rules are in the helper classes, then I would say yes.
If the classes are really just helpers that can be used in other enterprise applications (re-use in the absolute sense of the word -- not copy then customize), then I would say the helpers aren't a code smell.
It is an interesting point, if a word becomes 'boilerplate' in names then its probably a bit whiffy - if not quite a real smell. Perhaps using a 'Helper' folder and then allowing it to appear in the namespace keeps its use without overusing the word?
Application.Helper.SharePoint
Application.Helper.Authentication
and so on
In many cases, I use classes ending with Helper for static classes containing extension methods. Doesn't seem smelly to me. You can't put them into a non-static class, and the class itself does not matter, so Helper is fine, I think. Users of such a class won't see the class name anyway.
The .NET Framework does this as well (for example in the LogicalTreeHelper class from WPF, which just has a few static (non-extension) methods).
Ask yourself if the code would be better if the code in your helper class would be refactored to "real" classes, i.e. objects that fit into your class hierarchy. Code has to be somewhere, and if you can't make out a class/object where it really belongs to, like simple helper functions (hence "Helper"), you should be fine.
I wouldn't say that it is a code smell. In ASP.NET MVC it is quite common.

The "Why" behind PMD's rules

Is there a good resource which describes the "why" behind PMD rule sets? PMD's site has the "what" - what each rule does - but it doesn't describe why PMD has that rule and why ignoring that rule can get you in trouble in the real world. In particular, I'm interested in knowing why PMD has the AvoidInstantiatingObjectsInLoops and OnlyOneReturn rules (the first seems necessary if you need to create a new object corresponding to each object in a collection, the second seems like it is a necessity in many cases that return a value based on some criteria), but what I'm really after is a link somewhere describing the "why" behind a majority of PMD's rules, since this comes up often enough.
Just to be clear, I know that I can disable these and how to do that, I'm just wondering why they are there in the first place. Sorry if there's something obvious I missed out there, but I did a Google search and SO search before posting this. I also understand that these issues are often a matter of "taste" - what I'm looking for is what the argument for the rules are and what alternatives there are. To give a concrete example, how are you supposed to implement one object corresponding to every object in a loop (which is a common operation in Java) without instantiating each object in a loop?
In each case, the rule can be a matter of specific circumstances or just "taste".
Instantiating an Object in a loop should be avoided if there are a large number of iterations and the instantiation is expensive. If you can move the code out of the loop, you will avoid many object instantiations, and therefore improve performance. Having said that, this isn't always possible, and in some cases it just doesn't matter to the overall performance of the code. In these cases, do whichever is clearer.
For OnlyOneReturn, there are several ways to view this (with vehement supporters behind each), but they all basically boil down to taste.
For your example, the OnlyOneReturn proponents want code like:
public int performAction(String input) {
int result;
if (input.equals("bob")) {
result = 1;
} else {
result = 2;
}
return result;
}
Rather than:
public int performAction(String input) {
if (input.equals("bob")) {
return 1;
} else {
return 2;
}
}
As you can see, the additional clarity of ReturnOnlyOnce can be debated.
Also see this SO question that relates to instantiation within loops.
This article, A Comparison of Bug Finding Tools for Java, "by Nick Rutar, Christian Almazan, and Jeff Foster, compares several bug checkers for Java..."—FindBugs Documents and Publications. PMD is seen to be rather more verbose.
Addendum: As the authors suggest,
"all of the tools choose different tradeoffs between
generating false positives and false negatives."
In particular, AvoidInstantiatingObjectsInLoops may not be a bug at all if that is the intent. It's included to help Avoid creating unnecessary objects. Likewise OnlyOneReturn is suggestive in nature. Multiple returns represent a form of goto, sometimes considered harmful, but reasonably used to improve readability.
My pet peeve is people who mandate the use of such tools without understanding the notion of false positives.
As noted here, more recent versions of PMD support improved customization when integrated into the build process.
You can look at the PMD-homepage, the rules are explained here in detail and often with a why. The site is structured for the rules-groups, here the link to basic-rules: http://pmd.sourceforge.net/rules/basic.html
Each rule is in a PMD Rule Set, which can give you a clue to the reasoning behind the rule (if it isn't explained in detail on the Rule Set page itself).
In the case of AvoidInstantiatingObjectsInLoops, it can be expensive to instantiate a similar object again and again. However it is frequently necessary. On my own project, I have disable this rule, since it is flagging too many false positives.
In the case of OnlyOneReturn, note that it is in a Rule Set called Controversial, which is a hint that these rules are debatable, and depend on the case. I have disabled this entire Rule Set as well.

Do Extension Methods Hide Dependencies?

All,
Wanted to get a few thoughts on this. Lately I am becoming more and more of a subscriber of "purist" DI/IOC principles when designing/developing. Part of this (a big part) involves making sure there is little coupling between my classes, and that their dependencies are resolved via the constructor (there are certainly other ways of managing this, but you get the idea).
My basic premise is that extension methods violate the principles of DI/IOC.
I created the following extension method that I use to ensure that the strings inserted into database tables are truncated to the right size:
public static class StringExtensions
{
public static string TruncateToSize(this string input, int maxLength)
{
int lengthToUse = maxLength;
if (input.Length < maxLength)
{
lengthToUse = input.Length;
}
return input.Substring(0, lengthToUse);
}
}
I can then call my string from within another class like so:
string myString = "myValue.TruncateThisPartPlease.";
myString.TruncateToSize(8);
A fair translation of this without using an extension method would be:
string myString = "myValue.TruncateThisPartPlease.";
StaticStringUtil.TruncateToSize(myString, 8);
Any class that uses either of the above examples could not be tested independently of the class that contains the TruncateToSize method (TypeMock aside). If I were not using an extension method, and I did not want to create a static dependency, it would look more like:
string myString = "myValue.TruncateThisPartPlease.";
_stringUtil.TruncateToSize(myString, 8);
In the last example, the _stringUtil dependency would be resolved via the constructor and the class could be tested with no dependency on the actual TruncateToSize method's class (it could be easily mocked).
From my perspective, the first two examples rely on static dependencies (one explicit, one hidden), while the second inverts the dependency and provides reduced coupling and better testability.
So does the use of extension methods conflict with DI/IOC principles? If you're a subscriber of IOC methodology, do you avoid using extension methods?
I think it's fine - because it's not like TruncateToSize is a realistically replaceable component. It's a method which will only ever need to do a single thing.
You don't need to be able to mock out everything - just services which either disrupt unit testing (file access etc) or ones which you want to test in terms of genuine dependencies. If you were using it to perform authentication or something like that, it would be a very different matter... but just doing a straight string operation which has absolutely no configurability, different implementation options etc - there's no point in viewing that as a dependency in the normal sense.
To put it another way: if TruncateToSize were a genuine member of String, would you even think twice about using it? Do you try to mock out integer arithmetic as well, introducing IInt32Adder etc? Of course not. This is just the same, it's only that you happen to be supplying the implementation. Unit test the heck out of TruncateToSize and don't worry about it.
I see where you are coming from, however, if you are trying to mock out the functionality of an extension method, I believe you are using them incorrectly. Extension methods should be used to perform a task that would simply be inconvenient syntactically without them. Your TruncateToLength is a good example.
Testing TruncateToLength would not involve mocking it out, it would simply involve the creation of a few strings and testing that the method actually returned the proper value.
On the other hand, if you have code in your data layer contained in extension methods that is accessing your data store, then yes, you have a problem and testing is going to become an issue.
I typically only use extension methods in order to provide syntactic sugar for small, simple operations.
Extension methods, partial classes and dynamic objects. I really like them, however you must tread carefully , there be monsters here.
I would take a look at dynamic languages and see how they cope with these sort of problems on a day to day basis, its really enlightening. Especially when they have nothing to stop them from doing stupid things apart from good design and discipline. Everything is dynamic at run time, the only thing to stop them is the computer throwing a major run time error. "Duck Typing" is the maddest thing I have ever seen, good code is down to good program design, respect for others in your team, and the trust that every member, although have the ability to do some wacky things choose not to because good design leads to better results.
As for your test scenario with mock objects/ICO/DI, would you really put some heavy duty work in an extension method or just some simple static stuff that operate in a functional type way? I tend to use them like you would in a functional programming style, input goes in, results come out with no magic in the middle, just straight up framework classes that you know the guys at MS have designed and tested :P that you can rely on.
If your are doing some heavy lifting stuff using extension methods I would look at your program design again, check out your CRC designs, Class models, Use Cases, DFD's, action diagrams or whatever you like to use and figure out where in this design you planned to put this stuff in an extension method instead of a proper class.
At the end of the day, you can only test against your system design and not code outside of your scope. If you going to use extension classes, my advice would be to look at Object Composition models instead and use inheritance only when there is a very good reason.
Object Composition always wins out with me as they produce solid code. You can plug them in, take them out and do what you like with them. Mind you this all depends on whether you use Interfaces or not as part of your design. Also if you use Composition classes, the class hierarchy tree gets flattened into discrete classes and there are fewer places where your extension method will be picked up through inherited classes.
If you must use a class that acts upon another class as is the case with extension methods, look at the visitor pattern first and decide if its a better route.
Its a pain because they are hard to mock. I usually use one of these strategies
Yep, scrap the extension its a PITA to mock out
Use the extension and just test that it did the right thing. i.e. pass data into the truncate and check it got truncated
If it's not some trivial thing, and I HAVE to mock it, I'll make my extension class have a setter for the service it uses, and set that in the test code.
i.e.
static class TruncateExtensions{
public ITruncateService Service {private get;set;}
public string TruncateToSize(string s, int size)
{
return (Service ?? Service = new MyDefaultTranslationServiceImpl()). TruncateToSize(s, size);
}
}
This is a bit scary because someone might set the service when they shouldn't, but I'm a little cavalier sometimes, and if it was really important, I could do something clever with #if TEST flags, or the ServiceLocator pattern to avoid the setter being used in production.

Mutex names - best practice?

Related to this question, what is the best practice for naming a mutex? I realize this may vary with OS and even with version (esp for Windows), so please specify platform in answering. My interest is in Win XP and Vista.
A really safe name for a global mutex is <a description> + <a GUID>:
MyApp Single Instance Mutex : {c96f7db4-d743-4718-bef0-8533a198bcca}
By using a name like this there is absolutely no chance someone else will use the same mutex name as your mutex.
Sniffing around with process explorer, you can see that GUIDs are used in a few places, though in general they are not used. A pattern that does emerge though is that the word "mutex" is used quite a lot and Microsoft seem to like using capitols.
Suggestion:
Incorporate the object type (Mutex in this case) and application Namespace into the unique name. This will generally be safe. If you want to really be safe then append a Guid as well.
Example:
string mutexName = "MUTEX: Skyz.Messaging.ThreadPooling.MyAppSingleInstance";
Advantages:
By creating a naming convention for your apps you make it easy to manage many object names, create more readable code and will make it very easy for existing and future developers to understand the code.
Tip:
Instead of using a Mutex Directly in your code write a reusable wrapper class that can make the code more maintainable in case you ever want to change the implementation or add a tweak. Remember to Remove the Mutex using a disposable pattern or you will have issues!
using (SingletonProcess singletonProcess = new SingletonProcess("MUTEX: Skyz.Apps.MessagingQueue.InstanceMarker"))
{
if (singletonProcess.IsDuplicateInstance)
{
ConsoleWriter.WriteColorLine("An instance of the ExporterService exists, you cannot start a second instance.");
return
}
A google search of CreateMutex samples reveals that "MyMutex" is the most common mutex name chosen.
Therefore you should name your mutex "NotMyMutex" to guarantee uniqueness.
You could combine a description of what you're protecting against with the word "Guard"
I haven't used GUID's in the past, but I'm starting to think its a good idea - if you think about all the developers in the world working of different software.
Unless you are thinking up quite obscure names that you can be assured are unique, you should think about GUID's.