Timeline for Does "declare the most abstract type" increase coupling actually?
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 30, 2023 at 9:07 | history | edited | wcminipgasker2023 | CC BY-SA 4.0 |
added 434 characters in body
|
| Oct 27, 2023 at 17:11 | answer | added | JimmyJames | timeline score: 0 | |
| Oct 26, 2023 at 20:28 | comment | added | JimmyJames | @candied_orange That's great and all but it has nothing to do with my comment. I'm not sure why you are addressing my comment and talking about something that doesn't have anything to do with my point. My initial point was directed at the OP and has nothing to do with whatever you are talking about. | |
| Oct 26, 2023 at 20:00 | comment | added | candied_orange |
@JimmyJames If you read my response to that comment carefully you'll see I was talking about avoiding doing that. Your follow up question seems to insist that I'm talking about compiling Orange without Fruit. I'm not. I'm talking about compiling UseingCode without Orange. I've tried to make this clear 5 different ways now. I'm starting to lose faith in my ability to communicate.
|
|
| Oct 26, 2023 at 19:41 | comment | added | JimmyJames |
@candied_orange I think you just need to read my first comment more carefully. I said depending on Orange has an implicit dependency on Fruit. This isn't controversial. It's part of the definition of Orange.
|
|
| Oct 26, 2023 at 18:02 | comment | added | candied_orange |
@JimmyJames I already said that Orange knows about Fruit. Will it help if I diagram it? UsingCode->Fruit<|-Orange. Notice that nothing is pointing at Orange? If you don't point at it you can be compiled without it.
|
|
| Oct 26, 2023 at 17:32 | comment | added | JimmyJames |
@candied_orange Orange won't compile. How are you going to load the Orange class that isn't consistent with your Fruit interface? Whether you explicitly depend on Fruit is irrelevant.
|
|
| Oct 26, 2023 at 17:22 | comment | added | candied_orange |
@JimmyJames I can compile Fruit using code that has never heard of an Orange. It wont do much until some other complication unit hands it an Orange but it will compile just fine.
|
|
| Oct 26, 2023 at 17:15 | comment | added | JimmyJames |
@candied_orange I don't really see your point. If you change Fruit (the only scenario that matters) you will need change Orange or your compilation will fail, or you will get a runtime error.
|
|
| Oct 26, 2023 at 17:11 | comment | added | candied_orange |
@JimmyJames You compile the using code without telling it that Orange exists. Both the using code and Orange know Fruit exists but not each other. Fruit doesn't know either one exists. Do it that way and different teams of Devs can develop these independently so long as they agree on Fruit.
|
|
| Oct 26, 2023 at 17:01 | comment | added | JimmyJames |
@candied_orange I don't follow. How do you compile Orange if it isn't a valid Fruit?
|
|
| Oct 26, 2023 at 16:51 | comment | added | candied_orange |
@JimmyJames By depending on Fruit and not in any explicit way on Orange you are so loosely coupled to Orange that you are independently deployable.
|
|
| Oct 25, 2023 at 20:04 | comment | added | JimmyJames |
Another thing to consider here is that the Orange class is already coupled to the Fruit interface. That is that changes to the Fruit interface will generally require changes to the Orange class. By depending on Orange, you've got a transitive dependency on Fruit whether you import it or not.
|
|
| Oct 25, 2023 at 17:53 | answer | added | Tulains Córdova | timeline score: 2 | |
| Oct 25, 2023 at 16:31 | comment | added | Filip Milovanović |
Well, you can't really understand this by looking at the main function, as main is really "glue" code. You'd actually have something like a separate class (or even just a function) that takes in a Fruit, and expresses all of it's logic in terms of Fruit (never mentioning any derived type). That other class is decoupled from the concrete types. Note however, that just having a class extend an interface is not enough to decouple its clients from it. It's the kinds of methods you choose to put on that interface that allow for decoupling (or not).
|
|
| Oct 25, 2023 at 15:09 | answer | added | candied_orange | timeline score: 3 | |
| Oct 25, 2023 at 10:56 | answer | added | bdsl | timeline score: 4 | |
| Oct 25, 2023 at 8:55 | review | Close votes | |||
| Oct 30, 2023 at 3:09 | |||||
| Oct 25, 2023 at 7:26 | comment | added | Philip Kendall | "Because I think "coupling" of a class is about counting how many other class names appeared in the source file" Spoiler: it's not, at least not as simplistically as you do it here. | |
| Oct 25, 2023 at 5:34 | comment | added | Jacob is on Codidact | First, this is mainly important for your inputs and outputs, not local variables. Second, softwareengineering.stackexchange.com/questions/237113/… | |
| Oct 25, 2023 at 3:27 | history | asked | wcminipgasker2023 | CC BY-SA 4.0 |