Component - Revision history

Admin at 09:16, 21 March 2011

Admin — Mon, 21 Mar 2011 09:16:35 GMT

← Older revision		Revision as of 09:16, 21 March 2011
Line 31:		Line 31:
	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.		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===	+	==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.	+	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.

-	~~Either the both modules are~~ not ~~two separated modules, the functionality~~ should be ~~combined~~ in ~~one module.~~ - ~~Or it~~ should be ~~separated using~~ interfaces.	+	Another Aspect of Interfaces: A Component should not need a special other component. It should be more commonly in its dependency-necessities. A selection of the other associated components should be possible, for example for simulation and real usage, for different platform necessities etc.
		+
		+	* While compiling only the interfaces should be present.
		+	* While static linking in C/C++ or starting an application in Java or C++ with dynamic libraries any incarnation of interface-implementors can be used. Others for testing and for several application goals.
		+	* A symbolic linkuage is possible: The selection of a dynamic library or implementation class can depend on the presence of a special library or jar-file in the file system. It is possible too to select a implementor by parametrizing, especially with a identifier string. In this kind selecting on runtime is possible.
		+
		+	===Interfaces in Java===

	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:		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:
Line 43:		Line 49:
	};		};

-	====Classic C - Headerfiles as interface====	+	====Selecting implementors while startup====
		+
		+	TODO
		+
		+	====Selecting implementors symbolic====
		+
		+	TODO Class.forName()
		+
		+	===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:		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:
Line 53:		Line 67:
	But the principle of dependency-break is the same.		But the principle of dependency-break is the same.

-	====Classic C- struct forward declaration as dependency break====	+	===Classic C- struct forward declaration as dependency break===

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

Admin: Protected "Component" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

Admin — Mon, 21 Mar 2011 09:02:36 GMT

Protected "Component" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

← Older revision

Revision as of 09:02, 21 March 2011

194.138.39.55: Dependencies defines components

194.138.39.55 — Mon, 21 Mar 2011 09:00:30 GMT

Dependencies defines components

← Older revision		Revision as of 09:00, 21 March 2011
Line 17:		Line 17:
	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.		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.	+	===Dependencies defines components===
		+
		+	If a component need the presence of another component while compiling or linking, then the component depends on the other component formally. Components should be tailored to specified other components. If any other component is need only for a special function, which isn't the main stream functionality of the component, it is disagreeable. The user of the component should attend to the other component, which isn't need really. It is additional work to do without benefit.
		+
		+	Components can be depended on any common functions of a platform, which are present anytime. For example all base class of a Java Virtual Machine and its <tt>rt.jar</tt> library can be used in the Java-sources. Then the component may be designated as '''independent of any others'''.
		+
		+	If a component depends on another specified component, it builds a system of components. Such a component-system should not be complex. '''Dependency-breaker''' are need. The dependency breakers allow a formally translation (compilation) without the presence of other complex components. For running (linking), any incarnation of the ''components behind the dependency-breaker'' should be present. But that components may be replacements for simulation etc. if necessary.
		+
		+
		+
		+	===Dependencies in a application===
		+
		+	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===		===Interfaces as dependency-breaker===

Admin: Criterion for Components: frequently changed parts without core functionality

Admin — Sun, 27 Feb 2011 06:38:53 GMT

Criterion for Components: frequently changed parts without core functionality

← Older revision		Revision as of 06:38, 27 February 2011
Line 68:		Line 68:
	* Dependencies of parts to other components: If any new part creates a new dependency to a foreign component, it should be realized as critical. Either the new dependency is desired, or the part should not be a part of this component.		* Dependencies of parts to other components: If any new part creates a new dependency to a foreign component, it should be realized as critical. Either the new dependency is desired, or the part should not be a part of this component.
	* Conglomerate of several functionality: It is okay, if the modules doesn't need other components (see ''dependencies''). A component can contain a functionality, which is not need in the typical use-cases, but it is offered for special usages.		* Conglomerate of several functionality: It is okay, if the modules doesn't need other components (see ''dependencies''). A component can contain a functionality, which is not need in the typical use-cases, but it is offered for special usages.
		+	* Frequently changes in conglomerate parts: Any change in the sources of the component builds a new release of the whole component, which should be checked for relevance for all usages. Parts, which are frequently changed, but they are not a core functionality of the component, should be dissolved from the component therefore.
	* Self-reliance: The same functionality should not scattered to several components. Only one component should be responsible to that functionality.		* Self-reliance: The same functionality should not scattered to several components. Only one component should be responsible to that functionality.

