| Design patters are codifined standard practices of expert designers. Quoting Alpert et al, "A reusable implementation model or architecture that can be applied to solve a particular recurring class of problem." It includes a pattern name, problem (when to apply the pattern), solution (the elements that make up the design, their relationships, responsibilities, and collaborators), and consequences (results and tradeoffs of the pattern). Frameworks are groups of classes used for a particular domain. ~Sabina Karkin |
| Nice start Sabina. But, can anyone say what is really different about them? Why are design patterns harder to use than frameworks? Barbara Ericson |
| It is hard to learn about frameworks and how to use them. ~Sabina Karkin |
| Frameworks are actually easier than design patterns to use, Why? Barbara Ericson |
| Frameworks are code that is already written that you just have to use. Design patterns are more like following a cookbook implementation model that you can use to write your own code to solve the problem. timmy |
| Yes, timmy is right that frameworks provide existing classes that you can use or extend for a domain (like GUI or database or testing). Design patterns mean you have to write all the code to use it. What else is hard about design patterns? For example, why are they hard for people without much experience doing object-oriented programming? Barbara Ericson |
| Because I think understanding /why/ (what problem would I run into if I coded it this way—and how does this technique solve it) is more important here than understanding /how/ (how do I write the code for this). If you don't understand /why/, you'll never know /when/. timmy |
| Good, timmy, one problem is that people without experience don't understand why the pattern is a good way to solve the problem. There are some other things that are hard about design patterns. Anybody else care to try? Barbara Ericson |
| You would use Command, which is a Behavioral design pattern (the patterns of communication between objects). You would put Commands in a stack or a queue. ~Sabina Karkin |
| You could use the Factory method pattern, which is a Creational design pattern (making a system independent of how its objects are created, composed, and represented). This pattern lets you define an interface for creating an object but lets subclasses decide which class to instantiate. ~Sabina Karkin |
| Hmm, there is another pattern that might be a better fit. Barbara Ericson |
| Maybe the Bridge pattern? You would bridge when both abstraction and implementation might be extensible via subclassing and you want to avoid permanent binding between an abstraction and its implementation. ~Sabina Karkin |
| Yes, the bridge is usually what you use when you want to subclass both the abstraction (think concept, like window) and the implementation (how will we do a window on Windows machines, Unix, and Macs). Barbara Ericson |
| You could use Singleton pattern where we only want one instance of the class. After making the constructor private, you get one version of the class. ~Sabina Karkin |
| You can use the Singleton pattern to limit the number to X as well. Barbara Ericson |
| It sounds like an array and a simple if-statement is the only thing that is necessary here. Before you know it, you'd have a over one-hundred classes at this rate. timmy |
| Not sure what you mean by that timmy. Object-oriented programming is about creating objects to do the work that needs to be done. We don't do the code as procedures and just use arrays and if statements. We think about what class should be responsible for doing the work and create objects from that class as needed. |
| OOP can be abused just like any other technique. It's similar to how there are times when recursion describes a problem better than iteration. But if you ignore iteration completly because you can do it with recursion, you will be missing out. While I see a use for the singleton approach, I think it over-complicates this problem. timmy |
| Sure, OOP can be abused. And I have seen groups create too many classes to handle a problem, though usually they error on the side of not creating enough. One goal of OOP is well designed classes that can be reused. Classes should also have attributes and methods (behaviors). So one way to check for too many classes is to check that all the classes have well defined responsibilities and have data and behavior. If they don't have that remove the classes and move their data or behaviors to other classes. However, the singleton pattern does solve a real problem and can be used to create reusable classes. Most database connection pools use this pattern. Barbara Ericson |
| Actually, the problem is that usually you can create any number of objects from a class. So we need a way to restrict the number of objects that can be created from a class. That is what the singleton pattern does. How does it do that? Barbara Ericson |
| Keep a class variable that's a counter, make the constructor private, and have a class method that creates/returns an instance if the counter is less than the max number of objects and increments the counter. -Kerry |
| Right, Kerry Barbara Ericson |
| Observer would be good, which is a Fundamental design pattern because it uses delegation in telling objects to take action when the other object changes. ~Sabina Karkin |