Interview Notes
(Simple) Trading System Diagram
Message Manager
This processes each trade update on its own thread. We have a problem where inconsistent trade
data is being shown in our trade viewer, what might be causing this?
>> The likely problem
is a race condition between two trade updates on the same trade.
Score [0] [1] [2] [3]
How might we rectify this?
>> ensure an update
thread must obtain a synchronisation lock on the target trade before conducting
it’s updates.
Score [0] [1] [2] [3]
Open Trade Viewer
This is supported through a JTable, each row of which
displays a different trade.
A Trades contains the following sort of rendering method;
public Object getValueAt(int col)
{
switch( col
)
{
case
1:
{
SimpleDateFormat
formatter = new SimpleDateFormat("EEE
dd-MMM-yy")
return formatter.format( _startDate );
}
….
}
}
Why is this approach not a good idea?
>> Because each time
the cell is rendered a formatter must be created, and the field could be
prerendered anyway
Score [0] [1] [2] [3]
Trade Entry Screen
Currently this is all one code block.
We decide to refactor this so that the Price and Ticker
components are obtained through a
factory.
Why might we have done this?
>> Decoupling of
creational routines.
>> Plugability (can
switch UI seamlessly).
Score [0] [1] [2] [3]
What are the advantages and disadvantages of this approach?
>> Decoupling vs the
addition of extra code (i.e. if the components were 3 lines each a factory
would be overkill).
Score [0] [1] [2] [3]
We have an existing class B which implements interface A.
We want to create a new class which implements interface A
and has much of the functionality that B supports.
What options are open to us?
Score [0] [1] [2] [3]
>>> show diagram
<<
Class D is an example of what sort of design approach?
Score [0] [1] [2] [3]
>> Delegation
What are the advantages of Class C over Class D, and vice
versa?
Score [0] [1] [2] [3]
>>
Class D reduces the coupling between D & B and makes the classes more
flexible to change.
Additional
Questions
Q: When might delegation be a
preferable alternative to inheritance? What are the merits of each and in what
situations might make you choose one over the other?
>> The candidate should
understand that delegation makes a favourable alternative to inheritance. The second part is very subjective but might
include discussion of delegation being a more robust solution. Comments on the
context of the change would demonstrate a pragmatic approach.
Q: How do software patterns fit into your development methodology?
>> should be pragmatic about
this issue.
Q: A commonly know design principal is
that you should depend on Abstractions rather than Concrete classes. Comment
briefly on why this should be so.
>>
Do they understand the concept of
coupling and the role played by interfaces?
Q: Describe how you would the unit
tests you would write for the method boolean isNegative( Integer anInt ).
>>
Test positive result. Test negative
result. Test Null. Boundary comment that you would only bother doing this in
extreme cases where the routine being tested was hyper critical.
Q: Can you give an example of
when you might want to extend a concrete class?
>> Where you want to
use an existing framework that you have no refactoring control over.
Q: Can you give reasons why
you would not want to extend a concrete class?
>>Delegate class need
know only the interface rather then the other concrete class it is delegating
to.
Q: Why does java support
primitives?
>>>Speed based
primitives are heap based and passed by value