Providing Your Own Security Manager

Structural Patterns

This design pattern is all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality.
Following are the patterns under this category:

• Adapter pattern / Wrapper pattern
• FlyWeight Pattern
• Bridge  Pattern
• Composite pattern
• Decorator pattern
• Proxy Pattern

Behavioral design pattern

This design pattern is all about algorithms and assigning object responsibilities. This design pattern also helps design communications between different classes and objects and their interconnections. While behavorial-class patterns use inheritance to distribute behavior between classes, behavorial-object patterns use object composition to perform the same task.
Covering some patterns under it :

• Memento Pattern
• Mediator Pattern
• Observer Pattern
• Null Object Pattern
• Visitor Pattern
• Interpreter Pattern
• Iterator Pattern
• Strategy Pattern
• Command Pattern
• Template Method Pattern
• Chain of Responsibility Pattern

Design Principles

The principles of design include following:

• Open Close principle
• Dependency interversion principle
• Interface segregation principle
• Single responsibility principle
• Liskov's Substitution principle
• Principle of least knowledge

These all principles help us manage dependencies and coupling among the software modules in a better way. These principles expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects. This is not to say that OO is a poor tool for conceptualization of the problem space, or that it is not a good venue for creating models. Certainly many people get value out of these aspects of OO. The principles, however, focus very tightly on dependency management.

Dependency Management is an issue that most of us have faced. Whenever we bring up on our screens a nasty batch of tangled legacy code, we are experiencing the results of poor dependency management. Poor dependency managment leads to code that is hard to change, fragile, and non-reusable. On the other hand, when dependencies are well managed, the code remains flexible, robust, and reusable. So dependency management, and therefore these principles, are at the foudation of the -ilities that software developers desire.

The first five principles are principles of class design. They are:

SRP	The Single Responsibility Principle	A class should have one, and only one, reason to change.
OCP	The Open Closed Principle	You should be able to extend a classes behavior, without modifying it.
LSP	The Liskov Substitution Principle	Derived classes must be substitutable for their base classes.
DIP	The Dependency Inversion Principle	Depend on abstractions, not on concretions.
ISP	The Interface Segregation Principle	Make fine grained interfaces that are client specific.

The above 5 principles are called SOLID, derived from their first name.

Creational Patterns in java

This Design pattern is all about class instantiation. This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done. Following are the patterns under this category:

• Object Pool Pattern
• Prototype Pattern
• Factory Method Pattern
• Builder Pattern
• Factory Pattern( See also - Factory pattern example in java )
• Abstract Factory Pattern
• Singleton Pattern

LinkedList in java

Introduction

LinkedList also implements List. But unlike its brothers like ArrayList and Vector, it doesn't use arrays as their underlying implementation. In a LinkedList each element has a pointer to the element before it and to the element following it. Because of this LinkedLists and ArrayLists will perform differently from processing time and memory usage standpoints. So it gives kind of sequential access and not random access. See the post – difference between iterator and index access for more.

I am not going to get into all the differences in performance here except to say a LinkedList can add elements very quickly to its beginning or middle, and there is no capacity to manage. Ultimately performance really depends on what you are doing with your collection. When performance is a concern you are best off testing each side by side and seeing which is better for your particular application.

Common methods of LinkedList

A simple example on LinkedList

User-defined implementation of linked list in java

Further you can implement your on linkedList in java.

SimpleSinglyLinkedList implemented in java

SimpleDoublyLinkedList implemented in java

Performance of List implementations in java

List Implementations in java

Being a Collection subtype all methods in the Collection interface are also available in the List interface.

Since List is an interface you need to instantiate a concrete implementation of the interface in order to use it. You can choose between the following List implementations in the Java Collections API:

 

• java.util.Vector
  Vectors(Java 1.1) (Click on link to see tutorial on it)
  --uses array to implement list
• java.util.ArrayList
  ArrayList (Click on link to see tutorial on it)
  --uses array to implement List
  – not thread-safe, otherwise same as Vector
• java.util.LinkedList
  LinkedList  (Click on link to see tutorial on it)
  --List interface implemented as a doubly-linked list
  – access to elements is not constant time
  – better performance for frequent add/remove operations in middle of List
