Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
 New Feature: Community Sites:
Create your own .NET community website and start earning from Google AdSense !
It's Free !
|
Implementation Patterns
|
Introduction
There are some common trade-offs that all programmers face while planning a software application. Either of the two or more options in a situation have benefits of their own. However, choosing the right option in the context may lead to achieving the desired objectives, at lesser cost. These common programming problems have been referred to as ‘implementation patterns’, since they are more to do with implementing a design , rather than designing a solution.
Which option is better for me ?
1) Should a transaction number be auto generated by the database or generated programmatically ?
2) If the transaction number is to be programmatically generated, should it be a cached set of numbers for each user (to avoid database trips to get each new number).
3) If the transaction number is to be programmatically generated should it be generated as soon as the new transaction begins, or should it be generated at the time of saving the transaction ?
4) How normalized should a database be ? If the data belonging to the parent table is ALSO stored in the child table, the reports and queries can avoid a join to the parent table in the SQL .
5) Which transactions need an audit trail, and which do not ? If we add a database trigger to all the tables , the application could slow down. On the other hand having audit trails help us to trouble shoot system errors or user mistakes.
6) Should we use Exceptions or error return codes or a suitable mix ? If we use error codes , we have much better control over the granularity and user-friendliness of the error messages that we can program.
7) How memory based should a complex data processing program be ? Should it be entirely memory based with minimal database hits , or should it be a balanced mix ? If we load all relevant data into memory, and manipulate there, the server may run out of memory and crash the application .
8) How modular should any program be ? Too much modularization can be a pain to trace while debugging. Too less modularization can lead to spaghetti coding. This is true even in Object oriented programming – too much of nested inheritances can be difficult to debug. On the other hand, programming to the implementation can mean higher coupling.
9) How stringent should a UI design standard be ? Too loose a standard leads to inconsistent and sometimes un-friendly UI. Too stringent standards needs higher programming discipline and control.
10) How much of testing should be automated using another set of programs ? Using manual testing can lead to redundant activity, and high end testing tools may not be affordable. However, programming unit tests needs more resources and discipline.
Summary
Just as there are design patterns which help architects and programmers in facing common challenges , there are also some ‘implementation patterns’. Identifying an implementation pattern, and choosing a right solution is part of any software project. I hope I have identified the typical ones. If I have not, maybe the reader can add his own observations.
|
Responses
|
No responses found. Be the first to respond and make money from revenue sharing program.
|
|