Archive

Archive for the ‘java hacks’ Category

Mutability vs Immutability in java

Whole post is a copy from [1]

Well, there are a couple aspects to this. Number one, mutable objects without reference-identity can cause bugs at odd times. For example, consider a Person bean with an value-based equals method:

 

Map<Person, String> map = ...
Person p = new Person();
map.put(p, "Hey, there!");

p.setName("Daniel");
map.get(p);       // => null

The Person instance gets “lost” in the map when used as a key because it’s hashCode and equality were based upon mutable values. Those values changed outside the map and all of the hashing became obsolete. Theorists like to harp on this point, but in practice I haven’t found it to be too much of an issue.

 

Another aspect is the logical “reasonability” of your code. This is a hard term to define, encompassing everything from readability to flow. Generically, you should be able to look at a piece of code and easily understand what it does. But more important than that, you should be able to convince yourself that it does what it does correctly. When objects can change independently across different code “domains”, it sometimes becomes difficult to keep track of what is where and why (“spooky action at a distance”). This is a more difficult concept to exemplify, but it’s something that is often faced in larger, more complex architectures.

 

Finally, mutable objects are killer in concurrent situations. Whenever you access a mutable object from separate threads, you have to deal with locking. This reduces throughput and makes your code dramatically more difficult to maintain. A sufficiently complicated system blows this problem so far out of proportion that it becomes nearly impossible to maintain (even for concurrency experts).

 

Immutable objects (and more particularly, immutable collections) avoid all of these problems. Once you get your mind around how they work, your code will develop into something which is easier to read, easier to maintain and less likely to fail in odd and unpredictable ways. Immutable objects are even easier to test, due not only to their easy mockability, but also the code patterns they tend to enforce. In short, they’re good practice all around!

 

 

With that said, I’m hardly a zealot in this matter. Some problems just don’t model nicely when everything is immutable. But I do think that you should try to push as much of your code in that direction as possible, assuming of course that you’re using a language which makes this a tenable opinion (C/C++ makes this very difficult, as does Java). In short: the advantages depend somewhat on your problem, but I would tend to prefer immutability.

 

Ref:

[1]  http://stackoverflow.com/a/214718/1433172

Advertisements
Categories: java hacks, Uncategorized

Subtleties of the OOP Principles

This is some of the definition of basic OOP principles I came across the Internet.

Abstraction:[2]

“One point of confusion regarding abstraction is its use as both process and an entity. Abstraction, as a process, denotes the extracting of the essential details about an item, or a group of items, while ignoring the inessential details. Abstraction, as an entity, denotes a model, a view, or some other focused representation for an actual item.”

Information Hiding:

“Its interface or definition was chosen to reveal as little as possible about its inner workings.” — [Parnas, 1972b]

“Abstraction can be […] used as a technique for identifying which information should be hidden.”

“Confusion can occur when people fail to distinguish between the hiding of information, and a technique (e.g., abstraction) that is used to help identify which information is to be hidden.”

Encapsulation:

“It […] refers to building a capsule, in the case a conceptual barrier, around some collection of things.” — [Wirfs-Brock et al, 1990]

“As a process, encapsulation means the act of enclosing one or more items within a […] container. Encapsulation, as an entity, refers to a package or an enclosure that holds (contains, encloses) one or more items.”

“If encapsulation was ‘the same thing as information hiding,’ then one might make the argument that ‘everything that was encapsulated was also hidden.’ This is not obviously not true.”

 

In comparison: “Abstraction, information hiding, and encapsulation are very different, but highly-related, concepts. One could argue that abstraction is a technique that help us identify which specific information should be visible, and which information should be hidden. Encapsulation is then the technique for packaging the information in such a way as to hide what should be hidden, and make visible what is intended to be visible.”

Polymorphism [1]:

Polymorphism is a long word for a very simple concept.

Polymorphism describes a pattern in object oriented programming in which classes have different functionality while sharing a common interface.

The beauty of polymorphism is that the code working with the different classes does not need to know which class it is using since they’re all used the same way. A real world analogy for polymorphism is a button. Everyone knows how to use a button: you simply apply pressure to it. What a button “does,” however, depends on what it is connected to and the context in which it is used — but the result does not affect how it is used. If your boss tells you to press a button, you already have all the information needed to perform the task.

In the programming world, polymorphism is used to make applications more modular and extensible. Instead of messy conditional statements describing different courses of action, you create interchangeable objects that you select based on your needs. That is the basic goal of polymorphism.

 

 

 

Ref:

[1] http://stackoverflow.com/a/8005176/1433172

[2] http://stackoverflow.com/a/8694874/1433172

Categories: java hacks, Uncategorized

Java Collection, List, Set

In Java List, Set or Collection all mean collection of items. But there are some subtle difference in them when you put your feet in Java world.

 

In fact, List and Set are special type of Collection in Java. Collection are just group of items where you can add or remove items, search for items and so on.

 

On the other hand, List is a sequential collection of items. For example, you may want to find 5th element from a List which does not carry enough semantics in Collection.

 

On another side, Set is yet another special type of collection where there cannot be any member duplicated. Java Util Set basically give an abstract of mathematical set.

 

Following figure from [1] explains the relation between Collection, Set and List (and others) in term of Java Interface hierarchy.

 

 

ss40

 

 

Reference:

[1] http://way2java.com/wp-content/uploads/2011/06/ss40.png

[2] http://stackoverflow.com/questions/3317381/what-is-the-difference-between-collection-and-list-in-java

Categories: java hacks, Uncategorized

.equal() and .compareTo()

Interestingly from [1]. I came to know that sometimes (I am not quite sure when) ‘==’ operator does not work for comparing two integer values.

For example, in one of my program today I found v1==v2 was returning false. where v1 = 129 and v2 = 129.  huh!!

After finding [1] now I now that this also happens. As [1] suggest, the right way of doing this is checking whether

v1.equals(v2)

Similarly for comparing String variable following syntax should be used.

s1.equals(s2) 

 

Reference:

  1. http://stackoverflow.com/questions/17601803/when-comparing-two-equal-integers-in-while-loop-the-equal-to-operator-fails
Categories: java hacks, Uncategorized