JcHartmut: /* Navigation */

JcHartmut — Sat, 26 Feb 2011 14:25:20 GMT

Navigation

← Older revision		Revision as of 14:25, 26 February 2011
Line 1:		Line 1:
	==Navigation==		==Navigation==
-	* up: ~~mainPage~~	+	* up: [[Main_Page]]
	* down: [[Components_of_vishia-Java]] [[Components_of_CRuntimeJavalike]]		* down: [[Components_of_vishia-Java]] [[Components_of_CRuntimeJavalike]]

JcHartmut: /* Links-down */

JcHartmut — Sat, 26 Feb 2011 14:22:26 GMT

Links-down

← Older revision		Revision as of 14:22, 26 February 2011
Line 1:		Line 1:
-	==~~Links-down~~==	+	==Navigation==
-	* [[~~Components of vishia~~-Java]]	+	* up: mainPage
-	* [[~~Components of CRuntimeJavalike~~]]	+	* down: [[Components_of_vishia-Java]] [[Components_of_CRuntimeJavalike]]

	==Components and modules, re-using==		==Components and modules, re-using==

JcHartmut: /* Criterion for Components */

JcHartmut — Sat, 26 Feb 2011 14:19:20 GMT

Criterion for Components

← Older revision		Revision as of 14:19, 26 February 2011
Line 67:		Line 67:
	* Able to test as entity.		* Able to test as entity.
	* Dependencies of parts to other components: If any new part creates a new dependency to a foreign component, it should be realized as critical. Either the new dependency is desired, or the part should not be a part of this component.		* Dependencies of parts to other components: If any new part creates a new dependency to a foreign component, it should be realized as critical. Either the new dependency is desired, or the part should not be a part of this component.
		+	* Conglomerate of several functionality: It is okay, if the modules doesn't need other components (see ''dependencies''). A component can contain a functionality, which is not need in the typical use-cases, but it is offered for special usages.
		+	* Self-reliance: The same functionality should not scattered to several components. Only one component should be responsible to that functionality.

JcHartmut at 10:13, 26 February 2011

JcHartmut — Sat, 26 Feb 2011 10:13:52 GMT

← Older revision		Revision as of 10:13, 26 February 2011
Line 1:		Line 1:
		+	==Links-down==
	* [[Components of vishia-Java]]		* [[Components of vishia-Java]]
	* [[Components of CRuntimeJavalike]]		* [[Components of CRuntimeJavalike]]

JcHartmut: chapter Criterion for Components

JcHartmut — Fri, 25 Feb 2011 20:13:34 GMT

chapter Criterion for Components

← Older revision		Revision as of 20:13, 25 February 2011
Line 61:		Line 61:

	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.		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.
		+
		+	==Criterion for Components==
		+	* Able to define and describe as entity.
		+	* Able to test as entity.
		+	* Dependencies of parts to other components: If any new part creates a new dependency to a foreign component, it should be realized as critical. Either the new dependency is desired, or the part should not be a part of this component.

91.54.100.91: links

91.54.100.91 — Fri, 25 Feb 2011 18:20:50 GMT

links

← Older revision		Revision as of 18:20, 25 February 2011
Line 1:		Line 1:
		+	* [[Components of vishia-Java]]
		+	* [[Components of CRuntimeJavalike]]
		+
	==Components and modules, re-using==		==Components and modules, re-using==

Line 33:		Line 36:
	extern int aFunction(int arg);		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''.	+	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.		But the principle of dependency-break is the same.