Every few years, Microsoft releases an upgrade to its venerable set of development tools: Visual Studio.

Despite being heavily biased towards the technologies that Microsoft is currently pushed, and the advance of other IDEs such as Eclipse, there are many reasons why Visual Studio is still so widely adopted in the industry:

• It is the standard for Windows Development. If you want to create professional native windows applications it is still difficult to avoid using Visual Studio in a way or another.
• It is easy to setup. Due to the tight integration with Windows, VS is an easy to use IDE for MS languages. This is disputable, but at least some beginners may feel more comfortable using C# or VB.NET than other languages.

Other than the standard advantages that we all know about, one of the nice things about Visual Studio is that it reflects the needs and advances of software development. For example, VS2003 introduced managed code technologies, as a reaction to the widespread use of Java. Then on VS2005 MS added nice features to the .NET languages, such as generic types, which where pioneered in C++ world.

We also saw the introduction of several technologies to reduce the gap between MS traditional software development approaches to the new world of the web.

New Features

Thus, at every release of Visual Studio, we can see that the engineers of MS try to make the languages of .NET (especially C#) reflect the current trends. And VS2010 is not different, as we see features that are already popular in other languages/environments become part of the offer:

• Dynamic languages: .NET now support objects created in dynamic languages, such as Python or Ruby, as first class citizens. Now, you can just create a new object with the “dynamic” keyword, and that object will be allowed to dispatch messages at run time — no static information is required by the compiler. Using this feature may allow you to simulate most of the possibilities of dynamic languages such as Python, Ruby, or Objective-C.
• Simplified parameter passing: most dynamic languages also support passing parameters by keywords. This is possible in Lisp, Python, and in a limited sense in Smalltalk and Objective-C. C# and .NET now support these features that make it easier to call methods with many parameters (although we know that we should avoid this).
• Functional Programming: the software world is each day using more techniques borrowed from the functional paradigm. Which is good news, because software is becoming more complex, and with the trend of parallel programming and multi-cores becoming the reality, there is no way to continue with imperative programming models. It is great to see that F#, a .NET version of OCaml is now a standard part of Visual Studio 2010.

Conclusion

The new features of VS2010 make it again a compelling development environment. Most people will say that MS is late to the game by releasing many of these features only now. But we have also to agree that it is better late than never. What do you think?

Further Reading

• The MSDN page for the public beta of VS2010.
• C# in Depth: an updated book covering the latest version of C# (before the next version). Lots of good tips here.

One of the features of some modern object oriented languages derived from C++ is the use of interfaces. An interface is a class that has no concrete implementation and provides only an interface to access its resources.

Each interface needs to be implemented by some concrete class, but the advantage is that they make it very easy to separate implementation concerns. Thus, you don’t need to worry simultaneously about implementation and interface issues.

Interfaces are one of the things that has helped me to constantly create software that is easier to test, modify and that doesn’t rely on concrete classes. Interfaces may not be the silver bullet of object oriented programming, but they provide a number of advantages over programming over concrete classes:

• An interface is a contract between you and the rest of your application. This contract is guaranteed by the compiler, so it is not possible to change the services made available through your class without changing the interface.
• Creating an interface gives you an opportunity to think about what you class has to offer to clients. The formal step of making an interface requires that you think what is essential in a class and what is just nice. Remove what is not essential and you will have a solid foundation.
• Interfaces can be mixed. So you don’t need to worry if all functionality you need is not present in a single interface. You can always add additional interfaces to supply the required methods for a specific use case. With interfaces, you don’t feel trapped when creating new functionality in the same way as when you use concrete classes. Interfaces can be mixed and matched at will.
• Interfaces make software easier to test. Since there is no concrete implementation that you are tied to, you can freely change the code used by your testing classes by defining your own concrete class. This way, you can decouple testing of your code from the behavior of other classes in the application. It is much more modular and results in fewer headaches during testing.

Disadvantages of Interfaces

Interfaces have very few disadvantages, the only major one being that you need to spend some effort to maintain a separate entity. But modern programming tools have made this mostly a simple effort, so it is not as difficult as it used to be.

Another aspect of interfaces that is overemphasized is the performance issue of using virtual pointers?—?in the lingo of C++. You have to notice, however, that modern object oriented languages are based on virtual machines. Such languages have each method represented as a virtual pointer anyway, unless the system decides to inline the method (in which case there is no performance penalty). Unless you have extremely critical software (in which case you probably need to be using C/C++) you shouldn’t worry about such performance issues, because they can be better solved by the virtual machine.

Conclusion

Interfaces are a modern mechanism to improve the design of software. Despite this, interfaces are under-used by most developers. We should use interfaces as the default method of communicating between parts of our application, reserving concrete classes only for constructing objects (factory methods) and for classes residing in the same package.

I intend to write more about the issue of creating concrete objects through the use of factory methods, which is another important part of the application if you really want to make full use of interfaces. Stay tunned and we will discuss more of this in the future.

Further Reading

• Large Scale Software Design is a C++ book, but it teaches everything you need to know about separation of concerns between interfaces and concrete code. This is even more important in C++ than in C# and Java, because of the compilation issues in C++ code. However, the advice is completely applicable. Reading this book will make you more knowledgeable about interfaces than reading any other book in Java or C#.
• Effective C#: this book covers a lot of nice topics related to class design and use of interfaces. Recommended.

But what about you, do you think there is any advantage or disadvantage of interfaces that I didn’t mentioned above? Share this with us in the comments.

I am an avid reader of programming books. I think it is important to benefit from the experience of other fellow programmers, and one way of doing this, other than reading other people’s software, is reading books that collect some kind of development experience.

Although it is interesting to read about programming, there is a big downside on programming books: the programming examples that they present.

Coding samples are given on books to exemplify techniques. They can very well perform this task, but they also carry with them several problems that make them a tough sell:

Most code examples are of low quality: one of the reasons for this is that coding samples in books are not directly checked by a compiler. I know that most writers in fact check this before publishing something. But in reality there is no guarantee that between final edition, changes requested by the editor, etc., the sample code will still be correct. Authors and editors try to be careful, but by the very nature of the process there is the possibility of mistakes that wouldn’t be allowed by a compiler.

Sample code is tied to the author’s environment: a very frustrating scene is to open a book on some technique, then type the sample code and find out that it almost works. That is, it compiles, but for some obscure reason it doesn’t perform what it was supposed to do. This is a problem that everyone learning to program has encountered at least once. Probably the main reason is that sample code, by its brevity, is tied to the environment in which the author is working. Most modern programming technologies are too complicated to be reduced like that.

It promotes bad programming habits: The worst habit, which is also rampant on programming forums, is programming by copying and pasting. While it is simple to directly copy and paste a piece of code, it rarely works the way you immagine. You are also making your own code more complicated, and it is just like adding a strange body to your house: you don’t really understand what you are doing.

It always lacks encapsulation: by the very nature of coding samples, it has nothing to do if your application domain. By using such code, you are programming in the authors level of abstraction, not in your level of abstraction. A classic example is someone creating a Windows program using the Win32 or .NET API. The code is usually littered with Win32 or .NET terms. By doing this, you are programming at the level of abstraction of the Windows API: windows, forms, handles, callbacks. Such a programmer is not doing a good job in representing the level of abstraction of the application. The level of abstraction of your code should be based on the elements of your domain, not on windows and dialog boxes. These elements should be encapsulated as part of the objects used by your application.

Conclusion

My advice on this area is: read as many books as you can, but don’t bother using any of the sample code included. Prefer online resources, that are much easier to check. Prefer also the documentation from your vendor, that should be easier to read now that you (hopefully) know how the technology works (if the author did a good job). Use sample code from a book only as a last recourse, but be warned: it may be bad for you.

Further Reading

• Desing Patterns: this is THE book you can use to start thinking about abstraction at your level, instead of the abstractions others want you to use. This book is has very high rate of ideas per lines of code. Also check this one on the same subject, but much easier to read.