Extensions methods... Still missing some features

I like extension methods in dotNet. Extension methods give you easier access to your helper and util classes with static methods that operate on your object. It's not that extension methods give you any new features, they just give a little different syntax that might be a little more natural. It gives the programmer a way to use methods across your project without learning the syntax of your helper classes.

I like extension methods because they give me a way of separating my code where I find it fit, and still give the user a feal of coherence. Extension methods do not affect the architecture of your application as it doesn't change where code is, just the syntax of accessing it.

So far I have found 3 areas where extension methods fall short.

1. :Extension methods can be made work like instance methods. Extension method cannot be used as static methods. In a static context they could have been great for factory methods and such for your classes and interfaces.

IDomainObject o = IDomainObject.Load(1); //Working on the type. Can't be implemented as an Extension method
o.Save(); //working on an instance. This is ok

Wouldn't static extension methods be cool? :)

2.: Extension methods can't overload operators. As I generally dislike operator overlodings, this is not a big problem for me. I do however have one place in mind where I could use this.

3.: Visual studio does not recognice Extension methods if your code is in the class that is extended.

public class Test{
public void doStuff(){
HandleMe(); //Can't be implemented through extension methods
this.HandleMe2(); //This can be an extension method.
}
}

I don't really see why this is not implemented. Maybe it will come in a future release.

Extension methods are GREAT!

Creating a test/development enviroment

On most projects I've been on, defining the infrastructure has started by looking at the customers current infrastructure and then trying to create an environment that resembles that for testing and for development. I have never seen a test environment that looks like the production one. I have never moved an application from test to production without some unknown settings on the production environment.

My suggestion is this: We should stop using the production environment as the reference of our development. Instead we should specify the environment in as simple terms as possible. this specification should of course be validated by infrastructure guys (or girls). This way the application developer can focus on what is his does best which is the functionality of the application and not hardware and network setup.

This approach should result in better applications because it lets the infrastructure support the application and not the other way around.

Edit: I had a comment on this post. What I mean is that I want the reference infrastructure to be something that can be realised in a test and development environment. I don't want the production environment to be the reference. The reference infrastructure should of course be evaluated by someone who knows the production environment. Getting the application from the reference installation to the production environment should not be a task for a developer.

Databinding in WPF

Data binding in .Net has previouslybeen done by providing a data source and calling DataBind(). It has been a one way data flow initialized directly by user code. In WPF they have changed it a bit. To enable automatic synchronization they have basically implemented the Observer pattern. To make this happen they have implemented the properties in the UI component as DependencyProperties. A DependencyProperty is a static object on the class containing the property. The ordinary properties on the class are wrappers setting the value on the DependencyProperty. In this way you can subscribe to changes on the property through the DependencyProperty.



In the illustration I'm trying to show two connected textboxes. When typing the name of a font in the first TextBox, the font of the second should change accordingly.

This event driven synchronization is dependent on the fact that your object inherits DependencyObject and that your properties use DependencyProperties. If you want your UI to be data bound to something that is not a UI component, you can implement the INotifyPropertyChanged interface and fire the PropertyChanged event when your object changes.

The way to publish data to the UI could be to bind all the fields in the UI in relation to a parent container (the windows or something) and then set DataContext to the data object. This way your UI is filled with data very smoothly.

Xaml, the ultra lightweight IOC container

I've been testing xaml for defining what object to create at runtime. Although xaml is often linked to windows workflow foundation or windows presentation foundation, it can easily be applied to your own domain.

Xaml is a xml language where you can define how a .net object structure is to be initialized. It has many similarities to springframework.net, lightweight IOC.

The greatest thing about Xaml is it's very easy syntax. Every node in your xml is giveng the name of the class to instantiate. By givin the root node a namespace, your VS.Net provides full intellisense to what properties are on what classes and what type they are. By making typeconverters for your classes you are able to provide a simple way of creating your simple classes.

Missing?
What is missing then? Well... Xaml is just a language that enables you to create objects. Because of this it doesn't give you the means of controlling the lifespan of your objects. You can't state that an object should be a singleton for the application etc. If you want that you have to code it yourselfes.

Xaml supports property injection but not constructor injection which means all properties needs a public setter for it to be set by Xaml. Most of my properties already have public setters, but I have to alter a few for them to be xaml enabled.

Another thing I'm missing is the support for generic types. In xaml you cannot instansiate List as an example. In stead you kan implement some xaml interfaces or you will have to make new classes that inherrit from the generic type you want.

Example

I have used my search criteria framework that I introduced in "A use for operator overloading" for testing the Xaml.



