Why Object-Oriented languages rock?

I loved coming back from using T-SQL to C# or Java like I loved the view from the picture (view from the l'Esterel's mountains towards Cannes). Of course, SQL-like languages are very powerful and when you do some complicated computations that need many requests to the underlying relational database, this choice may be the right one. At least, as far as the performance is concerned.

If we leave performance concerns behind we still have the language itself. So, what did I miss in this language? I was thinking of enumerating things that I didn't like but after some thinking I conclude that I just missed object-orientation in general.

But what it means? Let's see... I was not able to use any design pattern (e.g. Factory, Strategy or Decorator) and I needed them very badly! Instead of using design patterns I had to add many ugly ifs.

Another thing I missed was abstraction i.e. I wasn't able to create abstract stored procedure and then implement specialized subprocedures. In T-SQL everything you can do is to add some more ifs :) This language is strongly data-oriented which is maybe good but it's not sufficient IMHO.

Yes - it's very vague but it doesn't make sense to compare stored procedures with OO constructs. T-SQL is just yet another language I've learnt and used after many years of writing Java/C++ code and I just wanted to express my feelings.

I don't know what are perspectives for such SQL languages like T-SQL or PL/SQL but I think they should evolve in an object-oriented way. It would be much easier to write stored procedures/classes in e.g. Java, test them and then deploy on the server. This would be a win-win situation. We would gain performance by having stored code invoked directly on the SQL server while we will still be able to use OO constructs and profit from unit tests, design patterns, etc.

Maybe there already are such languages but I just don't know them (most of them are procedural languages) - if you know some let me know.

Everybody Needs ... Unit Tests

Picture courtesy of Lotus72@flickr

... please remember people, no matter who you are, and whatever you do to live, thrive and survive, there are still some things that make us all the same: you, me, him, them - everybody, everybody! - this is a fragment of Blues Brothers' "Everybody Need Somebody" song. Nothing to do with software development but when you change the next line of this song from "Everybody needs somebody" to "Everybody needs Unit Tests" it becomes closer to software development.

I intentionally used lyrics of this song to keep everyone's attention (just a little bit) to this post. If you are familiar with TDD and unit test your code you can disregard it - I'd like to address this post to all software engineers/developers/programmers/etc. that DO NOT unit test their code.

In this post I will try (again) to convince all software developers that still don't unit test their code that it's right thing to do and it's damn simple.

Assume that Agile software development is wrong, really wrong

You don't have to be the fan of Agile movement - you can even think it's stupid, immature and doesn't help software development at all. Maybe you're right, maybe not - it's rather a question of taste. You don't have to use or like Scrum, you may think that XP is crazy and an overkill - you have right to think so. I can understand everything but PLEASE do unit test your code! Forget about Agile, forget about processes and methodologies - just unit test your code.

I just took over another project that is quite complex (of course it is!) but has NO SINGLE unit test (or any test at all). More so, there is no documentation of any kind. Yes I can read the code and see what it does - that's simple but how the hell I could know it does what it should do? How could I know it's not a mistake made by the developer who created this creature?

This code lacks Unit Test, but fortunately day after day I add more and more and I'm more confident this piece of software works.

Unit Testing once again

If you want to know something more about unit testing check out our previous articles. I will just recapitulate the most important, in my opinion, qualities of unit testing:

• unit tests document internal and external architecture of the software system


• unit tests help you and other developers to immediately see whether code "improvements" broke already existing code


• unit tests help making your software bug-free - all issues should be addressed by writing a failing test first


• unit tests together with code coverage tools improve quality of your software


• unit tests can be used as a presentation platform - you can present hard to visualise issues using unit testing green bar - green means that it works


• unit tests significantly improve team confidency in progress - if all the tests pass it means that all features implemented so far work and nobody broke the system


• unit tests improve efficiency - you don't have to perform laborious manual tests again and again after code changes, just start unit tests and watch the red/green bar


• already there but so important that worth reminding - unit tests work as a DOCUMENTATION (auxiliary or main one)


• I'm open for your propositions

I hope I convinced you to start writing unit tests - if you don't like or believe in Agile movement it's OK. Unit Testing is just an obligatory practice of every decent software developer. If you do unit test it doesn't mean you're good one but if you don't unit test you're a poor developer (I mean it).

I wonder when unit testing will be taught obligatory at every decent university. It does so many good and is so simple - people, please - write unit tests!

If you have any ideas how to convince every developer that unit testing is right thing to do I'm open for suggestions.

Originally published on AgileSoftwareDevelopment.com