reading the SCJD book and the forum, I saw that a GuiControllerException was used for all controller exceptions was the design chosen by many.
however, I don't really get it. Simply put, I've the feeling that the handling of the exception(s) could be different depending on the UI and the exception itself.
As such, just returning always a GuiControllerException feels a bit too simple.
On the other hand, it may be a common practice in swing, so then better stick to it. I've absolutely no clue.
One of the reason why GuiControllerException is implemented by many (besides its simplicity): mostly all the time questions are answered by the same people (Roberto and me) and of course we answer from our experience and our own implementation.
David Byron wrote:I think what you're seeing is widespread adoption here of the KISS philosophy: demonstrate your competence by doing the simplest thing that can satisfy the requirements.
One of my favourite philosophies, together with YAGNI This certification is not about having the best algorithm to solve an issue or about the most performant network server, but about other important characteristics of software development like easy-to-maintain code, adding new functionality without having to make a lot of changes,... And to proof this little theory: I developed my application using KISS and YAGNI, so my application was really simple and very basic (no-frills) and I passed with the maximum score.
Roel De Nijs wrote:One of the reason why GuiControllerException is implemented by many (besides its simplicity): mostly all the time questions are answered by the same people (Roberto and me) and of course we answer from our experience and our own implementation.
And funny thing, today I already have a very different vision from the one I had when I developed the assignment. For instance, today I would certainly implement a thin client instead of a thick client, which is what I did. It would be a lot easier, mainly because my lock() method returns void, the server API would be simpler, etc. But we are always glad to try to help everybody around here!
I was just wondering about the reason behind this choice, so thanks for this clarification. In the end you may have spotted that I'm a bit at odd with this "simplicity at all cost" kind of mantra, whatever one should "normally" do on a swing app. Anyway, don't worry: once I got the reason and provided it means it's enough for the SCJD, it's ok for me. It's just a bit confusing sometime (don't do it right, do it simple).
Norbert Lebenthal wrote:don't do it right, do it simple
It might be meant cynical, but I totally don't agree with your remark. You insinuate that simple = wrong, and that's not true at all. I am currently a developer of a desktop application (we don't use Swing, but RCP) and if I am sometimes informed of functionalities a user want in the application, I'm sometimes amazed about the "craziness" of the requests. We have chosen for a simple, easy-to-use (intuitive) desktop application (created with an own framework on top of RCP). If I get a request to implement a new functionality which conflicts with the philosophy (look-and-feel) of our application, I simply don't implement it (and I justify of course why I don't do it) or I suggest an alternative which fits much better in our application philosophy.
Our own little framework makes development very easy. If you make a change to the framework, the change is visible in every screen in the application, which gives the user a consistent look-and-feel and behavior. And many other advantages. I'm convinced that KISS and YAGNI result in less and simple code, so it will be easier to maintain. So keep it simple is the right thing to do
when I wrote "don't do it right, do it simple", I thought of the EDT discussion as well. In the context of this very limited application, using properly the EDT is not "stricto sensu" needed. However, if I was to really develop a Swing app, I would make sure I understand it right from the beginning to avoid mistakes (which could end up expensive in the long run). So, to me, it feels a bit wrong of not caring of the EDT there.
It's a bit of the same for the exception handling: here we aim at Kiss and Yagni. However it feels like the GuiControllerException wouldn't be enough for a proper swing app, yet I would not know the usual pattern for such uses cases.
I feel like I've started the SCJD as a Swing newbe and that, in the end, I'll stay a Swing newbe. If I was to develop a true app, I wouldn't stand that and dig deeper. So I don't reject KISS/YAGNI, I just dislike putting in "prod" stuff where I feel I'm a newbe: I could miss obvious stuff. And usually I make sure I read/learn/test enough to avoid this "still newbe yet in prod" state, which for the SCJD looks like not needed and not the way to go. Only good point there is that I'm short on time, so...
Oh, btw, time to go to bed.
Free fire zone opened ;)
I did an internship with Swing (in 2002) and we (my classmate and I) did not have any experience at all with Swing. So we had 4 weeks to learn Swing and complete the application. Luckily they had a Swing expert who helped us out a lot. After we finished our internship the code was tuned and improved, so it was more performant and more to the Swing programming standards (they added a lot of threading).
It was simply not expected from us to deliver an improved and tuned application, simply because Swing programming is hard and difficult (and we didn't had the time). And that's the same with the SCJD assignment. It's not the intention to make you a Swing guru, but you have to learn (depending on your experiences) with a set of new technologies and Swing is one of them. And it's up to you to decide how far you go. There are people who delivered a full-fledged application (with icons, context help,...) because they had already Swing programming experience (thanks to their daily job), but it's not needed to pass the certification, neither to have a perfect score on GUI (because that would be simply unfair and it requires also that the accessors are real Swing gurus to know how Swing programming standards are perfectly applied).
And as a final note: I think there are now other technologies to develop desktop applications which are better and easier to develop with than Swing (like Swt, JFace, RCP).
thanks again a lot for taking this time to discuss such matters with me.
Regarding swing, it's unfortunately dead in the long run IMHO, due to the weight of its AWT inheritance (see for example Apple refusal to implement on its own the JDK: complexity, weight and cost of proper awt/swing porting is said to have played a big role there).
However, the principles behind it were quite successful and are now seen all over the place. That's why the more I can get first hand knowledge of it, the better (thanks SCJD).
And with a bit of luck the new JavaFx coming out of Oracle will be a proper replacement (for java only full blown cross OS ui framework, where SWT is kind of a in between solution there).