Over-engineering trivial tasks can be challenging and educating

Posted by Filip Ekberg on June 1 2011 2 Comments

It’s been almost six months since my last blog post here, it’s not like I don’t have anything to write, but the time I have over at the end of the day just doesn’t end up so that I have time to write here. I’ll try to get some more time to write here since I really do have a lot of interesting things that I want to share!

Lately I’ve seen a bunch of questions over at StackOverflow that is quite trivial, at least trivial to us that work with these kinds of things on a day to day basis. My example here is from the question “how to read all the subdirectories in a given destination..” as I see it, there are a lot of different ways that you can solve this but no matter how trivial this problem is, you can always over-engineer it. So when I first saw this question I immediately started to think about interesting ways to solve this.

One of the possible solutions could be to get a directory list of the parent folder and use parallel extensions to recursively scan each folder to speed up the process a bit. The traversing method signature could also contain an action / delegate that are used when the given file you are looking for is found.

However, this does not completely solve the given task, the person asking the question wants the following requirements:

  • Start looking for the ABC file in the parent directory
  • If there is no ABC file, go on to the next subfolder
  • If it is not in the subfolder, move on to the next one…. and so forth..
  • Once a file is found, process the file

It is however not stated if the scanning should continue after the first file is found. Do you see where I am getting at? When you open to door to allow different interpretations of your problem, a lot of us that see interesting challenges in everything start to think about how we can effectively make this reusable and optimized.

Over-engineering a trivial problem can actually lead to something good, you might get optimized and reusable code!

One of the solutions presented was actually pretty cool, there’s something called “LINQ to File System” which will let you create a query and ask for these files, and you can use the built in System.IO.DirectoryInfo directly to ask for a certain file-pattern. But neither of these lets you process the file In-Place. What I mean about In-Place is to process it once you’ve found it and not after you’ve found it.

My final solution ended up being a recursive method that just takes a path; this was to give the trivial question a trivial answer.

void TraverseDirectory(string directory)
{
    var currentDirectory = new DirectoryInfo(directory);

    foreach(var dir in currentDirectory.GetDirectories())
    {
           var currentPath = dir.FullName;

           TraverseDirectory(currentPath);

           var pathToMasterFile = Path.Combine(currentPath, "Master");

           if (File.Exists(pathToMasterFile))
               DoSomethingWithMaster(pathToMasterFile);
    }
}

Even though this problem was initially trivial, if we want to, we can make it very complex, challenging and educating. For instance, it’s been a while since I created something interesting with Delegates/Actions/Tasks so why not elaborate this a bit and make the result a bit more interesting?

You can always make trivial problems into something fun, exiting, educating and challenging! You just need to put your mind into it. Mainly I just want to say to all developers out there that are stuck with trivial tasks that they find a bit boring; you can make so much more out if it!

Vote on HN

Polymorphism – A Practical Example

Posted by Filip Ekberg on November 13 2008 2 Comments

Classes, inheritance and polymorphism can sometimes be somewhat hard to understand. So a practial example suits many well. Therefore this will be a tutorial where i will touch the areas of classes, pointers, inheritance and polymorphism.

So to just clearify some expressions i will add a little dictionary at the top:

Class
A class can somewhat be seen as a blueprint of your object. I.e. having a blueprint for a building, then this would be the class. Then a Constructor would build this to become an actuall touchable object.

Inheritance
When you inherit something you can think of it more like you extend this thing. I.e. having a Car and then having a Sports Car where there are some new variables to it. The Sports Car is actually a Car but it’s also extended with new properties.

Polymorphism
This is taken from Wikipedia: “In simple terms, polymorphism is the ability of one type, A, to appear as and be used like another type, B. In strongly typed languages, this usually means that type A somehow derives from type B, or type A implements an interface that represents type B”. Read more here

Pointer
For a pointer explenation look here

I will be using Visual Studio 2008 with the built in C++ compiler for the following examples.

