• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java-programme "Mise en Place"

 
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i've noticed that my programming is pretty chaotic...i.e. with reference to naming conventions, and communication between my methods and classes etc.
i've noticed that i spend almost as much time reorganising my work as i spend programming (not to speak of debugging )

...ergo my (probably very silly question)...

how do you start off writing a java programme?
(e.g: what individual steps do i need to take to ensure a fast and structured solution which avoids having to rename variables, or parameters(after the actual programming has been taken care of etc...
)

maybe someone could give me a short, step by step guide using a simple example....for example:

problem:
write a method which computes the number people who have resided in one of many hotel rooms (received as a parameter) from 1999 till any given date(received as a parameter) based on a guest list sorted according to any given criteria.

i hope my question is clear.

thanx, i'd appreciate any help i get...

-W.O.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a great technique called Test Driven Development or TDD. It involves writing a test that defines what your code should do and then making the test pass. The trick is to start with the smallest possible thing you can think of and build more tests and more solutions until you're done.

Here are two exercises that let you watch over Robert Martin's shoulder. This is a pretty amazing experience.

http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata

Try those a couple times each and let us know how it goes. Oh, he's using JUnit for the tests. Download it from http://junit.org/index.htm. Give a holler if you need help setting it up.
 
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Wolfgang
The question that you have asked here is very general rather than java based. And lot of programmers can speak at lengths when asked this question.

The very basic principle of software development is

the more you sweat in peace, the less you bleed in war



Putting it to software line, it translates to that as much time you spend designing your program, the lesser problems/reorganization you face while coding.

For designing you can use top down or bottom up approach. And then write (on paper) the entire skeleton of your program. (Now coming to java) Like the classes that you will require. That can be classes that will have the functionality and ones which will only hold the data used by your program in a structured way. Then you plan your methods in the classes having the functional logic. Then you can decide upon the variables and getter and setter methods of the classes which will hold your data. And last but not the least the class which will create objects and call the methods from your classes to run the functionality which you have implemented, yeah you guessed it right, the class with the main method.

I hope it helps.

Cheers!
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Putting it to software line, it translates to that as much time you spend designing your program, the lesser problems/reorganization you face while coding.



Be aware that this is a controversial point of view. Some projects like the Space Shuttle get fabulous results with lots of design up front (at fabulous cost) but others get by quite nicely (and very quickly) designing one test at a time.

I'd suggest you practice both ways for a bit and learn to travel as light as works for you.
 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:


Be aware that this is a controversial point of view. Some projects like the Space Shuttle get fabulous results with lots of design up front (at fabulous cost) but others get by quite nicely (and very quickly) designing one test at a time.

I'd suggest you practice both ways for a bit and learn to travel as light as works for you.



Which probably has at least something to do with their ability to have well-defined and precise requirements. What happens when a client needs something, but they can't precisely define what it is? What if those requirements are changing in unforseeable and significant ways at a rapid pace? Spending too much time in design in that kind of scenario leads to nothing getting done because by the time the design can be worked out the requirements have changed, if they were ever truly defined to begin with.
 
mohit bahl
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Which probably has at least something to do with their ability to have well-defined and precise requirements. What happens when a client needs something, but they can't precisely define what it is? What if those requirements are changing in unforseeable and significant ways at a rapid pace? Spending too much time in design in that kind of scenario leads to nothing getting done because by the time the design can be worked out the requirements have changed, if they were ever truly defined to begin with.



I totally agree with it but I think you will agree that developing on requirements which are not signed off will never do you any good. And when you develop like this you are spending more time reorganizing rather then delivering.
If you really foresee that the client needs are bound to change, then evolutionary development will be better. That is you take a round of the development lifecycle with one particular requirement rather then developing the full blown system at once.

But I think we are driving away from the topic of this thread and for that what I will suggest is when the requirements are frozen, you design. While designing pick up/mention as many reusable components as possible and then go ahead with development.

cheers!
 
reply
    Bookmark Topic Watch Topic
  • New Topic