Java4c - User contributions [en]

Components of vishia-Java

2011-02-25T18:56:27Z

91.54.100.91: first

==Overview==
vishia-Java is a tree of Java-files in the package-structure ''org/vishia/stuff''. All files are written by Hartmut Schorrig, www.vishia.org. They are used in some applications in profession too (with second license model). It is a conglomeration of different things, of course.

The usage of all files as jar-library if only a few files are needed - it isn't optimal:
* The usage as library will be proper, if an extrinsic application will use them as it is.
* If one of developers uses a component in another self-programmed application, it is self-evident to improve the used component with the challenges of the application. In that case the source should be present to check, change and improve.
* But on the other hand, if an extrinsic application should use that components proper, it should be well tested in a defined environment. A conglomeration can't be tested well enough.

Therefore that Java-sources are separated in some components. Any of the named component is available as a bazaar archive to work with sources. Any of this components are available as a download-file with some test environments as a application - or some test-Java-files exist.

This components are presented in the next chapters:

==srcJava_ZBNF==
* distribution on [[http://sf.net/projects/zbnf sf.net/projects/zbnf]]
* bazaar-archive on [[https://launchpad.net/zbnf/srcjava.zbnf launchpad.net/zbnf/srcjava.zbnf]]
* description, home-site on [[http://www.vishia.org/ZBNF www.vishia.org/ZBNF]]
Content of the distribution:
* The ZBNF-Parser with this Java-soruce is able to use discrete to convert plain-text but well-syntactical files into XML.
* The Java-sources includes a tool ''Header2Reflection'' which translates C/C++-headerfiles to C-files, which represents reflection-information about the data structures. It is used in a ''ReflectPro''-suite.
* A ''Zmake''-Tool is assiciated there. It converts simple make-prescripts to [[http://en.wikipedia.org/wiki/Apache_Ant ANT]]-make-files.

Further usage:
* The ZBNF is used in almost all applications of the author. It is because the applications translates some texts (for example Java2C), it needs config-files (GUI) etc.

Included:
* A commandline calling argument preparer is included in the srcJava_ZBNF-package between it is the core-package of all applications.
* Some util-components are included.
* A MessageDispatcher which separates output messages (logs, able to use for embedded applications too) is contained there.

==vishiaJava_Util==

TODO

==vishiaJava_Java2C==
TODO

==vishiaJava_GUI==
TODO

Component

2011-02-25T18:20:50Z

91.54.100.91: links

* [[Components of vishia-Java]]
* [[Components of CRuntimeJavalike]]

==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++-virtual-methods 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 <tt>TheType</tt> 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 <tt>TheType</tt>

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 <tt>struct TheType_t</tt> to <tt>TheType</tt> with its given definition. The <tt>TheType_t</tt> is the tag-name of the struct where <tt>TheType</tt> is the really type name. The writing-style with <tt>_t</tt>-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.

Component

2011-02-25T18:12:27Z

91.54.100.91:

==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 <tt>TheType</tt> 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 <tt>TheType</tt>

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 <tt>struct TheType_t</tt> to <tt>TheType</tt> with its given definition. The <tt>TheType_t</tt> is the tag-name of the struct where <tt>TheType</tt> is the really type name. The writing-style with <tt>_t</tt>-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.