0

Is it a best practice to initialize class dependencies in a constructor or should a class be initialized in the method where it is used. Let's say we have the following situation, and PriceCalcService is used only in a couple of methods. Order also takes other parameters, and sets its state.

public class ShippingService() { .......... }

public class Order() {
    public string SomeOrderProperty;
    private PriceCalcService priceCalcService;

    public Order(string someOrderproperty) {
         priceCalcService= new PriceCalcService();
         SomeOrderProperty = someOrderProperty;
    }

    public void Method1() {
         PriceCalcService.MethodX();
    }
    .......
}

Or should the PriceCalcService be initialized only in the methods that use it?

public class PriceCalcService() { .......... }  

public class Order() {

    public string SomeOrderProperty;
    public Order(string someOrderproperty) {
         SomeOrderProperty = someOrderproperty;
    }

    public void Method1() {
         new PriceCalcService().MethodX();
    }
    .......
}

First example: Advantage: We can see the dependencies Disadvantage: We instantiate a class even if it is not used. Which method should I choose?

  • In you example, the Order class doesn't have a dependency to the PriceCalcService. Therefore you can just drop the method Method1 and use the PriceCalcService somewhere else. – JanDotNet Jan 5 '17 at 14:25
7

Is it a best practice to initialize class dependencies in a constructor or should a class be initialized in the method where it is used

No. Neither is good practice. Good practice is to:

  1. reference those dependencies via interfaces,
  2. Inject the dependencies via the constructor

So the code might look something like:

public class Order() {
    private IShippingService shippingService;

    public Order(IShippingService shippingService) {
         this.shippingService = shippingService;
    }

    public void Method1() {
        shippingService.MethodX();
    }
    .......
}
  • 1
    some say that the 'I' prefix for interfaces are a bad pratice. – linuxunil Jan 5 '17 at 12:10
  • 2
    @linuxunil, That is entirely dependent on the language, eg using I to prefix interfaces in Java is going against that language's conventions. Not using them in C# would be failing to follow that language's conventions. They are used here to emphasise it's an interface as the question is language-agnostic. – David Arno Jan 5 '17 at 12:24
  • that's way i said 'some say'... in java abstract classes usually have an 'Abstract' prefix - apache does this a lot - so i don't know why not let intefaces have the 'I' prefix. But let's not start this discussion here as it has nothing to do with the OP question ;) – linuxunil Jan 5 '17 at 12:34
  • Thanks for the answer David Arno. I don't want to use Dependency Injection, because I want to do OOP style programming and if I use DI I will kinda end up with a procedural programming style. I want to pass additional parameters beside class dependencies to set up state for the object. Sorry I forgot to mention that I will update my question. – Icebraker Jan 5 '17 at 12:45
  • @Icebraker, "I want to do OOP style programming and if I use DI I will kinda end up with a procedural programming style". This statement is non-sequitur. Object constructor-based DI is, by definition, an OOP-only solution. – David Arno Jan 5 '17 at 12:47
3

Let the POJO be the POJO.

The responsibility of an Order Object is to hold information of an order.

public class Order() {

    //let the properties of the pojo be private
    private String orderDescription;

    public Order(String orderDescription) {
       this.orderDescription = orderDescription;
    }

    //getters/setters
}

Let the Service be the service.

The service is responsible of containing methods that take an order and operate on them.

public class ShippingService() { 
  public void processShipping(Order order){
    //write the body of the method that takes the order and do the shipping.
  }
}

In a abstract way, you have an Object that is a POJO. Then you have a service that holds the ways of work with that Object. That way you can develop your object - adding new properties - and the service - adding new functionality - in a separate way.

  • You are right, but that way you will end up in a procedural style of programming. I wanted to have data + operations at the same place, thus doing oop style programming. – Icebraker Jan 5 '17 at 13:03
  • are refering to [DDD] ? : en.wikipedia.org/wiki/Domain-driven_design – linuxunil Jan 5 '17 at 13:05
  • yepp, something like that. – Icebraker Jan 5 '17 at 15:11
1

In general, if we are talking about a business application and you wish to support automated unit testing, follow these rules:

  1. Dependencies should be injected.
  2. Other initialization should be done outside the constructor, just before it is actually needed ("lazy")

This allows a unit testing framework to isolate method logic from constructor logic, while supplying mock interfaces via DI.

On the other hand, if we are talking about a realtime application such as a video game, you should probably do all of the initialization in the constructor so that the performance of the code is predictable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.