A Java object is considered immutable when its state cannot change after it is created. Use of immutable objects is widely accepted as a sound strategy for creating simple, reliable code. Immutable objects are particularly useful in concurrent applications. Since they cannot change state, they cannot be corrupted by thread interference or observed in an inconsistent state. java.lang.String and java.lang.Integer classes are the Examples of immutable objects from the Java Development Kit. Immutable objects simplify your program due to following characteristics :
Immutable objects are simple to use test and construct. Immutable objects are automatically thread-safe. Immutable objects do not require a copy constructor. Immutable objects do not require an implementation of clone. Immutable objects allow hashCode to use lazy initialization, and to cache its return value. Immutable objects do not need to be copied defensively when
| simple rule: | |
| we have object A and object Z. | |
| if we have a pointer from object A to object Z then its aggregation.(no pointing from Z to A ,since it maks a simple relation). | |
| if object Z cannot exists in the system without object A, then its composition. | |
| its not that hard, even more ITS NOT THAT USEFUL. why? beacuse no body uses this stuff to the fine lines, its a loose model that lets you grasp what you want from the system. |
| <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager"> | |
| <property name="entityManagerFactory" ref="entityManagerFactory" /> | |
| <property name="dataSource" ref="myDS" /> | |
| </bean> | |
| <tx:annotation-driven transaction-manager="transactionManager" /> | |
| <aop:config> | |
| <aop:pointcut id="defaultServiceMethodTxPointcut" | |
| expression="execution(!@org.springframework.transaction.annotation.Transactional * *(..)) |