Java Design Patterns

[Moonwraith]

Now this is a last second ditch attempt to try and understand WHY design patterns are actually useful? I've got notes, and plenty of internet sources that can explain all of them in the typical verbose ways.

But my question is, to anyone out there with experience with java design patterns, (and also the skill to translate it into retard speak for me).. Why _DO_ these stupid design patterns help with the re-use of code?

I've used some specific ones before, and they just merely complicated the system for almost no reason.

The key ones to focus on are... Factory method. Abstract factory, Singleton, Adapter, Observer, Composition, Façade, State and Strategy patterns.

Factory methods, singleton, facade and adapter are relatively straight forward.

If there's no one out there that can help or doesn't have the time by tomorrow, then don't worry about it - exam tomorrow and my mind's finally caved in on itself. :dead: I'm pretty much doomed either way, but who knows, there may be some genius out there

 

[Geffy]

I've not done Java in quite a while but theres no strict reason to use Design Patterns in any case. Design patterns are simply the definition of a particular way of doing something. They are a pattern on which to base the design of your code.

Now they are very useful, they are useful because they save you having to do a lot of thinking about how to put something together. They also serve to inspire and discourage other methods of writing code.

The factory design pattern for example is useful in the case where you are likely to be dynamically generating a lot of objects which are very similar with only subtle variations. In this can you might have a Factory object which, when passed a selection of options, returns you with a nice correct instance of your generic object. Factories become more useful when you have an object which is composed of many other objects. The Factory then encapsulates the nitty-gritty job of creating and hooking together all of those other objects.

Singleton, well that makes sense when there should be one and only one instance of something. A particular connection to a limited shared resource perhaps.

How do they help with the reuse of code? Well the factory description I gave before has clear benefits of helping you limit errors in the creation of your complicated object. As the only bugs with creation you should need to fix would be in the factory.

Adapters promote the reuse of a baseline piece of code which is able to interface with multiple other objects. A database adapter is one of the easier examples to understand. You might have a generic database interface with a series of adapters which know how to translate the generic api into the database specific api. This means you can reuse the code you wrote for one database against another database because the adapter can translate your generic commands into the specific ones for the new database.

Observers are a bit of a wild beast, how reusable they are depends more on how you write them and how closely they tie into the thing they are observing. I'd say Observer pattern would be more likely to help you reuse the code which is observed than the other way round.

State pattern I'm assuming is a reference to state machines. I'm not sure these help in code reuse but they certainly help with programmer comprehension and understanding as well as code maintenance.

Hopefully that hasn't confused you.

 

[Moonwraith]

Thanks mr Geffy - clears up a few basic things, still going to be hitting the books throughout the day/this evening. They're just frustrating, remembering specific UML for them is definitely a pain

 

[Geffy]

UML *shudder*

I have used it since Uni, but I've always had to go find a book on what the symbols are again. More often than not I just grab a piece of paper these days and do my model in the way that makes the most sense to me.

 

[Moonwraith]

Agreed - I hate all these pre-defined styles of design. Lemme just do it my own screwed up way damn it!