STATICS

/
When static??
When a methods behaviors has no dependency on
state of an object
i.e.., when the method will never be instance specific.
E.g.., A class having a method which generates
random number

When we dont want a identifiers value to be

initialized again and again for every instance being
created.
E.g.., when we want to count the no of instances
getting created in a class.

/
 Static method:
JVM doesnt have to create an instance of the
class just to start running of the code.
Eg., public static void main(String args[])
Static variables and methods belong to a class
rather than to any particular instance.

Static variables and methods can be used

without having any instance of that class at all

If there are instances, a static variable of a

class will be shared by all the instances of that
class i.e. there is only one copy

/
 class hello //usage of static
{
static int count=6;
public hello()
{
count+=1;

}
public static void main(String args[])
{
new hello();
new hello();
new hello();
System.out.println("Value of count :"+ count);
}
}

o/p: Value of count :9

/
 class hello //usage of non-static
{
int count=6;
public hello()
{
count+=1;

}
public static void main(String args[])
{
new hello();
new hello();
new hello();
System.out.println("Value of count :"+new hello().count);
}
}

o/p: Value of count :7

/
Properties:
Non-static
method can access a static
method also variables

A static method cant access a non-static

(instance) variable coz there is no
instance

A static method cant directly invoke a

non-static method

Astatic method can access a static

method or a static variable /
 Example:
class Foo {
int x = 3;
float y = 4.3f;
public static void main (String [] args) {
for (int z = x; z < ++x; z--, y = y + z) {
System.out.println(z:+ z);
}
}

o/p: cant make a static reference to a non-

static field

/
Accessing static methods
and variables:
Since we dont need to have an
instance ,How can we invoke a static
method or variable without using it??

Use a dot operator on the class name

and not on a reference to an instance
Format:
Class name . static variable
Or
Class name . static method

/
Class Fruits{
Static int fruitcount=1;
Public Fruits() {
fruitcount +=1;
}
}
Class TestFruit
Public static void main(String args[])
{
new Fruits(); new Fruits();
System.out.println(fruit count: +
Fruits.fruitcount);
}
} o/p:fruit count:3
/
 Class Fruits{ //wat if we use object
reference variable??
Static int fruitcount=1;
Public Fruits() {
fruitcount +=1;
}
}
Class TestFruit{
Public static void main(String args[])
{
Fruits f =new Fruits();
Intfruit=f.fruitcount; // reference
variable-f
System.out.println(fruit count: + fruit);
} } o/p:fruit count:2
/
 We use only the object reference variable but
not the object it refers

Static member is still unaware of the instance

used to invoke it.

Compiler knows that reference variable is of the

type fruit and so fruit class static method is
run.

Compiler cares only that reference variable is

declared as class type in which the static
method is defined.

Static methods cant be over ridden but can be

overloaded.
/
 class Animal {
static void doStuff() {
System.out.print("a ");
}
}
class Dog extends Animal {
static void dostuff() { // it's a redefinition not an override
System.out.print("d ");
}
public static void main(String [] args) {
Animal [] a = {new Animal(), new Dog(), new Animal()};
for(int x = 0; x < a.length; x++)
a[x].doStuff(); // invoke the static method
}
}
Running this code produces the output:
aaa
/
COHESION
&
COUPLING

/
Coupling and cohesion:
Good OO design calls for

loose coupling and shuns tight coupling.

high cohesion, and shuns low cohesion.

OO design discussions, the goals for an

application are
Ease of creation
Ease of maintenance
Ease of enhancement

/
 Coupling:
Degree to which one class knows about another
class

Loose coupling (good):

If the only knowledge that class A has about class
B, is what class B has exposed through its
interface, then class A and
class B are loosely coupled.

Tight coupling (bad):

If class A relies on parts of class B that are not
part of class B's interface, then the coupling
between the classes is tighter
/
 class DoTaxes {
float rate;
float doColorado() {
SalesTaxRates str = new SalesTaxRates();
rate = str.salesRate; // ouch
// this should be a method call:
// rate = str.getSalesRate("CO");
// do stuff with rate
}
}
class SalesTaxRates {
public float salesRate; // should be private
public float adjustedSalesRate; // should be private
public float getSalesRate(String region) {
salesRate = new DoTaxes() . doColorado(); // ouch
again!
// do region-based calculations
return adjustedSalesRate;
}
}
/
Cohesion:
Degree to which a class has a single,
well-focused purpose
Higher cohesivenessa good thing.
Lower cohesivenessa bad thing.

Key benefits:
Classes are much easier to maintain
than classes with low cohesion
Classes with a well-focused purpose tend
to be more
reusable than other classes

/
Example:
class BudgetReport {
void connectToRDBMS(){ }
void generateBudgetReport() { }
void saveToFile() { }
void print() { }
}

/
class BudgetReport {
Options getReportingOptions() { }
void generateBudgetReport(Options o)
{}
}
class ConnectToRDBMS {
DBconnection getRDBMS() { }
}
class PrintStuff {
PrintOptions getPrintOptions() { }
}
class FileSaver {
SaveOptions getFileSaveOptions() { }
}
/
Select the two statements that best indicate
a situation with low coupling. (Choose two.)
A. The attributes of the class are all private.
B. The class refers to a small number of
other objects.
C. The object contains only a small number
of variables.
D. The object is referred to using an
anonymous variable, not directly.
E. The reference variable is declared for an
interface type, not a class. The interface
provides a small number of methods.
F. It is unlikely that changes made to one
class will require any changes in another.

/
 Answer:
E and F are correct. Only having access to a small number of
methods implies limited coupling.
If the access is via a reference of interface type, it may be argued
that there is even less opportunity for coupling as the class type
itself is not visible.
Stating that change in one part of a program are unlikely to cause
consequences in another part is really the essence of low coupling.
There is no such thing as an anonymous variable.
Referring to only a small number of other objects might imply low
coupling, but if each object has many methods, and all are used,
then coupling is high.
Variables (attributes) in a class should usually be private, but this
describes encapsulation, rather than low coupling. Of course,
good encapsulation tends to reduce coupling as a consequence.

A, B, C and D are incorrect based on the preceding treatise.

/
Which statement(s) are true? (Choose all that
apply.)
A. Cohesion is the OO principle most closely
associated with hiding implementation details.
B. Cohesion is the OO principle most closely
associated with making sure that classes know
about other classes only through their APIs.
C. Cohesion is the OO principle most closely
associated with making sure that a class is
designed with a single, well-focused purpose.
D. Cohesion is the OO principle most closely
associated with allowing a single object to be
seen as having many types.

/
Answer:
Answer C is correct.
A refers to encapsulation, B refers to
coupling, and D refers to
polymorphism.

/
Thank You