This message will be repeated in english.
Har du någonsin stått inför dilemmat hur metoderna och deras paremetrar i en klass skall se ut?
Skriv anropet först så får du en känsla för hur användaren vill göra.
Hur en metod ser ut kan vara viktigt, det kan till och med påverka arkitekturen.
Have you ever been sitting without being able to work just to figure out the name and parameters of a method?
Start by writing the call to get a feeling for the user's preferences.
The looks and work of a method can be important enough to have an impact on the architecture.
2007-10-06
Subscribe to:
Post Comments (Atom)
3 comments:
Predict the right parameters for a certain function can become easily a Fortune teller work. As the software matures you find out that the parameters aren't enough, or that this or these ones aren't needed, or that these parameters can be used as a constant in your config-settings file. For my own experience, the best solution is to keep these methods together, labeled properly and grouped practically under a meaningful regions set. It means easy to spot and update. Personally I always tend to add functionality to the methods as the software grows, maybe I need to improve my Hack-Cast to make a decent architecture design before coding.
The right expression in my last post was Hack-Forecast :)
Regions are only good for keeping methods in the same class in order.
When writing methods for a whole solution, the decisions grow with a cartesian rate.
The solution is, of course, refactoring; just as you said.
Post a Comment