This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
I have this program a database manipulation program as good java program do i have to use model view controller design pattern which i separate the GUI part, the data manipulation part, and the that one that control the two parts of the program? My senior colleagues say that it is more confusing to debug than the standard inline style programming where u can see all the part of the program in one class. I'm doing this pattern in all of my program, and they said when they try to to look at my program they have to go to another class to look what that method do.... (data manipulation part) but all the method does is to retrieve data and save data to the database. They are forcing me to use inline style of programming to standardize with them, which i'm not custom of doing, they said the code is not reusable anyway to separate them into this MVC pattern. My questions are... is that so? if the code is not reusable do i have to do it in an inline style? Does java design pattern can be used only for reusable code? Am i right in using design pattern in my code? What are the advantages of design pattern vs inline style programming?
The thing about patterns is that they are each good solutions to particular categories of problem. Applying any pattern without consideration of its appropriateness can be very dangerous. MVC is a solid approach for building maintainable software. I can't really say much more about it's applicability in your situation, because I don't really know much about what your code is needed for. From your introductory post I understand the following:
you are applying MVC to every programming task you are asked to do.
some other colleagues find your code hard to "debug"
some other colleagues claim that there is no need to reuse the code you are writing.
I hope you don't take this personally, but I also learned from your introductory post that you are not skilled at composing and phrasing a bulletin board post in English. Your initial post is all jumbled together with no clear separation of ideas. I really hope your code is not like this. The best way to make code easy for others to "debug", is to make sure that you have found all the bugs before anyone else sees it (see "unit testing", below). The next best way is to make sure every line of code, method, variable and class, does just one job, does it well, and expresses its intent as clearly as possible. How much effort do you put in to choosing good names in your code? Can you express the responsibility of each class or method in a simple sentence ? Have you ruthlessly removed any duplication ? The problem of "to understand your program I had to look here, then here, then here etc." is a very common complaint from people unfamiliar with Object-Oriented software. As a comparison with "spagehtti" code (a tangled mess of "goto" and procedure calls), it's sometimes referred to as "ravioli" code (lots of small very similar-looking lumps with nothing to connect them apart from a bit of sauce). My guess is that your colleagues find your code difficult to understand, and point to your use of MVC as the cause. This might be because they have not read much/any good O-O code, and don't know how to read it or what to look for. As for the "no need to reuse" argument. I find this a bit spurious. Do you and the team really change to a completely different problem domain or programming language each week? If not, there must be some commonality in what you are doing. If you make what you write fine-grained enough, there will always be something you can re-use even if only by cutting-and-pasting. You don't mention if any sort of "maintenance" is ever required on this sort of software. Is each chunk of code written, used, then thrown away, or is anything ever changed later to track changing requirements ? If the code ever needs to be changed after its first written, it's worthwhile considering what patterns to use, and applying them in a way which enhances maintainability. Finally, from your mention of "hard to debug", I assume that a fair amount of you and your colleagues time is spent debugging. To me this sounds like a symptom of a haphazard development process, and in particular one with too few "unit tests". Over the past few years, the single thing I have learned which has increased both my productivity and code quality the most is the use of unit tests. I now hardly write any code at all without first writing some code to test the desired functionality. After I have written the test, I run it to make sure that the requirement is not already met. Then the test acts like an "executable specification" - I keep coding until it passes. As soon as the test passes, it then becomes useful as a "regression test". I can tinker and refactor the code to make it the best I can, and run all the tests after each small step so I know it always keeps working. If anyone finds a "bug", first write a test to show it, then fix the code until the test passes. Then that test also becomes a regression test to make sure that that fault never occurs again. Since I got into using unit tests in this manner, I have never needed to use a "debugger". The tests tell me as soon as anything stops working, and I change the code in such small steps that the problem is usually immediately obvious. Would you be willing to share any of your code with us for more detailed comments and suggetsions? If you put the code here, please use UBB CODE tags to preserve your layout and formatting. If not, a few links to some source code on the web would be great. Thanks.
I fully agree with Frank and want to add one observation: It is really hard to test a chunk of code that does too much. So you will probably find that by following the One Responsibility Rule, by decoupling your design by usage of design patterns like MVC and the like, the testability (and therefore maintainability) greatly improves. In fact, when using the test strategy described by Frank (often referred to as "Test First Development"), it gets really hard to *not* use such patterns...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Feb 12, 2002
First of all, thanks for your reply Frank, sorry for my first post i admit that it was not so well composed and the ideas were fragmented. This was because i had so much in thought that time and I type as my mind dictates it. I agree with you Frank that my colleagues find my code difficult to understand because they are not familiar with Object Oriented Programming they are not used to seeing that kind pogramming style, all they know is VB style programming which is an "inline coding", which they used in their last version of their project.In short sentence --> They are in Java's learning curve. The nature of developing a project here is, they give us the look of the GUI (the user interface part) they give us the database tables involve and its up to us if we would like to change look of the GUI (or retain what they have given to us) and make it interact with users. Then they'll test it if they find any bugs then the programmer responsible to it will fix it, if that programmer is occupied with other work, then they'll find another idle programmer to fix it, until all the module programs are free of bugs then they will compile it together to complete the whole project. When my program contains some bugs and it was assigned to be debugged by my other colleague, then he/she starts to complain. You said Frank that whenever you start programming you never fails to write some code to test, you keep wrting until it passes. Can you give some example please? I'd like to try your kind of approach in attacking problems with programming because I think with that approach less time will be needed in debugging a programs.
see the junit website. (for a quick intro read the "test infected" article that comes with the download). One of those almost painless additions to the programming toolbox that pays huge dividends. Strongly recomended if you have never done any test first programming. [ September 17, 2002: Message edited by: Jeremy Thornton ]
Frank, I found your restraint admirable. I personally nearly blew a gasket when I read poor Richard's first post. Richard, you are on the right track. Keep it up. Your colleages are not just on the Java learning curve -- they are resisting learning Java. They are trying to do non-OO programming in an OO language, and that's a very, very bad idea. My question is, what does your management think about this? Why are you using Java if the team isn't willing to spend the effort to learn it and do it right? Why isn't there a "mentor" for your team? Has your management considered hiring someone to help your team out and teach them how to do this the right way? Kyle