cimplBlog_banner.png

Cimpl Blog

Your Weekly Insights on How to Manage your Enterprise Digital Footprint.

Always try to be Dry and Solid– Object-Oriented [OO] Programming Principles (Part 1)

Posted by Caroline Le Brun | November 12, 2012 11:50 AM

Software Devlepment Blog

Nope… I am NOT talking about your choice of deodorant.

Those two acronyms represent what I think are the most important principles of software development in the OO (object oriented) world. Some of them not only apply to OO but to any kind of development that you might want to do.

I will talk briefly about them in this post but let’s start about on why we should use it.

*Please note that Etelesolv changed its

company name to Cimpl in 2016.

Writing GOOD code is not only about getting your application/functionality to do what you want it too. It also has to be (among other things) simple, clear and maintainable. Wherever you work, during the development process, any code you write will most probably have errors (you know it will!!) and will be read by other developers. How you write that code will have a huge impact on how easy it will be to correct errors and make other adaptions or changes to it. That impact will be felt as the amount of time required to do the correction/change and time means cost.

So the principles that I will present are tools to help make the code you write more (let’s say) developer friendly.

Let’s start with DRY.

DRY stands for “Don’t Repeat Yourself”. We as developers many times do not see how many duplicates of code we write. It is very easy to copy and paste and normally you would think that “if it’s working over there it should probably work over here with some minor changes”. But when you repeat a code, you multiply the number of potential errors and change requirements by the number of repetitions. And even worse, it leads quickly to spaghetti code. Consider the code below…

public string listByInput(string input, int[] values) {
	var result = "";
	switch (input) {
		case "sample1":
			foreach (var value in values) {
				result += "," + value.ToString();
			}
			break;
		case "sample2":
			foreach (var value in values) {
				result += "|" + value.ToString();
			}
			break;
		case "sample3":
			foreach (var value in values) {
				result += ";" + value.ToString();
			}
			break;
		case "sample4":
			foreach (var value in values) {
				result += "." + value.ToString();
			}
			break;
	}
	return result;
}

Apply now and be part of the team!

Imagine that the client reports that the result list is “,1,2,3,4” and the correct would be “1,2,3,4”. Ok it is a quick fix but how many other places does that correction need to be applied to? The client just detected the bug on the path that the application passed at that moment. What about the other possible paths in that part of the code. That sample is a very short sample. Imagine it is in a file with hundreds and maybe thousands of lines, or even a code repeated in different files throughout your project.

Now consider that other code:

private string joinValues(string separator, int[] values) {
	var result = "";
	foreach (var value in values) {
		result += separator + value.ToString();
	}
	return result;
}
public string listByInput(string input, int[] values) {
	switch (input) {
		case "sample1":
			return joinValues(",", values);
		case "sample2":
			return joinValues("|", values);
		case "sample3":
			return joinValues(";", values);
		case "sample4":
			return joinValues(".", values);
	}
}

Both codes do exactly the same thing. Both codes would have the same problem reported by the client. Which one would require less points of attention to apply any correction?

Code repetition always leads to multiple points of maintenance, making corrections or changes more difficult, and more prone to be incomplete.

Avoiding repetition also improves the readability of the code. A small simple function is easier to read and understand than a huge complex one.

Consider these steps to reduce the complexity and code repetition:

  1. Break your huge functions as a sequence of higher level steps;
  2. Write every step as a separate function;
  3. Repeat the process with the new functions until you have a set of meaningful atomic functions
  4. Reduce the repetition by eliminating identical functions and merging very similar functions into a single one.
  5. If it is possible and makes sense, make the atomic functions available to be reused by other parts of the application.

It is important to say that this is a PRINCIPLE, not a REQUIREMENT.

How much you stick to it will depend on your own needs, experience and knowledge of the application you are trying to build.

On the next part of this post I will start talking about the SOLID principles.

Kaizen eBook - A Guide to IT & Telecom Management

 

Continue to Part 2...

Topics: Programming

Written by Caroline Le Brun

As a 16-year marketing veteran, Caroline’s experience extends across multiple industries. Since she joined Cimpl, her successful marketing campaigns have increased the company’s online and community presence, in addition to Cimpl’s footprint and appearances in new or traditional media (such as the Globe and Mail). Caroline is a specialist in communication and social media. She works closely with analysts to keep track of and adapt to the trends and changes in the industry of IT: Technology Expense management, IT cost optimization, Technology trends. Her leadership conducts Cimpl’s marketing team toward ever greater achievements. Caroline is also an exemplary citizen. Outside of work, she is involved in TEMIA, the Dorval Day Camp, and other community organizations. She has a Bachelor’s degree in Commerce from Concordia University and a Master Certificate in Integrated online Strategies from the University of San Francisco Intensive Development program.

Follow Us!

What is Telecom Expense Management?
Self-Assessement_Checklist
Customer Stories: Access now!

Subscribe to our Blog