The above xaml creates the object structure ressembling the following query: Content = "teste feste" or Title = "teste feste" or (Content="test" and Title="test")

I would also have liked a possibility to cross reference objects (create it once and reuse it multiple places in my xaml), but overall xaml provides a very simple way of creating your object away from your code. Whereas spring.net has quite a heavy syntax xaml is very intuitive and will be comprehendable, even for people with no technical background.

Reflection on Lazy loading

No, I'm not going to reflect on lazy loading. :)

By lazy loading I mean having an object model without all of the objects being loaded (from database) at once. If I for instance have a User object with an Organisation, I don't necessarily want the Organisation object to be loaded when the User is loaded. Not loading everything at once speeds things up because you can control what is retrieved from the database and what is not. Anyway, enough about why lazy load. NHibernate implements lazy loading by creating a proxy class that inherits the class of the object. The moment you try to access your object, the object is retrieved from the database. The object you asked for has been loaded internally in the NHibernate object and it will be transparent to you because all your interaction with the object will be passed on to it

The object model you want

The problem starts when you start to use reflection on your objects. The Organisation object on the User is actually not a Organisation, but a subclass generated by NHibernate. If the object you are trying to access is an ExtendedOrganisation, you can't cast it to the type you want because its type is defined by the reference on your User object.


Because NHibernate caches its loaded object it can be hard to tell in advance whether an object will be a proxy or not. If you ask NHibernate to load a Organisation object, you will get a proxy class object if NHibernate has cached it as a lazy loaded object beforehand.

The objects NHibernate gives you

If you want reflection on your objects that may be lazy loaded, you can make generic method where you also have to give the type. When applying reflection you will have to use the generic type for your analysis. If you object has been loaded with a wrong type, you can make a property that returns the same instance. Because the NHibernate proxy contains a reference to the real object and passes all method calls etc. through you can make it work just by returning "this".

Some of the components in .Net that consume list of objects do this by reflecting on the first object in the list, using this type to handle all the objects in the list. You can overcome this by implementing a TypeDescriptionProvider and registering it like described by Ayende. The problem with this is that it will change the way your types are handled throughout your application. You would no longer be able to have a list of ExtendedOrganisations.
The much nicer approach would of course be to have type aware components through Generics.

My Prefered Developer Profile

My preferred coworker has the following qualities:

• Lazy: I want the person to avoid repetitive work. Some might say that repetitive work is part of the job. I think repetitive work is a sign of bad architecture. Repetitive work should be avoided at all costs.
• Rebellious: Don't accept everything I say. I'm just human and might be mistaken. I get suspicious if no one challenges my ideas.
• Geeky: I want developers to be enthusiastic about the work they do. All the time they should be striving for better solutions to the problems we have.
• Have a hobby: Software development is not everything, and a lot of software ideas spring from problems outside this business.

And probably some more :)

Comma Separated Values

Or csv file extensions for tabular data.
I thought the name described the format, and that it was as simple as that. It was only when I tried to read such file in MS Excel I found out it is not the case. Apparently my regional settings requires csv files to be semicolon separated. So much for international documents :)

When to use the GAC

I've been using the .Net framework for a few years now. I still haven't really found a use for it...

One of the good things about .Net is the xcopy deployment strategi. It is kind of lost when the gac is used. With the gac your solutions suddently start to depend upon each other a lot more.

Thanks, but no thanks: No more GAC!

If anyone out there has a good use for the gac, please let me know :)

Consuming generic types as a generic parameter

What is he talking about? Well, I have a hard time expressing myself when it comes to generics. I'm trying to make a library I can use across projects

This is what I want to do:

interface BusinessEntity<T>{...}
class EntityList<T> where T : BusinessEntity<TT>{...}

That way I can let my domain objects implement the BusinessEntity interface and they can be consumed by my EntityList. In the following I have a domain class called Document.

//defining Document
class Document : BusinessEntity<int>{...}
//creating instance
EntityList<Document> list = new EntityList<Document>();

To me this all makes sense. Sadly it doesn't compile :( The problem is that TT in the EntityList is not defined. As far as I know I have to define both T and TT on EntityList even though TT is given once I have defined T. Now it loks like this:

//definition
class EntityList<T,TT> where T : BusinessEntity<TT>{...}
//creating instance
EntityList<Document,int> list = new EntityList<Document,int>();

I'm not to happy about the extra generic parameter on the EntityList. Once T is defined, there can be only one valid type of TT. But because of the way you have to define it, the compiler will not complain about the TT, but actually about the fact that T doesn't implement BusinessEntity<TT>. This means that if TT is defined as string for instance, the error message from the compiler will be: Error, Document does not implement the interface BusinessEntity<string>. This will make no sense to the programmer trying to use the class.

