Category: Software Development

Error Reporting

Posted by – March 25, 2009

PHP has come a long way. I used to program with Global vars then $HTTP_POST_VARS and then $_POST and even did a foreach to convert all Posted/Get-ed vars to their respective variable names. But I never faced any issue till the time I started using error_reporting(E_ALL).
My life changed. Initially I started pulling my hairs and then I realised that I will be bald very soon and then started concentrating on writing better code. Avoiding on the fly variables. Yesterday at work, I again realised the value of error_reporting(E_ALL).I created a small piece of code and tested it in a temp php file. It looked superb. I ported the code to production environment and it started breaking. I thought for a while. May be I have introduced some parse errors. I ran a php -l test and didnt see any syntax error. I read the whole code line by line. Even did a diff. Still the temporary php code was running fine and the code in production environment was not working fine. :-/

I decided to look at the code bit later. After a break of 15 minutes I decided to write a unit test and capture everything. And then I found a notice message telling me I was accessing an index that didn’t exist. I looked at my data set. It was a long range of number, 6184 to be precise and an index value 280 was not set. I looked at my temp file and found my code was not going thru error reporting and production environment was set up to halt at all notices and warnings. Damn it!

Are design patterns silver bullets?

Posted by – December 17, 2008

I hate text books thicker than half an inch. These books are, first hard to read, hard to understand. I am a man who will do it and understand it rather than read it and understand it. But today I decided to read and do and tried to understand. The object in question was a Frame Work which allowed me to build a SQLite based guestbook using MVC pattern, oops!, MVC Design Pattern. #-o

The question is do I really need to code more than 3 pages to develope a guestbook?

My answer is, no. Ofcourse you dont need a abstract knife factory which will give you a factory method that will let you create a kitchen knife to cut vegetables. I simply want to cut a piece of vegetable, say want to chop an onion to cook my ultimate Indian gravy dish. I need a knife. Now there are hell lot of knives in kitchen. Butcher knife, Kitchen knife, Chef’s knife and this and that and oh my god so many knives. So if I am planning to cook chicken dish I will need a butcher knife but also a kitchen knife to chop onions, green chillies and other stuff. So we have a abstract knife factory. Which in turn owns a factory method which in turns gives me an appropriate knife at the last momentdepending on what I am going to chopor cut.

Geez!!!

Come to procedural approach. I will develop a library of knives or say a knives holder. I will stack all my knives here and will pick up the knife which I need or say call the function whichever I need.

Aren’t design patterns leading to bloats or sometimes they turn into an overkill or…?

Are design patterns silver bullets?

Design Patterns – Is Singleton pattern evil?

Posted by – December 14, 2008

To hell with everything. Why the hell use singleton or even why the hell it is described as a pattern by GOF?

I don’t know. I have been reading, studying and even trying to code and use the same design patterns in real life. The very first and easy to understand pattern is Singleton. This pattern was defined/recognised/identified as a pattern which assures creation of one and only object throughout the life cycle of a program. Common or say classic example given is error logging mechanism. And that’s the only real world example. Rest of the examples such as file or database handles are not suitable examples. They can be said as good example but not perfect.

Why singleton is evil?

I don’t want to reinvent wheel. There are n number of reasons. The reason I found is, tight coupling. Coupling in OOPS or even Software Development is discouraged. Loosely coupled systems allow more robust testing. You can replace the modules with dummy modules, equivalent modules and test the system. In this scenario a file logging mechanism is a perfect example of singleton pattern. The mechanism can be file logger, database logger or any other logger and will not affect our system if we replace it. Coz its not tightly coupled to system. Or as I read some where it simply “gets” the information and doesn’t “set” anything in our system. On the other side a database layer can’t be singleton pattern. What if I replace my MySQL layer with PGSQL? The system may not perform as expected or worst may break.

I suggest using singleton pattern shamelessly if your system is going to be a very tightly coupled and is custom and specific to a requirement. My argument is performance counts more than portability. Ofcourse Bullet 350 is no match to Splendor and Splendor is no match to Bullet 350. So, singletons are evil but so is fire, if you use it to burn your neighbour’s house. Use fire to light up. Use singleton wisely. :-)

Interfaces versus Abstract classes in PHP

Posted by – December 12, 2008

Interfaces and abstract classes are similar because neither one can be used directly to instantiate an object. The key difference is that an abstract class can have some fully implemented methods, whereas interfaces just have method declarations. Use abstract classes when you want to maintain the same methods in all your subclasses but have some general functionality that can be shared by the subclasses. Use interfaces when the implementations will differ across most or all the methods in subclasses.

Edited on 12th December @ 13:00 Hrs
More differences are as follows:

  • Interfaces provide a form of multiple inheritance. A class can extend only one other class.
  • Interfaces are limited to public methods and constants with no implementation. Abstract classes can have a partial implementation, protected parts, static methods, etc.
  • A Class may implement several interfaces. But in case of abstract class, a class may extend only one abstract class.
  • Interfaces are slow as it requires extra indirection to to find corresponding method in in the actual class. Abstract classes are fast.

Similarities:

  • Neither Abstract classes or Interface can be instantiated.

Edited (again :-/ ) on 16th Dec @ 16:40 Hours IST

When to use what?

  • Use Abstract class for creating a bond between similar items like Splendor and Bullet 350 are similar entities, motor bikes, so extend them from abstract class like Bike.
  • Use interface for creating a bond between dissimilar items like Splendor and Civic are different from Bike but both are vehicles, have engine, have mileage, have wheels, consume fuel, and so many common behaviors.
  • Always try to use Abstract class or interface whenever you need to up-cast them to achieve simplicity e.g. accelerate and brake methods of bikes.

(not so) Short and (but still) sweet. :-)