Message Board
| Message Board > Programming > Some very interesting design patterns |
| August 4, 2012, 11:06 | |
|
Zomg
None 641 posts |
While preparing my project for Software Development, I came across some very interesting design patterns: 1. DAO (Data Access Object) --------------------------- It abstracts and encapsulates the access to persistent (remains active throughout the app) data (such as data in a database). This way it eliminates the problem of having your code dependent on proprietary APIs. Simply do insert(), update(), delete(), create() and the underlying implementation can be whatever!  Very powerful stuff.http://java.sun.com/blueprints … cessObject.html 2. Factory pattern ------------------ Analogous to a real factory. Instantiating objects in your classes creates dependencies between those classes and those objects. This is bad practice. In order to solve this problem, a factory object is created. This factory object abstracts away the creation (Dependency Injection) of the object. e.g.: Code: //old, dependent way: MyObject myObject = new MyObject(); myObject.use(); //new, decoupled and abstract way: MyObject myObject = ObjectFactory.getObject("myObject"); Advantages: Dependency injected code, decoupled code, easier for testing! 3. Aspect Oriented Programming using the Proxy pattern --------------------------------------------------- There are two classical methodologies of programming: Functional/procedural programming: Your program consists of a set of functions/procedures that call each other and when the final function/procedure is run, your program ends. Object oriented programming: We solve the dependencies problem in the previous methodology by isolating behavior and state into Object types. This way the programmer has a better view on his code and there are less dependencies. The problem with this approach is that not everything in your problem domain can be classified as an Object. For example: logging. Logging only provides a support role and does not solve a particular business problem. It doesn't add value to your business code. However, if we want to log everything, we'll have to use a logging framework such as log4j or we'll have another or our own logging object. The problem with this is that every time you are using the Logging object in your classes, you are making them dependent on that Logging object. Now, if you go and draw an object graph of your architecture, what will be the most coupled object in your business logic? That's right, the Logging object. This is not right. This problem has to be solved. Sure, you could make this object call static, but you would still have to make the call in each class. Sure, you could intelligently provide an interface, but there is a problem if your architecture was not made like that (especially in a real world application). Logging is an aspect of your problem domain. It's not a business value. Therefor, a Logging aspect object is made. This Logging aspect will contain a few methods that do the actual logging. Now, how do we tie these methods to all the classes? We use an expression pattern: "access-modifier package Type method (params)" For example, if I want the logThis() method inside the LoggingAspect to run for each and every class in my model, I would write this: Code: @AfterReturning(execution(* org.booleansoup.java.model.*(..))) public void doLog(){ System.out.println("Error occurred."); } How neat is that? Having a code section being applied to all classes without even putting the code in there? Very neat indeed. In OOP, it's not possible to have this functionality without an actual method call. This is where the Factory pattern and the Proxy pattern come in. It happens like this: Code: //MyMain.java MyObject myObject = MyFactory.getObject("myObject"); myObject.getName(); //MyFactory.java public Object getObject(String objectName){ //Don't really pay attention to this, it's a hardcoded example for illustration if (objectName.equals("myObject")) return new MyObjectProxy(); } //MyObjectService.java private MyObject myObject; public MyObject getMyObject(){ return myObject; } //MyObject.java public String getName(){ return name; } //MyProxyObject.java public MyProxyObject extends MyObjectService { @Override public String getMyObject() { new MyLoggingAspect().doLog(); return super(getMyObject()); } } Pretty nifty code huh? The whole point of this code is to abstract away the insertion of the logging into each of the logging pointcuts (=place in the code where logging/aspect action needs to happen). Essentially what's happening here is: Object a calls Object b and Object b calls method c. Therefor it looks like Object a is calling method c, while it's actually not.  Hope you enjoyed my writing. Design patterns are so valuable in the real world.. don't underestimate them.  [Edited on August 4, 2012 by Zomg] ____________ |
| # | |
| August 6, 2012, 07:56 | |
|
Dennis
どこかにいる 2092 posts 
|
MyObject myObject = ObjectFactory.getObject("myObject"); I'd just write it as ObjectFactory.getObject(myObject); and declare the parameter as datatype "Object", by reference. I think languages such as Java will automatically cast it to a MyObject class... or won't it? ____________ Kwakkel |
| # | |
| August 6, 2012, 10:14 | |
|
Zomg
None 641 posts |
The problem there is that you're simply fetching an object from the factory and you're not doing anything with it. In my case I am doing something with it because I put it in a MyObject object. This is the point of a factory. To hand out an object. It replaces instantiation coupling. Casts happen manually. :o
____________ |
| # | |
| August 10, 2012, 10:02 | |
|
Dennis
どこかにいる 2092 posts
|
Quoting Zomg: The problem there is that you're simply fetching an object from the factory and you're not doing anything with it. I don't get it, I also put it in myObject. 
____________ Kwakkel |
| # | |
| August 15, 2012, 22:09 | |
|
Zomg
None 641 posts |
I suppose you meant this: public Object getMyObject(MyObjectInterface obj){ return ObjectFactory.getObject(obj); } A getter for MyObject. Sure, yeah, you'll be passing in the object Type at runtime. Though the point is that you are not doing object creation in your method. Doing so will result in your method being tightly coupled to that object. Instead, the factory pattern is used. A factory will produce the object for you (pretty much a call to .getNewInstance()). However, if you're doing the above getter, you're tied to Objects of that type (unless you pass in Object, LOL). What dependency injection frameworks such as Spring do for you, is that they inject the object at runtime through an xml file. Example: <java-class id="ObjectWorker" class="org.foo.Objectworker"> <ref class="org.foo.MyObject"/> <ref class="org.foo.SomeOtherObject"/> <ref class="org.foo.HalfLife2Cube"/> </java-class> You see, this XML file is disconnected from your code in a way that it's not interfering with your code. There's no imports of any framework (except java). There's no explicit implementation of any interfaces. In other words, the code is not invasive. Encapsulate what changes. What changes? Well, in this case it's the object references in the constructor (I was almost going to write cuntstructor). More on this later. :f ____________ |
| # | |
Message Board > Programming > Some very interesting design patterns