in reply to Software design -- The confussion of buzzwords
hi zzspectrez,
1)If you want to dabble in oop the i suggest you go through Ali Bahrami's book titled Object Oriented Programming Concepts which starts from the rationale, basics, various paths that can be taken and all the while continuing with a single example of ATM machine which is very helpful in keeping the things organized.
2) I have read the above book as well as Software programming by Sommerville and also Jacobson.
3)Which way to go - object oriented or structured modular and within them which approach to take, all depend on the requirements and constraints. OOP is good but not the medicine of all diseases, sometimes it is the worst choice one can make. Spend as much time as possible in finalizing the requirements. Don't shy away from making prototypes if the project is big enough - the time spent here will pay off in latter stages.
4) The biggest difference i found is that in teams you got to have clear seperation of duties ( mind you it is not as easy as it sounds), clear interfaces for the various components that are being developed to avoid incompabilities and respect for deadlines as others will be waiting. So make a good estimate of time required before getting started and put 30 % buffer just in case.
5) Get set go and remember it gets better with time. i work better than i used to 5 months back when i first took up a job
good luck
1)If you want to dabble in oop the i suggest you go through Ali Bahrami's book titled Object Oriented Programming Concepts which starts from the rationale, basics, various paths that can be taken and all the while continuing with a single example of ATM machine which is very helpful in keeping the things organized.
2) I have read the above book as well as Software programming by Sommerville and also Jacobson.
3)Which way to go - object oriented or structured modular and within them which approach to take, all depend on the requirements and constraints. OOP is good but not the medicine of all diseases, sometimes it is the worst choice one can make. Spend as much time as possible in finalizing the requirements. Don't shy away from making prototypes if the project is big enough - the time spent here will pay off in latter stages.
4) The biggest difference i found is that in teams you got to have clear seperation of duties ( mind you it is not as easy as it sounds), clear interfaces for the various components that are being developed to avoid incompabilities and respect for deadlines as others will be waiting. So make a good estimate of time required before getting started and put 30 % buffer just in case.
5) Get set go and remember it gets better with time. i work better than i used to 5 months back when i first took up a job
good luck
|
|---|
In Section
Meditations