Fowler Quotes - Build Abstractions
-
I'm watching The Software Architecture Hour with Neal Ford with Guest Martin Fowler[^] (on O'Reilly). Fowler said a couple of very interesting things about abstraction that get to the root of OOP.
Martin Fowler
"...the key to controlling complexity in software is the ability to build abstractions for your particular circumstance and then be able to evolve those abstractions and use those abstractions to write & compose into better solutions."
He then said,
Fowler on Spreadsheets...
"one of the most successful programming environment...the most widely used programming environments that is out there is spreadsheets. For relatively simple tasks they can be very effective. But again, this inability to create your own abstractions... The fact that you all the time have to work at the level of rows & columns does end up getting in the way."
Often, people who write one-off solutions or who see the solution too simplistically (from a higher level, like a manager) think you are wasting time Engineering or Designing a solution that works to solve a Class of Problems.
Martin Fowler:
"If you can't build your own abstractions, you're not going to be able to tackle anything of serious complexity."
-
I'm watching The Software Architecture Hour with Neal Ford with Guest Martin Fowler[^] (on O'Reilly). Fowler said a couple of very interesting things about abstraction that get to the root of OOP.
Martin Fowler
"...the key to controlling complexity in software is the ability to build abstractions for your particular circumstance and then be able to evolve those abstractions and use those abstractions to write & compose into better solutions."
He then said,
Fowler on Spreadsheets...
"one of the most successful programming environment...the most widely used programming environments that is out there is spreadsheets. For relatively simple tasks they can be very effective. But again, this inability to create your own abstractions... The fact that you all the time have to work at the level of rows & columns does end up getting in the way."
Often, people who write one-off solutions or who see the solution too simplistically (from a higher level, like a manager) think you are wasting time Engineering or Designing a solution that works to solve a Class of Problems.
Martin Fowler:
"If you can't build your own abstractions, you're not going to be able to tackle anything of serious complexity."
And Marc says, abstractions are great, but you need concrete code to get things done.
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain -
And Marc says, abstractions are great, but you need concrete code to get things done.
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a DomainMarc Clifton wrote:
you need concrete code to get things done.
I agree, but you know the Abstractions Fowler is talking about are code too, right? I also understand that there are times that "Architects" create "Class Hierarchies" which offer little to no benefit, but being able to interact with higher level things is almost always better than fussing over pedantic details every time. Of course, the counterpoint to that is, "Someone, somewhere has to write the pedantic code that parses each byte or whatever." But that should be properly stuck behind an interface (notice small i) and used as a black box to save time. It's just if you get stuck thinking at the level of bytes then you can never get enough air to be able to see the whole picture. Of course, again, if you're doing embedded type of work this will all sound ridiculous again. But creating larger solutions based upon step-by-step details will probably preclude you from ever building something "bigger". Lots of trade-offs. But when it comes to Business-Logic (IT World - versus aforementioned embedded) Abstractions provide a strong ability to get large projects done. I myself am back & forth on it, because I do quite a bit of embedded, backend, detailed algos and then also want to just crank out a usable End-User Product.
-
I'm watching The Software Architecture Hour with Neal Ford with Guest Martin Fowler[^] (on O'Reilly). Fowler said a couple of very interesting things about abstraction that get to the root of OOP.
Martin Fowler
"...the key to controlling complexity in software is the ability to build abstractions for your particular circumstance and then be able to evolve those abstractions and use those abstractions to write & compose into better solutions."
He then said,
Fowler on Spreadsheets...
"one of the most successful programming environment...the most widely used programming environments that is out there is spreadsheets. For relatively simple tasks they can be very effective. But again, this inability to create your own abstractions... The fact that you all the time have to work at the level of rows & columns does end up getting in the way."
Often, people who write one-off solutions or who see the solution too simplistically (from a higher level, like a manager) think you are wasting time Engineering or Designing a solution that works to solve a Class of Problems.
Martin Fowler:
"If you can't build your own abstractions, you're not going to be able to tackle anything of serious complexity."
Yes, but still... " When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all. These are the people I call Architecture Astronauts. " -- Don’t Let Architecture Astronauts Scare You – Joel on Software[^] If'n I recall correctly, several years ago there was a member whose signature included an admonition against making something generic before you have seen at least three examples to go from. Someone who can't think in abstractions will not succeed, nor will someone who thinks only in abstractions. It's about balance.
-
I'm watching The Software Architecture Hour with Neal Ford with Guest Martin Fowler[^] (on O'Reilly). Fowler said a couple of very interesting things about abstraction that get to the root of OOP.
Martin Fowler
"...the key to controlling complexity in software is the ability to build abstractions for your particular circumstance and then be able to evolve those abstractions and use those abstractions to write & compose into better solutions."
He then said,
Fowler on Spreadsheets...
"one of the most successful programming environment...the most widely used programming environments that is out there is spreadsheets. For relatively simple tasks they can be very effective. But again, this inability to create your own abstractions... The fact that you all the time have to work at the level of rows & columns does end up getting in the way."
Often, people who write one-off solutions or who see the solution too simplistically (from a higher level, like a manager) think you are wasting time Engineering or Designing a solution that works to solve a Class of Problems.
Martin Fowler:
"If you can't build your own abstractions, you're not going to be able to tackle anything of serious complexity."
A round-about way of saying you need to "analyze; then design". He could have just as well said "model" instead of abstraction and more people would have understood what he was talking about. ERD diagrams, UML diagrams, etc. are all "models" / abstractions to help create the "final" abstraction (of some process) in code.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
