Component

From Java4c

Revision as of 18:12, 25 February 2011

Components and modules, re-using

A software should consist of more as one component. Each component should be able to describe, program and test independent of the application which uses it. A component may be able to use in several applications. Then it is reuseable.

Modules are the finer granularity inside components or inside the core of the application. Each module should be able to describe, program and test independently too. Modules may be one C/h-file or a package in Java or some related files.

A class in ObjectOrientation is the more finer granularity inside modules. A class in the C-programming is a logical coherence between one data structure and related subroutines. One class may be presented exactly with one source-file.

Dependencies between components, modules, classes

If another class is used inside a class, it depends on it. Formally it depends on the signature of the methods of the class. Really the functionality depends on the functionality of the called methods.

For a independent test of a class, module or component it may be necessary to abstract the functionality of the depending stuff. The behavior of the depending stuff should be replaced by a simulation or emulation.

There are horizontal and vertical dependencies: If a class/module/component can be created, described and tested independent on another class/module/component, it is deeper in vertical or parallel in horizontal layer. If a class/module/component needs another one, it is above that in vertical layer. It needs means, in the real application it is associated to it and calls some methods from there. For the independently test all needed classes/modules/components may be able to replace.

Interfaces as dependency-breaker

There is a problem: Module_A needs some methods from Module_B and on the other hand Module_B needs some things from Module_A. Both modules are parallel in layer, but there are not able to develop and test independently.

Either the both modules are not two separated modules, the functionality should be combined in one module. - Or it should be separated using interfaces.

The interface is a language-element of Java. It defines methods with its signature, but without implementation. The description, "what should the method do, which argument values are expectable, meaning of the return value" belongs to the method anyway. In C++ interfaces are able to create in a similar kind as Java. It is a class with only virtual abstract methods and without any implementation:

class InterfaceExample {  //C++-interface
  virtual int aMethod(int arg) = 0;
};

Classic C - Headerfiles as interface

The classic C programming knows headerfiles, which ones play the role of interfaces: Function prototypes has the same appearance as a method definition in a Java-interface or a virtual abstract methods:

extern int aFunction(int arg);

The difference to Java and C is: It is static linked. There can be only one implementation in a executable, whereby in Java and C++ the interface can be implement by several classes which are instantiated independently. It is a dynamic link.

But the principle of dependency-break is the same.

Classic C- struct forward declaration as dependency break

In C and C++ there is a nice possibility to prevent to many include-necessities:

struct TheType_t;

typedef struct Example_t{
  struct TheType_t* pointer;
} Example;

Inside the Example-struct a pointer of TheType is need. But TheType itself may left unknown. It isn't necessary to know the type while compiling this struct. It is not necessary to include the typedef of TheType

If the pointer is used in the implementation (the C-file), then the type should be known. The implementation-File includes the definition of:

 typedef struct TheType_t{
   int someStuff;
 }Thetype;

Now the compiler checks the matching of struct TheType_t to TheType with its given definition. The TheType_t is the tag-name of the struct where TheType is the really type name. The writing-style with _t-suffix is recommended and usual but not a fix rule.

The forward declaration of a pointer-type straightens a complex dependencies of header files. In Java there is not a adequate possibility. A Java-interface is the way of straighten still.