10 Concepts that every software engineer should know about!
Posted by
Luis Majano
Jul 24, 2008 00:00:00 UTC
I just found this incredible article via digg and had lots of fun reading it. I really recommend for you to read it and get some good concepts in your toolbelt.
The top 10 concepts are:
- Interfaces
- Conventions and Templates
- Layering
- Algorithmic Complexity
- Hashing
- Caching
- Concurrency
- Cloud Computing
- Security
- Relational Databases
Tags: ColdFusion, Development
Brian Rinaldi
That's what I get for commenting before I read the article. Oscar is right. Its more about building to interfaces rather than java interfaces. Thanks for actually reading Oscar. :)
Brian Rinaldi
Didn't read the full article yet but interfaces as number 1? Really? I don't claim to be an expert on the topic but I always understood interfaces to be a workaround for Java's lack of multiple inheritance. If that is the case, then why would it be the #1 concept for "every software engineer" to know?
Luis Majano
The eternal debate of inheritance and interfaces. I believe interfaces have their play, not so much in coldfusion due to its dynamic nature, but yes in other languages like Java. Inheritance in itself is brittle and if you have even multiple inheritance, even more dependencies and brittleness (if that is a word). So I do think that Interfaces are good to understand and know when they can be applied. I find them extremely useful, especially when creating public API's.
I know there are tons of discussions about them, but this could be an interesting discussion. As for interfaces in CF, I find them useful when architecting applications, because I can concentrate on contracts and theory of communications, instead of their actual implementations. Opens up a great way to define protocols and standards.
Any thoughts?
Oscar Arevalo
A very good read indeed, and definitely these are concepts one should learn by heart.
I think that in the context of the article, it is talking about Interfaces as the concept of defining a formal contract between two entities, and is not referring to interfaces in its common Java/OO meaning. Regardless of how you develop applications, anytime your system needs to interact with something else (a user, a webservice, another system, another class, etc), you will always need to define a formal contract on how to external entities will talk back to your system. That interface provides the abstraction of what your system does, regardless of how complex it may be inside.
At least tha'ts what I think the author is talking about.