> I'm looking for someone to give me a rough rundown of some of the OOP > terms > that I keep seeing thrown around and yet still baffle me. I've got some > elements of my application that I've been handed by other people, and they > refer to them as 'Facades' or 'Utilities' or 'Services' what are the > definitions of those? And how should they be applied within an > application.
Facades: A Façade is intended to keep your code from knowing how something is managed. In web based OO, you often need to persist a user object across the life of the session. You would not want session references sprinkled throughout your code, so you create a UserFacade. Your application asks the façade for a user, and the façade manages persistence of the user object in the session scope. Services: Services are often referenced as part of a SoA (Service oriented architecture). The easiest way I can describe them is using an analogy ;) Think of the process of going to the bank. You walk up to a teller, hand him/her your account number and tell them what you want to do. For example, I tell the teller my account number is 101 and I wish to deposit 500 into my checking account. The teller hands me a receipt and tells me the money has been deposited. You have no knowledge of exactly what the teller DID, you just know that the money was deposited. The teller performed a "service" to you. The teller can perform many other "services" like "withdraw money", "transfer money". Other services offered in the bank are "home loans", but they are offered by a DIFFERENT person (think object here). So the idea is that each object has a set of services that it offers. Those services might depend on a number of different objects in your business model, but the service hides the inner workings and just exposes the facts that it needs to perform the service. The tellerService might depend on an authentication object to verify that I have an account, an account object to deposit the money, etc. The method call tellerService.depositMoney(accountNumber, amount) is all the rest of the application has to see, and simply depends on the return (like a receipt) to know that the deposit was successful, so you hide many of the dependencies. This makes for a stronger application. Transfer Objects (TOs): Transfer objects are simply objects that contain only data. They expose this data as properties. See http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html for a full explanation. > I'd be interested to take any recommendations on more general perhaps java > based OOP, MVC and AOP related books that would be worth me reading. Many of the things you are reading / hearing are in reference to Design Patterns (gateways => table gateway pattern, DAO => Data Access Object Pattern, etc). It might make things clearer if you look into the GoF (Gang Of Four) and their book "Design Patterns: Elements of Reusable Object-Oriented Software". I highly recommend Head First Design Patterns (http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124), it's in Java but relatively easy to follow and an amazing explanation of many different patterns. HTH Rich Kroll ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Macromedia ColdFusion MX7 Upgrade to MX7 & experience time-saving features, more productivity. http://www.adobe.com/products/coldfusion?sdid=RVJW Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:273279 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