• java.util.Stack
  Stack

There are also List implementations in the java.util.concurrent package, which we will see later.

Here are a few examples of how to create a List instance:

List listA = new ArrayList();
List listB = new LinkedList();
List listC = new Vector();
List listD = new Stack();    

Equals method in java

Object class have methods like equals() and hashcode(). These methods have their own contracts which have to be fulfilled to override them.

Default implementation of equals() in object class

The default implementation of equals() in Object class is based on the == operator: Two objects are equal if and only if they are the same object. Naturally, most classes should define their own alternative implementation of this important method.

equals() vs == operator

Contract of equals method

Implementing equals() correctly is not straightforward. The equals() method has a contract that says the equality relation must meet these demands:

• It must be reflexive. For any reference x, x.equals(x) must return True.
• It must be symmetric. For any two nonnull references x and y, x.equals(y) should return the exact same value as y.equals(x).
• It must be transitive. For any three references x, y, and z, if x.equals(y) and y.equals(z) are True, then x.equals(z) must also return True.
• It should be consistent. For any two references x and y, x.equals(y) should return the same value if called repeatedly (unless, of course, either x or y were changed between the repeated invocations of equals()).
• For any nonnull reference x, x.equals(null) should return False.

The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any reference values x and y, this method returns true if and only if x and y refer to the same object (x==y has the value true).

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

Steps to be taken when implementing equals()

1. Use the == operator to check whether the incoming object is null. Its kind of performance optimization.
   

   public boolean equals(Object incomingObject) {
     if (incomingObject == null) return false;
   }

   
   


2. Use the == operator to check if the argument is a reference to this object. If so, return true. This is just a performance optimization, but one that is worth doing if the comparison is potentially expensive.
   
   

   public boolean equals(Object incomingObject){
       if(this==incomingObject)
           return true;
   }

   
   


3. Use the instanceof operator to check if the argument has the correct type.
   If not, return false. Typically, the correct type is the class in which the method occurs. Occasionally, it is some interface implemented by this class. Use an interface if the class implements an interface that refines the equals contract to permit comparisons across classes that implement the interface. Collection interfaces such as Set, List, Map, and Map.Entry have this property.
   
   

   public boolean equals(){
       if (!(incomingObject instanceof MyClass)) return false;
   }

   
   
   Note  : I have not checked like this:
   
   

   if(incomingObject instanceof MyClass)
     do something;

   
   
   The reason being instanceof returns true even when incomingObject is subclass object. So its important to check whether the object is type of class we are writing equals or not. If not, what is the point of writing further logic. Just return false, and leave.


4. Cast the argument to the correct type. Because this cast was preceded by an instanceof test, it is guaranteed to succeed.
   
   

   public boolean equals(Object incomingObject){
     MyClass mc = (MyClass) incomingObject;
   }

   
   
5. For each “significant” field in the class, checks if that field of the argument matches the corresponding field of this object. If all these tests succeed, return true; otherwise, return false
6. Writing the complete equals function
   Finishing whole steps:
   
   

   public boolean equals(Object o) {
     if (o == null) return false;
     if (o == this) return true;
     if (!(o instanceof MyClass)) return false;
     MyClass mc = (MyClass) o;
     return ... // compare members of mc
   }

   
   


7. When you are finished writing your equals method, ask yourself three questions: Is it symmetric? Is it transitive? Is it consistent?

Thanks

Working with Directory tutorial

Following topics can be covered in this tutorial

• Creating a Directory recursively
• Copying a Directory or file
• Traversing files and directories
• Printing the directory hierarchy
• Display all the files in the directory
• Display all the directories in the directory
• Getting the Current Working Directory
• Getting the last modified time of a File or Directory
• Listing Files or Subdirectories 
• Deleting a File
• Deleting a directory in java
• Checking whether directory is empty or not
• Getting the parent directory of a file in java
• Searching all files inside directory

Serialization tutorial index

Internalization tutorial index

Java IO tutorial

Java IO : Introduction

What is Stream in java IO?

• Type of Steams in java
• The Stream Classes (Covers various classes present in java IO)
• Where do streams come from?