If you have any solution to this, please let me know :)

Platform as a religion

I don't like job titles like "evangelist". I instantly think of religion and that they believe they have found the one true answer they are going to preach to me. I believe solutions only can be measured against real problems, and if the problem is complex and abstract, the outcome can be hard to conclude anything upon.

3rd party software

I'm a bit swamped by 3rd party software at the moment.

3rd party components are good in that they provide a lot of functionality that is already implemented and hopefully also tested. Sometimes I don't think using 3rd party components is the best solution. Sometimes the dependencies are large, and the problems created by these dependencies are greater than the benefits gained from using this 3rd party functionality.

I don't avoid using 3rd party components, but I do have some general issues that I address while deciding whether to use a component.

• Transparent
  Although I select a 3rd party component to reuse allot of its functionality, I like to understand what it does. If i understands its functionality on an abstract level, I'm less dependant on the component in the future.
• Few dependencies
  When I choose a component, I choose it for its features and behavior. I don't want to be handcuffed to other products that I don't intend to use. Even if I want to use the other product, I want be the person making that choice.
  
• Expandable
  I want to be able to plug in my own functionality where ever it makes sense. This could mean an event based approach or something based on contracts
  
  

Open Source

Open source is not very popular in the MS community. Here is my list of why I think Open Source is so great.

• It gives credability to the product being open sourced. It doen't make the product better, but as I can read the source the producer will be more willing to write robust and transparent code. The maker lets you check if the product is any good or not behind the scenes, and if the makers lets you see that, its probably not too bad.
• It makes me less dependant of a product. If the maker goes out of buisness, I can still get errors fixed.
• The producer can benefit from others reviewing the code.

Following Orders

Is it a problem that people don't know how to follow orders any more? Everything has to be discussed. I have met people who beleave it is, but I don't.

I think this human behavior is the main reason that we have evolved like we do and we all the time discover new things. I generally don't like to work with people that don't question what I say or do. Likewise I generally don't accept orders from my boss without a reason.

This doesn't mean that I can't do thing people tell me without asking question. If they have proven to ask reasonable things of me, I will do it right away.

Its all a matter of motivation. There is no such thing as a boring task. So far I haven't found a task in this business that I somehow couldn't turn interesting. If my project manager knows and understand my preferences he will be able to motivate me.

I once had a project manager who's standard motivation line would be: I know this a crappy task, but you just have to do it. That didn't motivate me and in the end I quit that job. He could instead have said: I have screwed up... you will really make my day if you can fix this for me.
To me project management is mostly about motivating project members to do the right thing. If they are motivated, following order will be easier, and productivity will be much higher.

What is SOA all about?

Do you think SOA is about software development? Do you think SOA is about making two systems communicate?

I don't!

I think SOA is about abstraction. I think SOA is about specifying needs and capabilities. SOA is about dividing your domain into smaller parts and being able to outsource it.

This can be applied to software or any other domain where you have parts communicating. I think it is great for structuring organisations. SOA is great for figuring out who needs to talk to who and why.

What I'm trying to say is that I don't think SOA is limited to software. Every time I hear people specifying resources they need and afterward seeking resources matching their needs, I think SOA..

Sometimes I hear about SOA as being bad for performance or that it doesn't scale well. I don't think SOA is about performance, it is about specifying needs and secondly fulfilling them.

Language preferences in domain model design

Every time I start on a new project I face the same dilemma: What language my domain model will be written in.
Generally I prefer English because it fits nicely into most programming languages, and foreigners will be able to understand it. I have done a lot of government law based applications, and sometimes English adds quite some complexity to the model. When there is no exact translation of the terms, you end up with a lot of nonsense of approximated terms or made-up words in the model and you need a great deal of commenting for anybody to understand it. Its not a domain model your domain experts understand.

Working with multiple languages is a pain, and I don't recommend it. I have seen lots of projects where the domain model was a mix , and it just adds complexity to the project.

I would very much like to hear your thoughts on this.. How do you handle developing for non English domains. At the moment I feel like going all the way and develop the domain model all in non English if needed.
On top of that I want to try out using letters like æøå in the domain model. The problem with this is that although the programming language supports it I can't count on all systems supporting it:(

Planing the next year

I have recently taken the MCPD in windows development, and now I have the time to think about what I want to take on next. I have a whole list of things I want to accomplish during the next year or so. Chances are that I will do something completely different. :)

• Take at least one more MCP certification.
  
