HomeTagSubmit NotesAsk AnythingLoginSubscribe Us
1. Feel Free to ask and submit anything on and get satisfactory answer
2. Registration is not compulsory, you can directly login via google or facebook
3. Our Experts are looking for yours ?.

corejava-basics: Explain the core-java concepts?

1) coupling
3)Object type casting

Explain the above mention concepts with examples.

corejava x 336
basics x 169
Posted On : 2016-08-28 06:53:24.0


An indication of the strength of interconnections between program units.
Highly coupled have program units dependent on each other. Loosely coupled are made up of units that are independent or almost independent.

Modules are independent if they can function completely without the presence of the other. Obviously, can´t have modules completely independent of each other. Must interact so that can produce desired outputs. The more connections between modules, the more dependent they are in the sense that more info about one modules is required to understand the other module.

Three factors: number of interfaces, complexity of interfaces, type of info flow along interfaces.

Want to minimize number of interfaces between modules, minimize the complexity of each interface, and control the type of info flow. An interface of a module is used to pass information to and from other modules.

In general, modules tightly coupled if they use shared variables or if they exchange control info.

Loose coupling if info held within a unit and interface with other units via parameter lists. Tight coupling if shared global data.

If need only one field of a record, don´t pass entire record. Keep interface as simple and small as possible.

Two types of info flow: data or control.
* Passing or receiving back control info means that the action of the module will depend on this control info, which makes it difficult to understand the module.
* Interfaces with only data communication result in lowest degree of coupling, followed by interfaces that only transfer control data. Highest if data is hybrid.

Ranked highest to lowest:
* Content coupling: if one directly references the contents of the other.
When one module modifies local data values or instructions in another module. (can happen in assembly language)

if one refers to local data in another module.

if one branches into a local label of another.

* Common coupling: access to global data.
modules bound together by global data structures.

* Control coupling: passing control flags (as parameters or globals) so that one module controls the sequence of processing steps in another module.

* Stamp coupling: similar to common coupling except that global variables are shared selectively among routines that require the data. E.g., packages in Ada. More desirable than common coupling because fewer modules will have to be modified if a shared data structure is modified. Pass entire data structure but need only parts of it.

* Data coupling: use of parameter lists to pass data items between routines.

Measure of how well module fits together.
A component should implement a single logical function or single logical entity. All the parts should contribute to the implementation.

Many levels of cohesion:
Coincidental cohesion: the parts of a component are not related but simply bundled into a single component.
harder to understand and not reusable.

Logical association: similar functions such as input, error handling, etc. put together. Functions fall in same logical class. May pass a flag to determine which ones executed.
interface difficult to understand. Code for more than one function may be intertwined, leading to severe maintenance problems. Difficult to reuse

Temporal cohesion: all of statements activated at a single time, such as start up or shut down, are brought together. Initialization, clean up.
Functions weakly related to one another, but more strongly related to functions in other modules so may need to change lots of modules when do maintenance.

Procedural cohesion: a single control sequence, e.g., a loop or sequence of decision statements. Often cuts across functional lines. May contain only part of a complete function or parts of several functions.
Functions still weakly connected, and again unlikely to be reusable in another product.

Communicational cohesion: operate on same input data or produce same output data. May be performing more than one function. Generally acceptable if alternate structures with higher cohesion cannot be easily identified.
still problems with reusability.

Sequential cohesion: output from one part serves as input for another part. May contain several functions or parts of different functions.
Informational cohesion: performs a number of functions, each with its own entry point, with independent code for each function, all performed on same data structure. Different than logical cohesion because functions not intertwined.
Functional cohesion: each part necessary for execution of a single function. e.g., compute square root or sort the array.
Usually reusable in other contexts. Maintenance easier.

Type cohesion: modules that support a data abstraction.
Not strictly a linear scale. Functional much stronger than rest while first two much weaker than others. Often many levels may be applicable when considering two elements of a module. Cohesion of module considered as highest level of cohesion that is applicable to all elements in the module.

Object Typecasting:
java object typecasting one object reference can be type cast into another object reference. The cast can be to its own class type or to one of its subclass or superclass types or interfaces. There are compile-time rules and runtime rules for casting in java.

Typecast Objects with a dynamically loaded Class ? - The casting of object references depends on the relationship of the classes involved in the same hierarchy. Any object reference can be assigned to a reference variable of the type Object, because the Object class is a superclass of every Java class.

There can be 2 casting java scenarios:
* Upcasting
* Downcasting

When we cast a reference along the class hierarchy in a direction from the root class towards the children or subclasses, it is a downcast. When we cast a reference along the class hierarchy in a direction from the sub classes towards the root, it is an upcast. We need not use a cast operator in this case.

The compile-time rules are there to catch attempted casts in cases that are simply not possible. This happens when we try to attempt casts on objects that are totally unrelated (that is not subclass super class relationship or a class-interface relationship) At runtime a ClassCastException is thrown if the object being cast is not compatible with the new type it is being cast to.

Below is an example showing when a ClassCastException can occur during object casting

//X is a supper class of Y and Z which are sibblings.
public class RunTimeCastDemo {

public static void main(String args[]) {
X x = new X();
Y y = new Y();
Z z = new Z();
X xy = new Y(); // compiles ok (up the hierarchy)
X xz = new Z(); // compiles ok (up the hierarchy)
// Y yz = new Z(); incompatible type (siblings)
// Y y1 = new X(); X is not a Y
// Z z1 = new X(); X is not a Z
X x1 = y; // compiles ok (y is subclass of X)
X x2 = z; // compiles ok (z is subclass of X)
Y y1 = (Y) x; // compiles ok but produces runtime error
Z z1 = (Z) x; // compiles ok but produces runtime error
Y y2 = (Y) x1; // compiles and runs ok (x1 is type Y)
Z z2 = (Z) x2; // compiles and runs ok (x2 is type Z)
// Y y3 = (Y) z; inconvertible types (siblings)
// Z z3 = (Z) y; inconvertible types (siblings)
Object o = z;
Object o1 = (Y) o; // compiles ok but produces runtime error

Posted On : 2016-08-29 15:09:35
Satisfied : 1 Yes  0 No
profile Rishi Kumar - Rishi Kumar
Reply This Thread

Post Answer
Please Login First to Post Answer: Login login with facebook -