Developing an Object Oriented Credit Card Transaction Processor - Conclusion
(Page 6 of 6 )
We have covered a lot of ground in this article. We have discussed and demonstrated the principles of loose coupling and designing for interfaces rather than implementations. We have introduced the concept of Factory methods as a way to defer instantiation of an object to an intermediary (the Factory) to allow the client to remain independent of the object creation process, which allows the client to simply request an object and get it back, without knowing what is required to create that object, or even the name of the class the object belongs to.
This could be extended into a substantial discussion about general practices of Object Oriented design, but that isn't necessary. If you found this article helpful, feel free to contact me and tell me what you liked and what you did not like. If you would like to read more about some of the design concepts we discussed, check out "Design Patterns" (Addison Wesley 1994).
David Fells is the IT Director for Turning Minds Media (www.turningminds.com). He is 23 years old and has been in the IT industry for five years. He is MCDBA and MCSE certified. He is proficient in Transact SQL, MySQL, PHP, C#, Perl, ASP, CSS, Javascript and Flash.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