Reading from Standard input in java

Control flow in java

Conditional statement in java - if else statement and ? operator

Switches in java
Loops in java
Continue, break and return

Regex tutorial in java

• Regular expression introduction in java
• Common symbols to represent regex pattern in java
• Using Regular expressions with String in java
  Using regular expressions with String.matches()
  
  
• Regular expressions using the Matcher Class
• Regular expressions using the Pattern class
• Application of regex or regular expression

AOP : Tutorial

Need for AOP
Introduction to AOP

Spring AOP vs AspectJ
AOP support in spring

• Proxy method
• Using weaving

Advices would have been explained in above mentioned points. So we can talk about them now.
Advice types in spring
Terminology of AOP ( though some part covered in above points)
Writing the Aspect class
Using xml style configuration
Using annotation style configuration
About joinpoint object
Pointcut expressions
Binding parameters to advice
Named pointcuts
Implementing After and AfterReturning Advice
Exception handling using AOP
Implementing Around Advice in aop
Pitfalls of AOP

OOP in java

Encapsulation
Class in java

• Field Values or Properties
• Methods
• Types of methods
• Pass by value or reference

Object creation and destruction
Access Control in java
Nested classes
Inheritance in java

• Inheritance : cpp vs java
• Using super in java
• Multilevel inheritance : Calling order of Constructors
• Abstract classes
• Interfaces in java
• Multiple inheritance in java
• Inheritance among interfaces in java
• Multiple inheritance in java
• Abstract classes : cpp vs java
• Abstract classes vs Interfaces
• Abstract-Interface or skeletal implementations
• Various interfaces
• Abstract-Interface or skeletal implementations 
• Constant Interfaces 
• Marker Interfaces
• Final in java: Preventing inheritance

Polymorphism in java

• Array of base class objects
• Casting and instanceof

Java Tutorial - File IO

 

Nested Class : Index

Nesting of classes : Introduction

Types of nested classes

1. Static member classes
   
2. Member classes
   
3. Local classes
   
4. Anonymous classes

Scope and inner ness of nested classes

How inner classes work in java?

Generics : Index or TOC

Generics in java 

Motivation behind Generics-Dealing with casting of objects
The Generics Facility  
Creating a Generic class
Writing a Generic Method

Naming convention in generics
Generics are syntactic sugar - Type Erasure with Generics
Advantage of Generics



Subtyping a generic type

Wildcards in Generics
Generics classes in java vs templates in c++


Some mistakes to be avoided with generics:
Beginner's mistake of using Object as type parameter to make method generic
Generic methods: How generic are generic method?
Wildcards in Generics 
Bounded parametric types 
Covariance, contravariance, invariance
Upper bound boundedness in generics
Lower bound boundedness in generics
Multiple bounds in generics
Get and Set principle in generics
Restrictions on wildcards in generics
Expressing dependencies in type parameters : Wildcards vs type parameters

Class objects as type literals
Generic types are not covariant
Type erasure in generics
Making return type of method as generic
Covariant parameter types

Set tutorial in java

A Set is a Collection that cannot contain duplicate elements. Set models the mathematical set abstraction. The Set interface contains no methods other than those inherited from Collection. It adds the restriction that duplicate elements are prohibited. Set also adds a stronger contract on the behavior of the equals and hashCode operations, allowing Set objects with different implementation types to be compared meaningfully. Two Set objects are equal if they contain the same elements.

 

Set Interfaces

• Set Interface in java
• SortedSet Interface

 

Set Implementations

• LinkedHashSet
  Creating a set that retains the order of insertion
• HashSet
HashSet class in java
Converting ArrayList to HashSet
• TreeSet
  TreeSet class in java – constructors

 

Operations on Sets

• Operating on a set
• Bulk Operations : Operations between the 2 sets in java

 

SortedSet

• SortedSet Interface
• SortedSet Operations
• Standard constructors for SortedSet interface
• Range-view operations on SortedSet interface
• Creating a sorted set

 

How is set implemented internally?

Set and serializations

Sets and synchronization

Iterators returned by set implementation and concurrent modification

When to use which set implementation?

Performance of set interface implementations