5 ms·

No it isn't. Too much abstraction can always be refactored down to less abstraction. (Too much abstraction means that there's abstraction that is unnecessary,

by tinco 14y ago

No it isn't. Too much abstraction can always be refactored down to less abstraction. (Too much abstraction means that there's abstraction that is unnecessary, thus it can be cut away.) Too little abstraction means your code is too closely coupled. When the code is fresh and small, then ofcourse it's not hard to abstract out a method to DRY something up. But when your code is big and old this will quickly approach infeasability, which is the reason many projects fail. I would go as far as saying that the science of software engineering exists because your statement is false :P

andybak 14y ago
So you're saying that the arrow of refactoring generally points in the direction of less abstraction? That directly contradicts my experience where most refactoring introduces abstractions when they are needed.
- ncallaway 14y ago
 My interpretation was that he was saying the arrow of refactoring is easier when refactoring in the direction of less abstraction. I suspect he agrees that generally the arrow points in the direction of more abstraction. This would be the problem he thinks exists. Not sure where I stand on either side of this; just trying to clear up what I saw as a miscommunication.
 - tinco 14y ago
 Yes. Usually when programming one encounters problems that are solved elegantly by introducing abstraction. The parent argues that doing this too eagerly results in a big mess that should be avoided by being cautious with abstraction. I argue the converse, being too cautious with abstraction can result in a big mess and you should be eager to abstract. Of course there is a golden path in the middle, but it is closer to my side ;)
TylerE 14y ago
I have one word for you: InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButton
- programminggeek 14y ago
  Too much abstraction or indirection will certainly lead you down that path, but that is not really what I would advocate at all. With Obvious the goal is to make it feel obvious what the system is doing. No big complicated inheritance systems. Instead it uses a bit of indirection via dependency injection and reflection to make the data plugs swappable. Nothing too crazy or complicated.

by tinco 14y ago

andybak 14y ago

So you're saying that the arrow of refactoring generally points in the direction of less abstraction? That directly contradicts my experience where most refactoring introduces abstractions when they are needed.

ncallaway 14y ago
My interpretation was that he was saying the arrow of refactoring is easier when refactoring in the direction of less abstraction. I suspect he agrees that generally the arrow points in the direction of more abstraction. This would be the problem he thinks exists. Not sure where I stand on either side of this; just trying to clear up what I saw as a miscommunication.
- tinco 14y ago
 Yes. Usually when programming one encounters problems that are solved elegantly by introducing abstraction. The parent argues that doing this too eagerly results in a big mess that should be avoided by being cautious with abstraction. I argue the converse, being too cautious with abstraction can result in a big mess and you should be eager to abstract. Of course there is a golden path in the middle, but it is closer to my side ;)

TylerE 14y ago

I have one word for you: InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButton

programminggeek 14y ago
Too much abstraction or indirection will certainly lead you down that path, but that is not really what I would advocate at all. With Obvious the goal is to make it feel obvious what the system is doing. No big complicated inheritance systems. Instead it uses a bit of indirection via dependency injection and reflection to make the data plugs swappable. Nothing too crazy or complicated.