Tag Info

New answers tagged

4

As an outsider looking at this code, it is not clear how the "hidden dependencies" get created to begin with. What if there is no "db" dependency registered? Does it throw an exception, return null? If my class doesn't get a "db" dependency, how bad is that? Many times people lean towards this pattern when there are too many dependencies to pass in the ...


1

if any of the methods fails, there is really no point in calling subsequent methods. How should I address those possible method failures? Throw an exception. Should the Carousel class be 'injected' into my class before it is used? Yes, if there is more than one implementation of Carousel (including the possibility of a mock object for unit testing ...


3

An Item-Class is there to tell you about data relating to items, and perform business logic that is centered around them - so making it able to tell you its price for a given customer and quantity, its main-image-filename or some such doesn't seem like a violation of the Single Responsibility Principle. Yes it is a violation of the SRP. It is ...


7

I would go with the anemic domain model here. Consider the example of your ItemImageFinder. Consider a few scenarios: You decide to extend your system to also include Image thumbnails, or including alternate images. Now you need to modify your Item behavior. Clearly this is not the only reason for Item to change, so you are violating SRP. You either have ...


3

DIP states that Higher level module should depend on Lower level module over abstraction and All variable implementations require Factory Method.Ref: DIP So, creating a Factory Class definitely a good option to resolve your problem. In addition, you could inject both IReader and Iwriter to your Person class. public class Person : IReader, IWriter { ...


1

A third option might involve creating a class to manage the state of your books, then sharing an instance of the class with your Person and IReader implementations. This is conceptually similar to having a book repository or cache. Option 1 or my suggestion are probably the cleaner solutions. Can you provide more information about the overall problem you ...


0

From the OOP point of view functions can be considered to be single-method interfaces. Interface is a stronger contract than a function. If you are using a functional approach and do a lot of DI then in comparison to using an OOP approach you will get more candidates for each dependency. void DoStuff(Func<DateTime> getDateTime) {}; //Anything that ...


5

is Functional Programming a viable alternative to dependency injection patterns? This strikes me as an odd question. Functional Programming approaches are largely tangential to dependency injection. Sure, having immutable state can push you to not "cheat" by having side effects or using the class state as an implicit contract between functions. It ...


8

Dependency management is a big problem in OOP for the following two reasons: The tight coupling of data and code. Ubiquitous use of side effects. Most OO programmers consider the tight coupling of data and code to be wholly beneficial, but it comes with a cost. Managing the flow of data through the layers is an unavoidable part of programming in any ...


-3

This is another option in addition to amon's answer Use Builders: class Foo { private Bar bar; private Qux qux; private Foo() { } public Foo(Builder builder) { this.bar = builder.bar; this.qux = builder.qux; } public static class Builder { private Bar bar; private Qux qux; public ...


5

The short answer is "almost never", but there are, in fact, a few places where the DIP doesn't make sense: Factories or builders, whose job it is to create objects. These are essentially the "leaf nodes" in a system that fully embraces IoC. At some point, something has to actually create your objects, and can't depend on anything else to do that. In many ...



Top 50 recent answers are included