Timeline for Is Dependency Injection useful when implementations are never expected to change?
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 17 at 2:49 | comment | added | Basilevs | @Flater "The part I disagree with is the underlying assertion that this is clean enough by clean coding standards - which it is not. " "there is no universal string theory in software development. " It is a broad design philosophy that is pervasive through the wider spectrum of coding standards " These are self-contradicting. If clean coding is a vague phulosophy it can not have strong underlying asssertions and certainly can not manipulatr with language specific notion of interface. | |
| Jul 17 at 0:44 | comment | added | Flater | @Basilevs I suggest you don't conflate Clean Coding (referring to Uncle Bob) and clean coding, the broad design philosophy to promote change-friendliness to enhance future codebase maintenance. While they share a common ancestry they are not equivalent and none of this answer/my comment seems to be written with specifically Clean Coding in mind. I don't subscribe to the idea that clean coding is (or should be) a manuscript from a single source. It is a broad design philosophy that is pervasive through the wider spectrum of coding standards and guidelines from many different experienced sources | |
| Jul 17 at 0:42 | comment | added | Flater | @Basilevs There's a bit of a logical fallacy in your argument. A car generally has four wheels and doors but that does not mean that if you take off the doors or build it with three wheels that it therefore ceases to be a car. Doing something partially does not mean that you're not doing the thing - it just means you're not doing it dogmatically. Dogmatism is never the right approach in software development, whether you're focusing on Clean Coding or any other guideline - there is no universal string theory in software development. Guidelines focus on pieces, not the whole. | |
| Jul 16 at 17:52 | comment | added | Basilevs | @Flater I refuse and refute "clean coding standards" (by Uncle Bob). DI and abstraction can be used without that BS. | |
| Jul 16 at 16:41 | history | edited | IMSoP | CC BY-SA 4.0 |
I'm being pedantic, but the DB is called "Postgres" (or "PostgreSQL") not "Postgre"
|
| Jul 15 at 10:56 | comment | added | Hans |
Semantically, those are not really abstractions, but implementations. You are right, maybe writing "implementations like MailService" would have been clearer.
|
|
| Jul 15 at 10:36 | comment | added | DavidT | In code bases that don't prefix all their interfaces with the letter (I) its trivial to copy a class change the original class to an interface and implement that interface from the new class - the only thing that typically changes in a well structured code base is the construction of the object. TL;DR - I introduce "language" interfaces when I need them. | |
| Jul 15 at 7:45 | history | edited | Arseni Mourzenko | CC BY-SA 4.0 |
added 52 characters in body
|
| Jul 15 at 0:36 | comment | added | Flater |
While I disagree with Basilevs on their advice for the OP, I think there's a confusion here in this comment thread between interface (the language construct) and the fact that classes inherently have a public interface. Basilevs is not wrong that classes do indeed have a public interface (even without being backed by an interface). The part I disagree with is the underlying assertion that this is clean enough by clean coding standards - which it is not.
|
|
| Jul 14 at 21:52 | comment | added | Arseni Mourzenko | I've already read your answer and I understand your point. I still find that it's superfluous in the context of the question (which explicitly mentions interfaces). | |
| Jul 14 at 21:41 | comment | added | Basilevs | Also, see how a simple "float" pointer can be injected as a dependency I guess, what I'm trying to convey is that even in languages without "interface" keyword, there is a place for abstraction and interfaces. | |
| Jul 14 at 21:38 | comment | added | Basilevs | I disagree, see my answer | |
| Jul 14 at 21:35 | comment | added | Arseni Mourzenko | @Basilevs: In the context of the question (which is about DI, after all), this is superfluous and potentially misleading. Keep it simple: in this context, interface = abstraction, concrete class = concrete implementation. | |
| Jul 14 at 21:19 | comment | added | Basilevs | They are also abstractions, because they have public interface, isolating clients from implementation details. | |
| Jul 14 at 20:49 | comment | added | Arseni Mourzenko |
I'm sorry, I don't understand what you're saying. The examples the OP provided are the actual implementations of abstract concepts such as IMessageService or IProductRepository.
|
|
| Jul 14 at 20:44 | comment | added | Basilevs | Yes, in bold: "This is because those are not really abstractions, but implementations." | |
| Jul 14 at 19:06 | comment | added | Arseni Mourzenko | @Basilevs: yes... and? Why are you saying that? Have I written the opposite? | |
| Jul 14 at 18:05 | comment | added | Basilevs | public interface of any class is an abstraction over its implementation. | |
| Jul 14 at 16:20 | history | answered | Arseni Mourzenko | CC BY-SA 4.0 |