Which combination of design patterns could I apply to my problem?
Hi all,
I'm facing the problem I'll try to explain.
I've the following abstract definitions.
1) Business Object - It's any object of my business that application has to handle (it might be a currency, a bank, a customer...a report etc)
2) Transaction .-It's is not the transaction concept of DBMS, but a set of coordinated application states which target is to create, update or delete a Business Object, by interacting with user.
3) Transaction State- A sigle state of application within a Transaction, in which app can accept user inputs
4) Begin State- The initial state of a transaction
5) End Sate- The final State of a Transaction
6) Middle State- Any state of transaction, between begin and end state.
My app should be a three tier app (presentation, business, data).
My question is. Could you suggest any document or link I could find any response or could you give me any suggestions on which combined OO design patters I could follow for this?
Thanks a lot.
Fil
# 3
What makes you think you need patterns in the first place ?
Try designing the solution as you see fit. If you have a problem, get stuck on inelegant constructs, or need something better, post your solution so far and people might be able to give you advice, possibly including some pattern that might help and that you have overlooked.
Patterns are not magic solutions !
# 4
It is obvious that the OP is a beginner and is still in the baby stages. If he/she wants to learn how to design software using design patterns, then that is a good step forward.
Patterns are not magic solutions, as mentioned. However, using design patterns is a best practice in software development. Applications can be designed without the designer referring to design patterns for assistance. Things just take a bit longer.
Structured programmers and old-style Perl hacks typically have difficulty understanding the proper place, usage and application of object-oriented design patterns. Many Computer Science professors and instructors have been teaching a long time and don't have "hands-on" experience with object-oriented software design. Especially those with tenure. What the undergraduate CS student eventually gets in Object-Oriented Analysis& Design 101 is some surface level theory and opinion.
To learn how to combine design patterns to solve problems, it takes a dedicated student that is able to teach themselves and solve problems on their own. Students that post their homework questions to internet forums for quick answers are typically the source of failure in most IT projects that fail.
# 5
> Structured programmers and old-style Perl hacks
> typically have difficulty understanding the proper
> place, usage and application of object-oriented
> design patterns. Many Computer Science professors and
> instructors have been teaching a long time and don't
> have "hands-on" experience with object-oriented
> software design. Especially those with tenure. What
> the undergraduate CS student eventually gets in
> Object-Oriented Analysis& Design 101 is some surface
> level theory and opinion.
If you are going to be wrong you might as well make it a wopper.
One of the authors of "Design Patterns" is a "Computer Science professor".
OO has been around for thirty years. Concepts in OO existed before that. And most of the time those sorts of concepts come from educational institutions. And it is likely that educational institutions are early adopters as well. Thus one was morely likely to have learned C++ in college in the 80's than one was to actually get a job using that language. Certainly at the time there was learning going on all fronts.
Now it is certainly possible that there are incompetent professors but that has nothing to do with ones background.
# 6
> Now it is certainly possible that there are
> incompetent professors but that has nothing to do
> with ones background.
And of course there are exceptions :o)
In the past few years I've grown a bit sour toward the output of the CS curriculums. Many individuals that I've interviewed with CS degrees tend to be lacking in the OO design space. Which is surprising in these times. Questionable recruiting activities and ficticous resume embellishments by account managers at consulting companies don't help things either.
The strategy that I've adopted is I want to see examples of your work and want you to come in the interview with a laptop and I want you to demonstrate and explain what you did. If you can't come in with a laptop, send me source code and design docs in the mail.
