Prev: custom user interfaces for desktop application
Next: Using 'scenario' library for navigation application?
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
 |  Next  |  Last
Pages: 1 2 3
Prev: custom user interfaces for desktop application
Next: Using 'scenario' library for navigation application?