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
Sat, 01 Jan 2011 16:58:41 -0800 Elements of Interface Design 2 http://vijaykrishna.posterous.com/elements-of-interface-design-2 http://vijaykrishna.posterous.com/elements-of-interface-design-2 The prequel of this post was termed Elements of Design. It was really a feeble attempt at trying to explore the various factors of Usability in any User Interface.  I am going to continue in those lines. I am going to talk about the relation between the back-end or the service layer of any system and the system's final User Interface. In particular i am going to explore the the interdependencies between the two. It is a common notion to design the architecture/databases of your system according to what you feel you want to show. This is often taken to the point where developers develop the architecture from the UI perspective. It is a sad misconception that many young, budding software engineers have, i know i did. It is sadder still that many go about building systems the other way round. That is, building UIs from the service perspective. "Everything in the Service or the database will be shown in the UI" Now, i think that it is a wrong way of doing things. Frankly, both the UI and the service should be independent of each other, with a very minimal and flexible points of interfacing. While, it is a natural notion to show all the data being supplied to you, you really do not have to. Good, interfaces are those which do not allow its users to search for results. Remember, Information above Data. Blind dumping of data, that being received from a service or database, implies one of the two things: a) Your service architecture is so good that it only returns all the relevant results, thereby automatically doing half the job for you in terms of making a good interface. b) Or, makes your UI designing job all the more difficult and tedious for a plethora of reasons i can think of right now: Too much data; Too little data; Irrelevant Data being returned by the service. Hence, by following the above stated approach (the line in quotes and italics), we have the following results: Good Service/Back-end, returning relevant data => Good UI, Service/Back-end, returning less data => UI with less information hence less value, Service/Back-end, returning more than required data => Cluttered UI, etc. All in all, the development, maintaining and purpose of the UI is too dependent on the Service/Back-end. This also leads to one other major problem: The UI will have to be changed as and when the service changes. And if that happens too often, then a ever changing UI might not be the best thing for a user, who will have to keep figuring out where the "Save" button is which was there till tomorrow. I am not suggesting an absolute decoupling. That is being crazy. I am however hinting at maintaining freedom at both levels. Let me ask you something: Does any Google API ask  you before hand the kind of tool/widget you want to develop? It just gives this brilliant set of calls and methods which can generate a whole gamut ideas in your head about the kind of tools you want to make the features that they will have. An artist comes out with the best piece of art, given a greater choice of colours and equipment. He may not use all the colours and equipment. At times he will use all the seven colors of a rainbow with an array of brushes to create a masterpiece. And at times he will just use a simple pencil to create a greater work of art in the form of a beautiful sketch. The point is that the artist needs the freedom of thought to play with things and to make his own choice. Similarly, the UI designer needs an architecture and a data pool, which he can play with. He needs that freedom. In essence, the system and architecture designer should not keep in mind the UI or how the data can be shown to the world. No! His job is to provide all the data and functionality in the world, which he can possibly think of, in a very distributed and atomic manner. His job in short is to think of everything in that domain of business or work, for which the software is being built. He has to go beyond the myopia of what is required upfront. He has to preempt and build a system that will last a decade's worth of requirements from the moment he declares it complete. When the service or back-end has such depth and power, the UI developer/designer will have all the freedom in the world to work. He will then be in a position to create something seemingly simple and brilliant.

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