pattern question ?
in [Java Programming]
|
From: tomo on 31 May 2010 04:51 I have three separate classes that calculate credit capability od client depending on loan type. Can I use some design pattern (for example Strategy) to write it more efficient ? Any suggestion ? __________ Information from ESET NOD32 Antivirus, version of virus signature database 5153 (20100528) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
From: Arved Sandstrom on 31 May 2010 05:59 tomo wrote: > I have three separate classes that calculate credit capability od client > depending on loan type. Can I use some design pattern (for example Strategy) > to write it more efficient ? Any suggestion ? With all due respect, you might have wanted to ask that question before you wrote code. Having said that, what do you mean by more efficient? More performant? Is it not performing well now? Or do you mean more maintainable? How is it currently causing problems with maintainability? Or do you just want to be able to hang a Design Patterns label on the code that you wrote? For all I know, depending on your current implementation, 3 separate classes each with completely different logic _is_ a good solution. I have no idea how you are using them in client code. AHS
From: Daniel Pitts on 1 Jun 2010 17:19 On 5/31/2010 1:51 AM, tomo wrote: > I have three separate classes that calculate credit capability od client > depending on loan type. Can I use some design pattern (for example Strategy) > to write it more efficient ? Any suggestion ? Yes, Strategy sounds like a good fit for this problem. I would start by making an interface that the three different classes and all implement. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Roedy Green on 7 Jun 2010 20:22 On Tue, 01 Jun 2010 14:19:41 -0700, Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> wrote, quoted or indirectly quoted someone who said : >I would start by making an interface that the three different classes >and all implement. or classes that extend an abstract class. For rules of thumb on which way to go, see http://mindprod.com/jgloss/interfacevsabstract.html -- Roedy Green Canadian Mind Products http://mindprod.com Have you ever noticed that any computer search in the movies, is always linear, with, for example, candidate fingerprints flashing up on the screen one after another? The public is still under the delusion that electronic files are microscopic filing cabinets made out of tiny wires or magnetic patches inside the computer. Most lay people are surprised that it is easy for a computer to file things simultaneously by a dozen different schemes, and that they can have any report printed in any number of different sorted orders. With physical files, they are limited to one ordering/access.
From: Lew on 7 Jun 2010 21:14
Daniel Pitts wrote, quoted or indirectly quoted someone who said : >> I would start by making an interface that the three different classes >> and all implement. Roedy Green wrote: > or classes that extend an abstract class. For rules of thumb on which > way to go, see http://mindprod.com/jgloss/interfacevsabstract.html Your site makes interfaces sound so weak and useless, and provides some misinformation regarding them. For one thing, you say that only classes establish an /is-a/ relationship. Something that implements an interface /is-a/ that interface. You go so far as to state that at least for some implementations of an interface, "[t]o them, your interface is only incidental, something that have to add on to the their code to be able to use your package." Nothing could be further from the truth, or more damaging to gaining the full power of interfaces. There is nothing incidental about implementation of an interface. Interfaces, in concert with generics, establish contracts and type structures which force implementations to adhere, in a way that the compiler enforces, thus preventing slews of bugs. They provide that type safety and power while maximizing the flexibility to adjust implementation in a controlled and tightly encapsulated fashion. They permit code to focus on the type and essential limited range of behaviors needed for a particular reference, without sacrificing the power of any other interfaces or parent classes that the run-time type may inherit. As Joshua Bloch pointed out in /Effective Java/, one should "[p]refer interfaces to abstract classes" (Item 18 in the second edition). You should read that chapter. You make interfaces sound like a red-headed stepchild when they're actually one of the most singularly powerful features of Java. -- Lew |