Hi Antonio,

Yeah, I think that's fine. The idea of having an interface is to reference the next command in the next() method (or as a prerequisite), but that is optional.
I think that would be a good idea, if these specializations had enough code to justify their existence.

On 10/27/2014 02:58 AM, Antonio Goncalves wrote:

Hi all,

I'm trying to add more commands in Forge... but I have to say, I'm a bit lost. So, I've made a quick UML class diagram.

As you can see in the attached diagram (UIForge.png), most of the Java EE commands extend AbstractJavaEECommand, which makes sense. But not all of them (NewBeanCommand (CDI), ValidationNewAnnotationCommandImpl, NewQualifierCommand....). And some times you have an extra level of abstraction (AbstractFacesCommand). Same for the Java commands. JavaClassCommandImpl extend AbstractJavaSourceCommand but JavaAddAnnotationCommand and JavaFieldCommand inherit from AbstractProjectCommand.

Then, when you dive into a command (UIForgeStructure.pgn), some commands use interface and implementation (see in the second diagram JavaAddAnnotationCommandImpl implementing JavaAddAnnotationCommand), some don't (e.g. NewQualifierCommand). Is there a reason ?

Correct me if I'm wrong, but the way I see it would be (HowIseeIt.png) : under AbstractJavaEECommand you have a set of AbstractValidationCommand, AbstractCDICommand, AbstractJPACommand.... each implementing PrerequisiteCommandsProvider (this way, each command sets up its own pre-requisite). And then, under AbstractCDICommand you have all the NewQualifierCommand, NewBeanCommand....

What do you think ? Am I the only one getting a little bit lost ;o)

What do you think of re-structuring the class hierarchy ?

--
Antonio Goncalves
Software architect and Java Champion

Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev