Timeline for design pattern for describing a variable subpart of a config file
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 24, 2012 at 18:38 | comment | added | Kevin Junghans | The factory pattern is not just used when "possible implementors of an interface is open-ended." It also used when a specific object interface can implement more than one class of objects and knowing which class is not necessary. It is also used for dependency injection. And saying you can predict when the "set of classes will grow" is like saying your application will never evolve. | |
| Jan 23, 2012 at 20:48 | comment | added | AgostinoX | Factory pattern is very useful when the set of possible implementors of an interface is "open-ended", and reveals to be quite burdensome when you have two or three or even ten implementors classes, but being the set unlikely to be extended. I think that this would be "push in" the factory pattern, so you feel the code is "right" because it respects a DP. But factory pattern pays for itself only when the set of classes is growing. A situation that occurs often in frameworks, not so often in common applications. | |
| Jan 23, 2012 at 20:31 | comment | added | Ryathal | the factory pattern would be a good way of creating the classes as need though as kevin junghans suggested. | |
| Jan 23, 2012 at 20:31 | comment | added | Ryathal | As I understand your question, you have an App that is intended to send a communication(s) to someone. MailTo and SmsTo are related in that they are your methods of communication; this is all the relation they need. I am more familiar with .NET where creating an interface called 'communication' with a method called 'send' for both classes to implement would be the best solution, so both classes can be held in the same collection of type communication, this might not be possible in java, but a class with a virtual method would achieve the same but less extensible result. | |
| Jan 23, 2012 at 20:18 | comment | added | AgostinoX | I don't think so. Perhaps the example is not clear in showing that MailTo and SmsTo have nothing in common but being a "output". The essence of polymorphism is to use an interface or a superclass and let the implementors decide the exact behavior of an inherited method. In those cases, programming to an "interface" is perfect. BUT the most the common aspects between the two classes are few, the more likely you will need to deal with specific aspects of your class. At the end of the line, we have an empty interface that contains no methods. How can you use polymorphism? | |
| Jan 23, 2012 at 18:23 | history | answered | Ryathal | CC BY-SA 3.0 |