Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Sun, 16 Jan 2011 18:10:00 -0800 Interface Inheritance http://vijaykrishna.posterous.com/interface-inheritance http://vijaykrishna.posterous.com/interface-inheritance

This friend of mine, pings me and asks my something about UML diagrams. Well, i answer his doubts and then i ask him what he was designing. That is when he tells me something i never thought of. What he told me, gave me a new insight to OOP and the fact that more the options you give to our friendly users for whom we are trying to build such brilliant technology, the more they will get confused by trying out and seriously using a gamut of all possible permutations of those options. In this case, the user is us, i.e Developers, Coders the whole class. Speaking of which, my friend told me about the most unique design pattern ever. He told me about a hierarchy of interfaces. "WHOOHA!!! Hold on!", i told my self, and tried to understand the concept, more like digest it, due to the conflict, then and slightly even now, raging in my head. He was talking about a hierarchy of interfaces wherein there was one IBaseInterface and its IChildInterface 1,2,3... and so on. This is was nothing but the inheritance of interfaces and there in lies the conflict of ideas. Interface as far as i am concerned was the perfect tool to overcome the issues with inheritance and embrace true code re-usability and freedom. Inheritance made the code rigid and tightly coupled to the parent classes. You could never quite do what you wanted to freely once you defined the object structure. It was painful. And then there were interfaces which only told you what to do. Not how to do them. The code became neater, it was fun. And then, some intelligent people mixed it. Now, lets take a step back. Inheritance all said and done did reduce a lot of our coding. If you had the correct design sense you could do wonders with the concept in designing powerful and flexible applications. But then, it things would get difficult with the client demands changed took the whole pendulum swing. Ahhhgrrrrrr!!! But, it did help a lot, there is no doubt about that. A lot of its issues were solved by interfaces. And as i kept using them more, i kept using inheritance lesser and lesser. But here i am wondering, as i always have been, why not have the best of both worlds. If you are a master designer and you can handle inheritance well, (and some things to be honest are better off done using that) why not use it! Interface Inheritance, gives you just that. The best of both worlds. Mind you you are still free to come up with different implementations for all those interfaces in the hierarchy. But you just have to remember that the Derived Interfaces also hold an implied contract of the Base/Master Interface. But the Beauty still lies in the fact that you can have multiple implementations, for all of them, and still keep them in a hierarchy. A common and valid argument i found against this approach was not use such hierarchies and simply implement all the required interfaces instead of inheriting one interface to another and implementing only the second one. While this is a valid argument, the prerogative of the design lies with the designers and the developers. You just need to keep one simple thing in mind while implementing such designs: there are implied contracts that need to be implemented and taken care of. Deal with that, and you have a very powerful tool in your hand.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Sat, 08 Jan 2011 18:01:21 -0800 Name and Address http://vijaykrishna.posterous.com/name-and-address http://vijaykrishna.posterous.com/name-and-address As a south indian, with my surname coming before my own name, unconventionally, i have always had all the issues in the world trying to fill forms right from my child hood days. My name would figure in ten different manners at ten different places. And quite frankly it is a matter of great importance to any sapient being, his identity i mean. Another such issue is that of ones address. Now, even here i have had a lot of explaining to do every time i had to change SIM cards for Mobile phones, or while getting official documents processed. So, i thought with the on set of the new age information technology, and everything having an eVersion, forms (especially) official ones will not be far behind and they might just resolve some of these issues. But, as luck (or poor efforts) would have it, it has not. Every now and again i still hear people complaining about the issue of mismatched or wrong addresses especially because there is a great diversity in the manner how a Human Being identifies himself. Now, let me clarify, while the instruments of identity are virtually the same across the globe, i.e his Name and the Place where he lives. The issue comes in the manner in which these two entities are conveyed. The diversity comes here. And this is where i feel that as responsible software developers we must ensure that the customer must be given the freedom and flexibility to express and represent his name and address the way he deems fit, not us. And do not tell me that it is not possible. The idea is to identify the atomic elements in both these things. To find the basic building blocks of a Name and an Address. Here are some that I have identified: Name: Initials, First Name, Middle Name, Last/Surname, Maiden Name, Family Name, Village Name. Address: C/o, Line1, Line2, Street, Village, Town, District, City, Province, State, Pin/Postal/Zip Code, Country, Geo Codes. Hopefully these elements cover most of the name and places in the world. Now, it might appear to you that i have stretched the limit beyond a point with the Village property in the two classes. But keep in mind that these are for the whole set of names and addresses one can think of in any context. Point is that while designing a system it is a good practice to keep such generic templates and classes of information and use the properties selectively. Like there are few properties such as First Name, Surname and Line1 or Postal Code (in Address), that you just need to have in any situation. Baring that, most other fields can be used selectively as the situation demands. For instance, if you know that your clients are in Urban areas then you can drop the Town and Village fields from your address. Similarly, if you know that your client is in say, in Italy, then you can drop the State field. So that is the point, keep you design in a manner that can fit into any situation and place. Parsers: This something that people are trying to break their heads with. Most people are trying to parse Names and Addresses into the above mentioned fields, which mind you is a very difficult task. Now I would not try and talk about the address parser, it happens to be my firm's fundamental hiring question. But then i am willing to talk about the semantics of the Name Parser, another similar problem, but more complex in nature due to the greater diversity of the sources and the way it can be mentioned. The first problem is to realize that, while most people will, not all people will write their names in the format given above, and you need to accept it. What you can do is to accept the input in a string and then parse it and show the results to the user. If anything is wrong then he will correct it and you can continue any way. Google does this in the Gmail contacts. Point is that you should always give the user the choice of representing things the way he wants to. It will be a good idea to create a feedback system here, where in the corrections can tell the system of the kind of surnames people have. That is another issue, there is no point in storing all the names in the world. Because the number of surnames are lesser in number than the number of First or middle names, it is a good idea to store them. The same can be done for the Initials, Family Name and Village name. The maiden name in most cases is a previous surname and can be recognized with the same DB. Another good idea is to identify a full stop in your string. If the full stop has come after a short burst of characters right after a space or at the beginning of the name then it is an initial. But beware, there is a pitfall here. People write their surnames in shorthand as well at times, eg: Kumar can be written as Kr. The examples are endless. One needs to identify such challenges for such problems. And in my opinion it is not all that a difficult thing to do once you have done it. I am currently working on one such parser and once the code is ready and presentable, maybe i will publish it here. Until then this is a good place to use your algorithmic skills.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu