From my limited experience, you don't want ->new("EUR/USD"), at least not as the canonical version. FX rates tend to be "traditionally" ordered, and in my experience the tradition of the currency pair order is broken/changed far too often to consider EUR/USD and USD/EUR as different pairs. Also, base and quote only make sense as long as your front end system gives you access to which currency actually was the base currency and which was the quoted currency.
Personally, I would keep the currencies and the amounts together, and basically use:
my $fx= MyApp::FXRate->new( EUR => 1_000_000, USD => 1_082_500 );
Alternatively, if you want to allow room for other options, I would propably use something like:
my $fx= MyApp::FX->new(
pay => [ EUR => 1_000_000 ],
receive => [ USD => 1_082_500 ],
spot_date => '2015-03-06',
);
| [reply]
[d/l]
[select] |
Can you show us a short example of how you envisage the API being used? (Preferably using 3 pairs, one of which has a common base.)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply] |
well that's it - I am not at all sure with OOP - I have to big questions:
1) With a class for the FX object - you could have many instances of that object - however where would I set a "global" setting that affects all the objects in that class - e.g. 'the separator character, or '/' (e.g. 'EUR/USD', or maybe 'EURUSD', or 'EUR-USD') - do I have to create a parent class or something?
2) It strikes me that I could break down the object a bit more and have a "Quote" class which would contain something like (timestamp, open, high, low, close) - that could then be used with many derived classes not just Forex quotes, but Stock Quotes, Bonds quotes, etc.
3) and then I guess you could create one 'pair' object - e.g. 'EUR/USD', and then have many (an array) of quote objects for each pair object. Or would that be better to have a quote object which would be of type 'pair' (e.g. type 'EUR/USD')...
and then I get a head explosion and think of giving up...
Also another principal I have heard is that one should make as much of the code as possible as straight functions (normal module code) so that it could be called by any script, and then have the Class call the straight function - is that a good practice?
| [reply] |
well that's it - I am not at all sure with OOP
You're approaching the problem of designing the API from the wrong perspective.
Describe a typical use case, not in terms of OOP, or any particular API, but in terms of how an application would need to use the functionality you are trying to encapsulate.
The key here is to recognise that once you know what an application needs to do with the functionality, 9 times out of 10, the API becomes self-designing...
Provided you don't get caught up with either:
- trying to utilise all the facilities of the OOP framework you are using;
That is, just because Moose provides a bunch of facilities, you don't have to use them all.
- Trying to cover every conceivable use-case;
Trying to predict all the possible different ways a piece of functionality could be used; and then design to cover them all, is a mug's game.
A)You'll guess wrong, and predict uses that will never be used, and miss those that will; B) You'll end up with an API so complex and top-heavy that no one will want to use it.
Write down the use case that you currently have in mind. In words; code comes later.
Once you have described the application, then you should be able to extract from that the API requirements of that application; then design an api to fit those requirements.
Then mock up the API -- just empty subroutines/methods that verify the arguments and return a plausibly correct value:
sub new{ bless {}, $_[0] }
sub twizzle{ my( $self, $twizzleFactor ) = @_; ref( $self ) = __PACKAG
+E__ or die; $twizzleFactor > 1.0 && $twizzleFactor < 9.0 or die; retu
+rn 123.4567 }
Then write the (bare-bones of the) application, in terms of that API.
That process will quickly allow you to see the weaknesses and strengths; omissions and over-elaborations of the API design; and correct them.
And then you can fill in the guts of the API, using the bare-bones as your test rig.
Once the bare-bones application works, you can then speculate about what else... but don't do so before hand.
And along the way, the API design will (should) have fallen into place naturally.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply]
[d/l] |