• Ruby on Rails. I have been briefly introduced to this.. I want to know more!!!
  
• JAOO.
  
• Workflow. This is a new way of thinking, programming across requests. It's programming closer to the domain model.
  
• Consolidate my design preferences in a framework or tool. I generally go for the big picture and I don't want to be too constrained by a given technology on a project. However I think I need to settle a bit (just a little :))
  
• Take a class in enterprise architecture. Why not just read books and blogs and figure it out myself? The advantage of taking classes is that I use dedicated time on it a and I will hopefully be in a study group that will force a bit of commitment from me.
  
• Make a small program, package it as a Debian package and deploy it to my own repository. This is just something I need to do because I think it is cool. :)

The C5 Generic Collection Framework

I have recently come across the C5 Generic Collection Library. This is something worth investigating. The .Net Framework collection namespace is a bit limited, and to me not abstract enough. The C5 enables you to

code to an interface, not an implementation

which is is what I have always wanted.

Caracteristicts of enums

Some time ago I had to map some enums to and from a database. The database would store the integer value and I would cast the enum to and from the database. Suddenly I got unsuspected results even though I had unit testet the functionality with all valid values of the enum. I realized the enum contained an integer value not maped in the enum. No runtime exception was thrown.

I was a bit puzzled by this and I more or less considered this to be some sort of bug in the .Net framework
This is not a bug, and although I sometimes would like it to behave differently, it does give enums a new use.

Consider the following:

Accesories{
  SpareTire = 1,
  ElectricWindows=2,
  Heater=4,
  AirCon=8,

  Standard= SpareTire,
  Family = Standard | ElectricWindows | Heater,
  Luxury = Family | AirCon
}

As shown above it is posible to define your vehicle just by adding the single components. I think MS calls it flags, and the keys issue is that your primitive enum values must map to different bits.

(var & Accesories.Family) == Accesories.Family

will determine whether the level is at least Family. You can use other binary operators to anlyse the value of your enums.

I have succesfully collected data by just adding the simple values together and in the end just validated that it was actually a valid enum value. the validation and decission of the application is build into the structure of the enum instead of written in code.

In the example it is possible to add all primitive values together, but it is also very usefull when you have to select one or the other. Male or female for instance.

I'm looking very much forward to using kanaugh maps together with my enums :D

The Inter - face

Interfaces in object oriented programming have been around for a few years now. I still run into people who do not use interfaces while programming.
For .net developers this might be because VS.NET does not have a menu for adding interfaces, and VS.Net allows you to be more or less ignorant towards the structure of the program you are making (Drag'n'Drop coding I think I would call it :)).

To me structure is the most important thing in software development. Interfaces is a cornerstone in building this structure.

Interfaces are great when you need to consume objects, and you are more conserned with its use than what it is.
Interfaces come into play when you want to create reusable code. Directly copying source code is not a good solution and I prefer structuring my way out of it. Making a component or a framework if you like.
If you can avoid it keep your reusable components working without the user having to extend a series of classes of yours. The user might have reasons not to extend your classes, such as the need to extend other classes. Maybe the objects need to be serialized in between calls or some thing else. If you force the user to extend your classes, you must be sure the user can do anything to it in another context.

There is of course nothing wrong with providing a default implementation for your interfaces. Please don't give these default implementation the name that fits the use of the interface. IList and List is a bad example of naming a default implementation, or maybe it's more that IList should not have a default implementation. Because of these bad names, I dislike prefixing interfaces with I. The interface is the main thing and should be given the real name. Normally there is no need for a default implementation, but if needed I like giving the default implementation a Impl postfix far better.

When you design your system, you must think interfaces to begin with. There is little benefit from designing a system using classes, adding interfaces to all classes afterwards. Interfaces are only relevant if they actually respresent some decoupling in your system.

As a class can implement as many interfaces as you like, interfaces can be very small. This means that by using interfaces you code will only require the functionality it actually uses.. and the people using your product will only have to implement what is needed. They do not have to extend an existing class and thereby enherit a lot of useless functionality.

Less is more!
Interface > Class

Unit test addicted

I have become addicted to unit testing. So far I haven't noticed any side effects :)

Enough small talk... This is why I like unit testing so much:

• It forces me to initially focus on functionality.
• It lets me refactor central code bits and see if any dependant projects break because of it.
  I have worked on projects where nobody wanted to change stored procedures on the database. Instead new stored procedures were created. Thereby not breaking existing code.
• It lets me open up old projects that i don't remember anything about and experiment when fixing an error. It more or less functions as a description and validation of what the application does.
• It feels good when delivering a product knowing that it actually does what you expect of it.