New answers tagged

0

Both your approaches raise some concerns. The main concern about the first approach is that you'll end up with a lot of duplicate methods. This isn't exactly a problem though, because both methods have a clear goal: One of the methods will actually implement the business logic you want to execute, and will return an entity. The other method will call the ...


6

Depend on abstractions, not on concretions. It means, coding to interfaces, not to concrete classes? Also known as "coding to the interface (not to confuse with interface the keyword), not the implementation". It is an ancient technique called abstraction. Any layer of abstraction tries to hide irrelevant details and thus reduce complexity, allowing ...


1

Abstraction does not necessarily mean an interface. If you think about two interacting components, as the code evolves there will be things that change, but there will be aspects that stay more or less the same. But changes in one component generally cause changes in the other, dependent component. If you recognize those aspects that don't change, or that ...


8

Depend on abstractions, not on concretions It means, coding to interfaces, not to concrete classes? For languages that support interfaces, this is generally the case. But that abstraction layer can be provided via other means, such as an abstract class, a factory, reflection etc. The important thing is that you do not directly couple a requirement to a ...


Top 50 recent answers are included