Code semantics

As I started a new job I was introduced to a new codebase. This happens to any developer who is starting a new job or a new role.

Since people are different, their approaches towards code is different as well, and were one developer gives his data-access interfaces and objects the suffix 'DAO', another developer will suffix it with 'Repository', hence, we might get 'ICoustomerDAO' or 'ICustomerRepository'.

The meaning is the same - a service that is charge of storing and retrieving information about a customer.

As I mentioned at the beginning, I was recently introduced to a new codebase that has its own semantics. Some of these semantics were trivial like using the convention of 'Sink'. I immediately understood that a sink is a recipient of data and it is the end of the road for this data. Examples are ConsoleSink which writes to the console and DBSink which writes to the database.

This however, is a simple example as a system is more complex than that. There are other "hidden" semantics that are just the result of differences between people and the way they things.

The example I used with the DAO/Repository in taken from the semantics of Domain-Driven Development (DDD) which gives very high importance to the way things are expressed. The base for DDD is first of all defining an ubiquitous language that is used to define the entities in the system and the relations between them.

I believe that if a software project will have a defined semantics, the amount of the mess that is usually a part of a codebase will dramatically be reduced, it will be easier to get familiar with the code and maintenance will be easier.

Blog returned here

However, there are posts that do not exist here but u can find on: http://jajahdevblog.com/reshef

Blog has moved

http://jajahdevblog.com/reshef

Tip of the day #2: Dynamic proxies

A dynamic proxy is an approach that is not fully natively supported in .net but natively exists in java.

What a proxy means, is to wrap an object with with wrapper that intercepts call to that object and does something in addition.

What is it good for? A naive example is to add a proxy that log calls to methods of an object.

A more real world example is to use proxy in an O/R mapper. The mapper can create proxies on top of the domain object and intercept calls to properties in order to fetch data from the db and track changes to the data that will later be persisted (NHibernate works this way).

The idea of dynamic proxy is to provide an implementation of an interceptor and attach it to the proxy. From now on, all calls to methods will pay through the interceptor which, for the logging example, logs every call to the method. Concrete examples can be found in the link at the bottom of this post.

The .net native implementation for dynamic proxies is by using ContextBoundObject or MarsalByRefObject. This approach is limited since you have to inherit from one of these classes which is not clean.

There are several implementations of dynamic proxies that do not interfere with inheritance hierarchy of your code.
Here are some examples:

1) Castle DynamicProxy

2) DynamicProxy.NET

3) LinFu

Tip of the day: Mutual exclusion when Remoting

Another tip from Gal:"

Just a small tip that might have saved me a few good hours:

A Mutex can be released only by the thread that originally locked it.

A semaphore can be released by any thread.

I used a mutex at the beginning, while locking and releasing on different threads, and at the threadpool desire, got ("sometimes" is the WORST one) an

ApplicationException - Object synchronization method was called from an unsynchronized block of code.

Usually this means that the mutex is not locked but still tries to be released – check this out.

But in my case (first remoting call locks an object and the second releases), it was just that a mutex was the wrong sync method, and a semaphore quickly solved the problem.

As mentioned in the link, the error message need some work."

Tip of the day: Interlocked

The Interlocked class in .net is a static class that provides type operation that are performed atomically.

By providing this, it can help solve simple multithreading scenarios since:

1) It removes the chance of deadlocks that can be caused by using the lock keyword.

2) It has better performance than the lock keyword.

3) Simpler (and less) syntax.

Lets take a look at a scenario where you would like to count how many times a method is called while a program runs (multithreaded environment):

private static int methodCallsCounter = 0;
...

public void SomeMethod()
{
    System.Threading.Interlocked.
        Increment(ref methodCallsCounter);
    ...
}

The Interlocked class has a set of methods to manipulate data. A complete documentation and a full example can be found here.

Talking about multithreading and locks, I suggest reading this. It describes very important points about locking.

Tip of the day: Friend assemblies

The internal keyword (C#) is defined as the way to restrict access to members only to types in same assembly.

But, since the .net framework 2.0, there is a way to to define an assembly as a friend assembly. This can be done by specifying

[assembly:InternalsVisibleTo("friend assembly")]

in the AssemblyInfo.cs file (or in any other file).

After specifying this, the friend assembly can access the internals of the assembly marked with this attribute.

I can see two useful thing that can be achieved:

1) Better encapsulation of course.

2) Enable access for unit testing by using this strategy.

The msdn documentation is here.