Software Reality
Programming with
a dose of satire.

Site Map Search


Agile Development
 
Extreme Programming
 
Code Generation


Articles
Lifecycle
Design
Programming
Soapbox
Reviews
Cthulhu

Java Swing
Swing's greatest threat isn't SWT, it's Flash
Swing Survival Guide


 
Check out our ageing Reviews Section


Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:



Programming

Component Oriented Software (Page 6)

<< Introduction & Message Forum

<< Page 5 (Component-Oriented Software)


Component-Oriented Java

So what is the best way for Javasoft to move, in order to provide a fully Component-Oriented language?

Component-Oriented class modifiers, if added to the language, let you declare a class or interface as a type, or module.

For example:

	public type class Invoice
	{
		public double amount;
	}
	
	public module class InvoiceSession
	{
		public void process(Invoice invoice) throws ProcessException;
	}

Declaring classes with these modifiers should give instructions to compilers to treat the classes meaningfully as data or architecture. Module and Type hooks could be included in the compiled code. The benefits of the Component-Oriented programming model would be immediate through the use of introspection.

Classes that were declared with the type modifier would allow accessor methods to be assumed as method declarations with the same access as the member declaration. The compiler could also make some compile time checks to enforce the bean standards, such as the existence of a default constructor.

Classes declared as types should be assumed to be Serializable. In addition type classes should be capable of mapping to XML binding and Persistence modules, and type classes should not reference module classes.

Classes that were declared with the module modifier would allow the methods to be assumed to be services. The compiler could also make some compile time checks to ensure that their methods only passed Serializable objects. This would mean they could be exposed either locally or remotely.

Classes declared as modules should be assumed to be Remotable. In addition module classes Remote Interfaces would need to be extended to seamlessly handle other protocols such as XML Schema or SOAP method bindings.

If these features were added to Java, aspect and feature oriented extensions would have something to get their teeth into. Property methods could be designed to have hooks for prefix and postfix processing.


>> Page 7 (Aspect-Oriented Java)

<< Back to Programming

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.