Design Patterns – Representing Complex Object Dependencies in Python

With the limited amount of information, I am making the assumption that planets themselves don't require logging, it's only the readings from Rovers and Satellites that do (they are the monitoring devices). In that case each Rover and Satellite should have their own instance of a logger, but perhaps log to the same log file.

By flipping your design to instead of Planets owning Rovers and Satellites, Satellites and Rovers tracking their point of origin, you could simplify this problem.

public class Satellite
{
    private ILog Log;
    void Satellite(Planet origin)
    {
        //include logic here on when not to instantiate logger e.g. origin.Name != "Mercury"
        Log = LogManager.GetLogger("Satellite");
    }
}

If you want to keep track of the number of satellites and rovers at each planet you can do so with Linq queries if you keep track of the collection of registered ones and filter them by what planet they are originate from.

As Doc Brown mentioned, using Dependency Injection containers is not Dependency Injection. Dependency Injection is just parameterization, and Dependency Injection containers are just meant to "simplify" wiring up dependencies. Your issue seems to be mostly driven by (perceived) limitations of whatever DI container framework you're using.

I don't understand how your objects being "bags of properties" is a "result" of dependency injection. Some objects are going to just be "bags of properties" and thus will have no dependencies. These are often called "POJO/POCO" objects for "Plain Old Java/C# Objects". Obviously, this can't be all your objects as nothing would need dependencies then.

You also mention "giant objects with lots of dependencies" that "needs [only] 1% of [the] created object graph". This is somewhat contradictory. If it only needs 1% of the "created object graph", why is it depending on that remaining 99%? If your dependencies need dependencies for things other than what you need of the dependencies, this suggests that your dependencies aren't well-factored. In OOD terms, a violation of the Single Responsibility Principle. One of the consequences of systematically using Dependency Injection is that your class hierarchy becomes completely flat. Any "hierarchy" that is needed arises from how things are wired together (which no longer needs to be strictly hierarchical). Each of your classes should depend on only what it needs via relatively narrow interfaces. If each class provides only one "service", then dependencies will never instantiate more of the object graph than they need. There are plenty of good reasons for class to provide multiple "services", and this can lead to dependencies that are extraneous to some downstream consumer of the "service", but this will be very obvious and presumably done for some explicit reason. If not, factor the class into multiple classes that each provide only one of the "services". (The "services" usually correspond pretty closely to the interfaces a class implements. So if you have a class that implements multiple interfaces, this is an indication that the class is providing multiple "services".)

At any rate, for the limited example of code you provided, there's a pretty clear solution. Firstly, it's quite possible that whatever DI container framework you're using explicitly provides for this, but let's assume not. What do consumers of Something actually need? The need something that will give them Somethings when given Others. (Or to be more precise, something that will give them an instances of an interface representing whatever "services" Somethings provide. They shouldn't care if they actually are Somethings.). That is, they need a SomethingFactory. So classes that need Somethings should depend on SomethingFactory and then use that to create Somethings. In code:

class Something : ISomething {
    public Something(Other object, Dependencies dependencies) {...}
    // ...
}

interface ISomethingFactory {
    ISomething CreateSomething(Other object);
}

class SomethingFactory : ISomethingFactory {
    private readonly Dependencies _dependencies;
    public SomethingFactory(Dependencies dependencies) {
        _dependencies = dependencies;
    }
    public ISomething CreateSomething(Other object) {
        return new Something(object, _dependencies);
    }
}

class SomethingConsumer {
    public SomethingConsumer(ISomethingFactory somethingFactory) {...}
}

This approach gives you almost exactly the same experience as directly writing new Something(object) plus not having to worry about extraneous dependencies. There is no reason from what you've described (or generally) why Dependency Injection would lead to you needing to make all properties public or use a "procedural style" or anything like that. You could take any OO program written "naturally" and mechanically convert it to one using dependency injection. Simply go through what you would "naturally" write in "OO" style, and replace any uses of new with either passed in dependencies or factories as I've illustrated above. Other than having to pass around some extra parameters, the structure of the code will be practically identical to what it was before. If you feel you need to make much more extensive changes than this, you are misunderstanding something. (This may suggest more extensive changes, but they should not be necessary.)

As a note, the fact that you are using any particular DI container should not be evident from the vast majority of your code. You should not be passing around the DI container and instantiating objects with it willy-nilly. The DI container should only be used (if used at all) to simplify the top-level code that wires everything together. I'm not sure what you mean by "you can request 'inner' service from DI", but it sounds like you're doing something like this.