Engineer

Computer Science - Programming - OOP

[santevid]

James Altucher

An amazing guy, excellent writer, blogger, teacher and adviser.

http://www.jamesaltucher.com/

Some of his excellent articles:

http://www.jamesaltucher.com/2014/04/the-ultimate-cheat-sheet-for-investing-all-of-your-money/

Mr. Altucher reminds me of Nenad Bakić, an Croatian entrepreneur and investor (http://trzistakapitala.wordpress.com/), but James is somehow more trustworthy.

[santevid]

Codility

Now, some words about Codility, this platform deserves it.

If you don't know what is Codility best explanation would be to click on this link: www.codility.com and read a frontpage.

There are several platforms on the net that provide tools for testing potential new software programmers/developers/engineers, but this is the best one, at least for now. Codility provides excellent reports, that will report a lot user actions while the user is solving a problem. i.e. when he run the code to test, time, execution times, complexity etc.

Except for recruiters, Codility is useful for someone who wants to train. For example if you are looking for a new job and you know that on interview you will be asked to solve algorithmic problems, then start train with Codility. They provide a lot of interesting problems.

Each month, they release a new challenge. So, people can test self on such challenges. If you manage to solve a challenge, then they will release a certificate:http://www.codility.com/cert/view/cert3G5VGX-KGDUSAF6XVCMWN8D/, which is nice.

[santevid]

Indexable Circular Buffer

Developers are familiar with the circular buffer data structure. It can be interpreted with end pointer (an index where a new item should be placed) and start pointer (an index where the oldest item is). When buffer is full (start== end), simply the oldest item is replaced with the newest (start= end++).

http://en.wikipedia.org/wiki/Circular_buffer

In some cases it is useful to have an indexable circular buffer, i.e.buffer[i] should access (start + i)-th item.

This can be simply implemented with modulo operation, as shown below in a C# implementation which implements IList<T> and IList interface.

public class CircularBuffer<T> : IList<T>, IList     {         private T[] buffer;         private readonly int size;         private int startIndex;         private int endIndex;         private int count;         public CircularBuffer(int size, double trunckRatio)         {             this.size = size;             Init();         }         public void AddRange(IEnumerable<T> collection)         {                 foreach (var item in collection)                     Add(item);                      }         private int CalculateTrunckSize()         {             return Math.Min(Math.Max((int)(Math.Ceiling(TrunckRatio * size)), 1), size);         }         private void Init()         {             buffer = new T[size];             startIndex = 0;             endIndex = -1;             count = 0;         }         public int Size         {             get { return size; }         }         /// <summary>         /// Transforms from buffer index to CircularBuffer index         /// </summary>         /// <param name="index">Index in buffer</param>         private int TransformInternalIndexToPublicIndex(int index)         {             return MathHelper.GetPositiveIntModulus(index - startIndex, size);         }         private int TransformPublicIndexToInternalIndex(int index)         {             return (startIndex + index) % size;         }         public int IndexOf(T item)         {             for (int i = 0; i < Size; i++)             {                 if (buffer[i].Equals(item)) return TransformInternalIndexToPublicIndex(i);             }                 return -1;                      }         public void Insert(int index, T item)         {                              if (index > Count - 1)                     throw new ArgumentOutOfRangeException("Index is not a valid index.");                 int internalIndex = TransformPublicIndexToInternalIndex(index);                 buffer[internalIndex] = item;                      }         public void RemoveAt(int index)         {             throw new NotSupportedException();         }         public bool IsFixedSize         {             get             {                 return true;             }         }         public T this[int index]         {             get             {                                      return buffer[TransformPublicIndexToInternalIndex(index)];                              }             set             {                                      buffer[TransformPublicIndexToInternalIndex(index)] = value;                              }         }         public void Add(T item)         {             AddInBuffer(item);         }         private int AddInBuffer(T item)         {                              int index = IncreaseAndGetEndIndex();                 if (Count >= size)                 {                     startIndex = (startIndex + 1) % size;                 }                 else count++;                 buffer[index] = item;                 return index;                      }         private int IncreaseAndGetEndIndex()         {             return endIndex = (endIndex + 1) % size;         }         private int IncreaseStartIndex()         {             return startIndex = (startIndex + 1) % size;         }         public void Clear()         {                              Init();                      }         public bool Contains(T item)         {             return buffer.Contains(item);         }         public void CopyTo(T[] array, int arrayIndex)         {                             foreach (T item in this)                     array[arrayIndex++] = item;                     }         public int Count         {             get { return count; }         }         public bool IsReadOnly         {             get { return false; }         }         public bool Remove(T item)         {             throw new NotSupportedException();         }         public IEnumerator<T> GetEnumerator()         {             return new CircularBufferEnumerator<T>(this);         }         System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()         {             return new CircularBufferEnumerator<T>(this);         }         public int Add(object value)         {             return this.AddInBuffer((T)value);         }         public bool Contains(object value)         {             return this.Contains((T)value);         }         public int IndexOf(object value)         {             return this.IndexOf((T)value);         }         public void Insert(int index, object value)         {             this.Insert(index, (T)value);         }         public void Remove(object value)         {             this.Remove((T)value);         }         object IList.this[int index]         {             get             {                 return this[index];             }             set             {                 this[index] = (T)value;             }         }         public void CopyTo(Array array, int index)         {             this.CopyTo((T[])array, index);         }         public bool IsSynchronized         {             get { return false; }         }         public object SyncRoot         {             get { return null; }         }     }

[santevid]

ReadOnly Collections

A disadvantage of .NET is surely failed definition (and implementation) of read-only collections. From the beginning .NET creators simply ignored read-only collections. This brings a lot of misunderstanding among.NET developers.

Take a look at this class:

public class FirstFiveOddNumbers {     List<int> numbers = new List<int>(new int[]{1,3,5,7,9}); . . .     IList<int> GetNumbers()     {         return numbers;     } }

Method GetNumbers() doesn't return read-only list, in fact caller can change, add, remove numbers in returned list.

Sure, method GetNumbers() can clone internal collection and return cloned one(new List<int>(numbers)), in such way method's class can ensure that caller's changes on collection will not affect its (internal) collection object. But cloning can be inefficient for large collections.

For that purpose Microsoft added in .NET 2.0 ReadOnlyCollection<T> wrapper:

[SerializableAttribute] [ComVisibleAttribute(false)] public class ReadOnlyCollection<T> : IList<T>, ICollection<T>, IEnumerable<T>, IList, ICollection, IEnumerable

Constructor of ReadOnlyCollection<T> accepts IList<T> that it wraps:

public ReadOnlyCollection(IList<T> list)

It only wraps a collection, so it is O(1).

So lets change our code:

public class FirstFiveOddNumbers {     List<int> numbers = new List<int>(new int[]{1,3,5,7,9}); . . .     ReadOnlyCollection<int> GetNumbers()     {         return new ReadOnlyCollection(numbers);     } }

Now, caller is unable to change returned collection, caller can't even cast returned collection to List<int> and then change items of collection.

It seems, like that is what we want. Is it !?

The problem is that ReadOnlyCollection<T> is not covariant in T, like any other implementation (only interfaces can be type covariant).

This code demostrates a problem:

public interface Shape { } public class Rectangle : Shape { } public interface Geometry {     ReadOnlyCollection<Shape> GetShapes(); } public class RectangleGeomerty : Geometry {     List<Rectangle> rectangles;     ReadOnlyCollection<Shape> GetShapes()     {         return new ReadOnlyCollection<Shape>(rectangles);     } }

This code is not valid, actually it produces a compiling error in method GetShapes(). Solution is to explicitly cast rectanges to shapes.

return new ReadOnlyCollection<Shape>(rectangels.Cast<Shape>());

But this is O(n) operation and we would like O(1).

So .NET creators bring interface IReadOnlyList<out T> in .NET 4.5. As you can see out T means it is covariant, so following code will do job as I wanted.

public interface Shape { } public class Rectangle : Shape { } public interface Geometry {     IReadOnlyList<Shape> GetShapes(); } public class RectangleGeomerty : Geometry {     List<Rectangle> rectangles;     IReadOnlyList<Shape> GetShapes()     {         return rectangles;     } }

Yeah, now seems like everything is solved. But then you are looking at specification of .NET 4.5 and find out that List<T> implements IReadOnlyList<T> which is OK, but IList<T> doesn't implement IReadOnlyList<out T>, which is not OK.

So code like this is not possible:

IList<Rectangle> rectangles; IReadOnlyList<Shapes> shapes = rectangles;

In fact, interface IList<T> is not covariant so there is a problem and they are unable to change IList<T> to IList<out T> because it would require moving some members from IList<T> to IReadOnlyCollection<out T> and this would bring a lot of problems in CLR 4.5. In fact, CLR 4.5 would be unable to run applications developed with frameworks .NET 1.0, .NET 2.0, .NET 3.0, .NET 3.5 and .NET 4.0

The problem can be overcome simply by implementing class that inherits IReadOnlyList<T> and is wrapper for IList<T> object,

public class ReadOnlyList<T> : IReadOnlyList<T>     {        private IList<T> list;        public ReadOnlyList(IList<T> list)        {            this.list = list;        }        public T this[int index]        {            get { return list[index]; }        }        public int Count        {            get { return list.Count; }        }        public IEnumerator<T> GetEnumerator()        {            return list.GetEnumerator();        }     }

or we can add extension method for IList<T>

public static IReadOnlyList<T> AsReadOnly<T>(this IList<T> collection) {         return new ReadOnlyList<T>(collection); }

[santevid]

Dispose()

Usually you can read how programming in languages such as C# and Java should be a lot easier than C++. One argument is memory handling in C++ where you need to contrive a smart memory management system before you even start to implement any complex solution.

Yes, you don't need to think about freeing memory since you have Garbage Collector, but life is not much easier in modern OOP environments since there are disposable objects. Carelessly handling with disposable objects can turn your code in mess, especially if you are coding with other team members on a project.

Before starting any coding, you have to clear some things with your team. One of those is handling disposable objects.

There is a standard rule that everybody should follow:

"The object which creates a disposable object and owns it is responsible for disposing it.".

I even thought to implement something like Smart Pointers in C++ (http://en.wikipedia.org/wiki/Smart_pointer) for C# disposable objects, but soonly I've realized it's not a smart idea. The best is to follow upper rule 1.

If a method returns disposable object

TODO