The professional, friendly Java community. 21,500 members and growing!

The Java Programming Forums are a community of Java programmers from all around the World. Our members have a wide range of skills and they all have one thing in common: A passion to learn and code Java. We invite beginner Java programmers right through to Java professionals to post here and share your knowledge. Become a part of the community, help others, expand your knowledge of Java and enjoy talking with like minded people. Registration is quick and best of all free. We look forward to meeting you.

Layering an application code: benefits and cons

Recently, I've been programming a simple application on Swing, ad I did it the following way:

1. Create the abstract App class, who extends JFrame and implements various listeners. Initialize all the GUI in that class, assign this as a listener to whatever needs to be listened, but not to implement the listeners' methods.
2. Create the abstract AppBehaviour class, who extends App class. Implement all the listeners' methods there, but "not too detailed". That is, we create additional abstract methods to encapsulate some operations, like downloading pictures from the internet (say, abstract downloadNextPicture()). And in listeners' methods we just provide a certain logics for these methods (say, if we are connected to the Internet, and time is less then 13:00, than call downloadNextPicture()).
3. Create the concrete AppActions class who extends AppBehaviour class and implements all the abstract methods from this class.

Can you provide your thoughts about the ease of understanding and maintenance of this pattern? What are it's benefits and cons?

Re: Layering an application code: benefits and cons

Sounds reminiscent of the MVC design pattern, in which the data/logic is separated away from the actual GUI (if you are unfamiliar with this pattern, I encourage you to look it up to study). I'm not as to why in step 2, the AppBehaviour class is Abstract...do you intend to extend this class multiple times? If this class implements all listeners, how easy then would it be to change the UI? For example, what if you wished to change the UI from Swing to, say, an Android app - is the code of the 'model' class abstracted from the UI enough to make the change easily? For me a stripped down code example would do nicely to illustrate your implementation.

Re: Layering an application code: benefits and cons

Yeah, this implementation was a bad idea. I'm not able to change even a single label behaviour efficiently. That's obvious, that it's impossible to port my app to android for example... I'm a beginner programmer, I have only 7 or 8 months experience in Java, so that's no wonder. Perhaps, I need to read about MVC and other patterns.