Bloomberg LP Interview Question for Financial Software Developers






Comment hidden because of low score. Click to expand.
0
of 0 vote

it's always preferable to use composition than inheritance , composition let's you to adapt more than one behaviour , you can inherit only one interface but you can inherit more than one using composition . By using method delegation you can provide virtual inheritance .

for example

public interface Aircraft {
fly();
takeoff();
land();
}

public interface Fighter{
fireBullets();
fireMissile();
}

Using inheritance

public class Plane implements aircraft {
fly()
{
//fly
}

takeoff()
{
//takeoff
}
land()
{
//land
}
}

public class F16 extends Plane implements Fighter
{
fireBullets()
{
//fire F16 Bullets
}

fireMissile()
{
//fire F16 laser guided missiles
}
}

Usage

F16 alpha = new F16();
alpha.takeoff();
alpha.fly();
alpha.fireBullets();
alpha.fireMissiles();
alpha.land();

Using Composition

public class F16
{
Plane myPlane;
Fighter myFighter;

F16(Plane myPlane, Fighter myFighter)
{
// assign
}

fly()
{
myPlane.fly();
}
// same kind of delegation for remaining methods

}

assuming boeing and m20gun are concrete implementations of plane and fighter
F16 alpha = new F16(boeing,m20gun);
alpha.takeoff();
alpha.fly();
alpha.fireBullets();
alpha.fireMissiles();
alpha.land();

- anandraiin3 April 07, 2009 | Flag Reply
Comment hidden because of low score. Click to expand.
0
of 0 vote

Imagine a scenario where you want to provide custom logic to a control.

public class MyTextBox extends TextBox
{
//my behavior
}

If I used Composition, I'd have to repeat all properties of TextBox for my consumer to use them. Worse, if the TextBox I encapsulate changes (new version), I will have to redeploy my code to get access to newer properties.

- I dont agree April 16, 2009 | Flag Reply
Comment hidden because of low score. Click to expand.
0
of 0 vote

You cannot blindly say use one over the other. Its more to do with the relationship that objects have.
Use Inheritance if its a "is-a" relationship. Ex : Apple is a Fruit.
Use Composition if its a "has-a" relationship. Ex : Customer has an Address.

The following link helps for a clearer understanding.
http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1

- Mo May 12, 2009 | Flag Reply
Comment hidden because of low score. Click to expand.
0
of 0 vote

The above comment by 'Mo' perfectly make sense and it is easy concept.

1) When you know that is-a relationship is not going to change for whatever reason. Then we need to choose inheritance. And what advantage you get by using inheritance in dynamic binding which means JVM will dynamically choose method depending upon the type of class object. Polymorphism is an added advantage too, where same super class object can hold the reference of this as well as all it sub types, which comes handy when you need to add another sub class say 'Mango' derived from 'fruit' without changing major part of the code.

2) When two entities share has-a relationship and you are sure that its not going to be changed during the lifetime of the application, then you are safe to choose Composition. What advantage you get is code-reuse and when you change super class functionality either by adding method or changing return type etc... You only need to make changes in the class who is holding the reference to super class by using method delegation concept. If you want minimal code changes to be done then the composition along with interface makes the perfect combination. In case composition it is easier to change back-end/front-end interface implementation compared to inheritance.

Note: Take family or employee example, as long as employee is working in a company is-a relationship holds good, but when employee leaves is-a relationship is no more valid. In this case composition is can play the required role.

- MasterSolution June 14, 2009 | Flag Reply
Comment hidden because of low score. Click to expand.
0
of 0 vote

From the nice link given by Mo:
<Abstract>
How exactly do composition and inheritance compare? Here are several points of comparison:

* It is easier to change the interface of a back-end class (composition) than a superclass (inheritance). As the previous example illustrated, a change to the interface of a back-end class necessitates a change to the front-end class implementation, but not necessarily the front-end interface. Code that depends only on the front-end interface still works, so long as the front-end interface remains the same. By contrast, a change to a superclass's interface can not only ripple down the inheritance hierarchy to subclasses, but can also ripple out to code that uses just the subclass's interface.

* It is easier to change the interface of a front-end class (composition) than a subclass (inheritance). Just as superclasses can be fragile, subclasses can be rigid. You can't just change a subclass's interface without making sure the subclass's new interface is compatible with that of its supertypes. For example, you can't add to a subclass a method with the same signature but a different return type as a method inherited from a superclass. Composition, on the other hand, allows you to change the interface of a front-end class without affecting back-end classes.

* Composition allows you to delay the creation of back-end objects until (and unless) they are needed, as well as changing the back-end objects dynamically throughout the lifetime of the front-end object. With inheritance, you get the image of the superclass in your subclass object image as soon as the subclass is created, and it remains part of the subclass object throughout the lifetime of the subclass.

* It is easier to add new subclasses (inheritance) than it is to add new front-end classes (composition), because inheritance comes with polymorphism. If you have a bit of code that relies only on a superclass interface, that code can work with a new subclass without change. This is not true of composition, unless you use composition with interfaces. Used together, composition and interfaces make a very powerful design tool. I'll talk about this approach in next month's Design Techniques article.

* The explicit method-invocation forwarding (or delegation) approach of composition will often have a performance cost as compared to inheritance's single invocation of an inherited superclass method implementation. I say "often" here because the performance really depends on many factors, including how the JVM optimizes the program as it executes it.

* With both composition and inheritance, changing the implementation (not the interface) of any class is easy. The ripple effect of implementation changes remain inside the same class.

- smartAss July 17, 2009 | Flag Reply
Comment hidden because of low score. Click to expand.
0
of 0 vote

Also, in inheritance, you can convert a Derived ptr to a Base ptr. In composition, it is not possible. This means, things like RTTI, dynamic_cast and typeid can be related only to inheritance and not composition.

For example:
------------

class B {};
   class D : public B {}; //Inheritance
   class E { B b; }; //Composition

Here, we can do things like:
    B* b = new D;
    D* der = new D;
    b = der;
    
But, we can't do things like:
    B* b = new E; //Compile-error
    E* der = new E;
    b = der; //Compile-error

- Helper December 17, 2009 | Flag Reply
Comment hidden because of low score. Click to expand.
0
of 0 vote

is this really a Bloomberg question? BB does not ask JAVA if i m not wrong...

- crap January 19, 2010 | Flag Reply
Comment hidden because of low score. Click to expand.
0
of 0 vote

composition - HAS - A
inheritance - IS-A

- dhrubo August 01, 2010 | Flag Reply


Add a Comment
Name:

Writing Code? Surround your code with {{{ and }}} to preserve whitespace.

Books

is a comprehensive book on getting a job at a top tech company, while focuses on dev interviews and does this for PMs.

Learn More

Videos

CareerCup's interview videos give you a real-life look at technical interviews. In these unscripted videos, watch how other candidates handle tough questions and how the interviewer thinks about their performance.

Learn More

Resume Review

Most engineers make critical mistakes on their resumes -- we can fix your resume with our custom resume review service. And, we use fellow engineers as our resume reviewers, so you can be sure that we "get" what you're saying.

Learn More

Mock Interviews

Our Mock Interviews will be conducted "in character" just like a real interview, and can focus on whatever topics you want. All our interviewers have worked for Microsoft, Google or Amazon, you know you'll get a true-to-life experience.

Learn More