A good practice will be to create a Bank, when you get a new assignment or just want to create something new, start by thinking about the structure, what actuall needs does this have? Well when creating a Bank i think to myself that i’d like to be able to create Bank Accounts, attatch these to People and you can go on and on.

But, for the example i will only go as far as creating a Bank, a Bank Account ( Abstract ) and a Student Bank account which is the only Bank account you can actually get.

So creating a simple diagram over the project, i got something like this:diagram So now we have a Bank, Account and Student Account, what kind of variables do we need?

Bank
Bank Name
Accounts

Account
Balance
Interest
Max Loan
Account Holder

Student Account
Amount of Deposits
Last Deposite Month

So the big difference between Account and Student Account is that the Student Account have different rules than Account and therefore calculate a lot of things differently. We won’t go through all the logics. There will of course be a window for you to evolve this application as you feel nessesary.

Now when we have a defined structure we can start by creating a new Project and it’s files. My project will be called Bank and the following files will be placed in it:

  1. main.cpp
  2. Bank.h
  3. Bank.cpp
  4. BankAccount.h
  5. BankAccount.cpp
  6. StudentAccount.h
  7. StudentAccount.cpp

When all my files are created a start by definint my program entry point, this being my main. Notice that i will be posting code snippets as pictures, because you should Write this yourself and not copy my code!

1

We prepare for an input/output stream by including <iostream> and setting using namespace std;

Now the next part is to define the Bank.h We need an appropriet constructor, desctructor and some access methods, remember to never open up member variables publicly!

The #ifndef part is important for the compiler, we dont want to define our header file more than once, because that is not nessesary!

2

I assume all the parts are clear except the last one, read more about how that pointer type works in the previous post here on my wordpress.

The implementation itself will be up to you, i will only be showing the structure, header-files and some code from main and where polymorphism is concerned!

The next file to create would be the BankAccount, remember to add #include “BankAccount.h”  to Bank.h when it has been done. Otherwise the BankAccount *accounts array will fail because undefined symbol.

Back to the third file, the BankAccount.h this is how i would structure it:

3

The part to look deeply on here is the Deposite method, watch closely, it’s defined as followed: virtual void Deposite(double amount) = 0; So this method is expected to be overrided in a inherited class and it has the return type of void and an in parameter of the type double.

Now the next file to create is the StudentAccount.h where we will be deriving from BankAccount.

4

So the following class StudentAccount is extending a class called BankAccount. So this means that StudentAccount is a BankAccount with extended properties and/or overrided functions.

Now, look closely again, here we have the virtual void Deposite part again, but without the =0, so this means we will be creating a definition for this function.

Also the Amount of Deposits and Last Deposit Month is just there to simulate some properties that might be nessesary to do something on a student accont. In my case this is for the Deposite. A Student Can’t deposite money more than three times per month, this is because a student gets 2% interest everytime they deposite money.

This is my Constructor for StudentAccount

5

As you can see, we pass the Variables Owner and Deposite back to the constructor of the base type, being BankAccount.

Now this is how my Deposite Method is implemented:

6 

Now the last think i want you to look at, is my final Main:

7

dth="450" border="0" />

I want you to try and create all the nessesary functions in Bank.cpp, BankAccount.cpp and in StudentAccount.ccp to get the following output from this Main.cpp:

8

I would happily answer any questions about this project. A link to the complete source code is here

Vote on HN

Importance of good Architecture, Structure and Patterns

Posted by Filip Ekberg on August 22 2008 Leave a Comment

Often when developing software such as websites, windows ( or any other operative system for that matter ) programs, the begining of the progress is quite simple; you have your ideas and may have some thoughts about how to implement everything. But what often is forgot when developing software is the importance of thinking ahead, thus, planning for a larger software that you have in mind.

For an example, when i started developing SmartIT Invoice i thought of it as a software that would generally help me organize my small amount of invoices. But as the years pass my company grows bigger and bigger and once im up to n-numbers of invoices, a simple List View won’t be sufficient. Therefore after implementing my Invoice software, i started thinking about how i could change everything and structure the code for helping me in the future. I had in mind that i might not always want to use the Windows Graphical Interface for input and output so as i always do, i seperate the Design code from the Logical Code. This meaning that my application has three layers. Them being:

  • Application Layer, code for display, handling window events
  • Logic data layer, database connections, objects
  • Data layer, this being the database with functions, views and procedures

By having these three layers i can easily change one of the layers without changing the next. Of course this is not entierly true, i would have to change some parts in the Logic Data Layer if i changed the DBMS.  I would however not have to change that much if i just changed the behaviour of a Stored procedure.

Again takng my Invoice softwre as an example, i recently released a software called Webexpress.nu which allows customers to create their own website and for this i need somewhat of a payment system. Of course using Credit card payments is nice and easy but not entierly nessesary. So by just adapting my Webste to the current Logic Data Layer of my SmartIT Invoice software, i could easily get an intergration that allowed me to create customer invoices that pops up on the user account, when they are online on the page of course and even directly to my software, withouth any adjustments in the Data Layer or in my Windows Software.

This proves the point that well structured code and seperate layers will help you along the way of program development.

As a side note the Data Layer in this case is a Windows DLL with .NET 3.5 code which makes it even easier to implement when the website itself is asp.net with .net 3.5.

There are a lot of good design guidelines out there which will help you structure your software better and help you understand how to always follow a pattern. A pattern doesn’t, in my point of view, have to be a pattern like Singelton etc, it can by any means be a way for yourself to regocnize your own code, thus following a pattern. Example, i often tend to use m_ before member variables and write all functions and access methods with a capital letter.

Have fun programming!

Vote on HN

Objects, Objects, Objects!

Posted by Filip Ekberg on August 8 2008 Leave a Comment

By looking on everything in life as Objects is one of the benefits from doing object oriented programming. It doesn’t really matter if you master the technique or if you are in the beginners stage, just starting with object oriented programming will open up your eyes.

Seeing how objects change your perspective on both programming and other stuff in life, i’ve notied that when i wanted to learn something like animating in Flash, knowing object orientation helps. Not particulary with the animating, but with the thoughts on how i will structure my animations.

I.e. that i have to create a move, where a part in this move occures many times, repeatinly creating this scenes and moving them around is a fairly harsh work. Looking at it from an object oriented perspective you see that you have:
A main film
An object containging the scene

When needed, you just insert a new object of the scene and you never need to repeate the procedure of creating the scene.

Using Objects isn’t always good though, when you need to store the memory on other medias than the RAM you need it to be serialized, which is not handled to good by some languages such as PHP.

The basics of object orientation is easy to learn over a few minutes, when you try to look at everthing at a new perspective, the learning period will decrease.

Let’s say that you have a Car, this car has 4 wheels, 5 doors, 6 windows and so on. The doors got handles, the wheels got air in them and so on. Seeing all these parts as Objects is a good way to play with the thoughts of object orientation. See how i apply inheritage on a car:

abstract class BasePart
{
    int m_ModelNr;
    string m_Name;
    public BasePart(int ModelNumber, string Name)
    { 
         m_ModelNr = ModelNumber;
         m_Name = Name;
    }
}

Everytime you create something, the created part / object or wathever got a Model Number and a Name, just look at carparts or a coka cola bottle.

class Door : BasePart
{
    int m_DoorType;
    int m_Weight;
    int m_Code;

    public Door(int DoorType, int Weight, int Code, int ModelNumber, int Name) : base(ModelNumber, Name)
    {
     ///.....
    }
}

The codesnippet above shows the basics in object orientation, this is a Base Class which is Abstract, which means that you cannot create an object of it.
The Door is derived from a BasePart because its a BasePart.

Vote on HN