Performance and good design are sometimes in tension. In my experience performance issues should be delayed as possible. Unless you are building a time critical software good designs should always be prioritized.
I 100% agree. To clarify, my point was just that performane can be a reason to prefer if statements, but only after the code has been found to be a performance bottleneck. Prematurely using low-level constructs where a higher-level abstraction would improve code quality is, as always, bad style.
Are you very sure if this than that is common among not developers? I don't really think so on accidental IFs
Depending on the situation, I am very much convinced. People say "If the weather is good, we can go to the park tomorrow", not "tomorrow we can do a weather-appropriate activity, where going to the park would be appropriate for sunny weather". This obviously isn't necessarily universal, but it does seem like a tendency.
I think you are confusing accidental concepts (like JSON or YAML) with essential ones (behavior).
I did mention those, but only to give a specific example. My main point is independent of data description formats though: The mapping from Rating to minimum age, is (or rather falls on the side of) data, not logic
I say data is accidental and we should never care about it at all
On the contrary: Data is the only thing we should care about. After all, the only purpose of any program is to take input data and turning it into output data.
Extensibility is key when you design very large systems with millions of code lines (as I do). Breaking up the code and refactoring is the only way of evolving the system and IFs are always blockers and defects source.
Our opinions seem to run parallel here. Looking back at my code example, you end up getting the same level of extensibility. It is easy to add another rating by appending an entry to the map. This is certainly also achieved by your method of encoding this relationship in objects, but my main point of criticism is that it encodes what I would consider a constant¹ as an object method.
¹ note that I don't consider a numeric constant like 42 to be any different from a hugely complex constant data-structure. The defining factor is it's immutability during program execution.
What I consider naive with that pattern is that it adds complexity to the code. If you were to draw flow-charts of both implementations, one of them ends up showing the relationships, while the other treats them as additional input data.
Breaking up the code and refactoring is the only way of evolving the system and IFs are always blockers and defects source.
Not in my experience at least. Assuming performance is not critical, refactoring code with many conditionals can be done in many ways and I personally prefer representing the complex decision logic using data structures. This sometimes goes almost full-circle: depending on the language, data-structures can contain code (usually in the form of functions), which then looks surprisingly similar to an object, which is ultimately just a handle for a collection of behaviours, not unlike a data-structure containing functions.
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
I think the main disagreement comes from this perception of software.
On the contrary: Data is the only thing we should care about. After all, the only purpose of any program is to take input data and turning it into output data.
I don't care about data because I see software as a model and predictor and data is accidental.
If we were to design a weather forecaster I would not see temperature and pressure indicators as data flowing into the system. I'd like to see the model as a simulator and predictor of actual conditions.
So out forecasted data like estimated temperature, wind speed and thus would be accidental. What would be essential (IMHO) is the model behaving like real weather.
If you get too coupled to data you cannot change them as long as requirements change. And I personally think end users don't care about data. It is us, developers, who care too much about that. User wish a system do what they would need to achieve manually.
You prefer representing the complex decision logic using data structures and this is fine. you want to see all the information centralized and this is tradeoff decision. This is the structural programming approach and is very good.
I'm just pointing out there other ways of simulating real world.
Definitely. But either way, I still find it very interesting to see how someone else thinks about software systems completely differently, as I don't believe neither of us is inherently more "right" or "wrong" than the other.
To end on a positive conclusion: I think we can extrapolate from this that OOP, with its emphasis on systems and behaviours and FP, with its contrasting emphasis on data flow and transformations can both be the right or wrong tool for any individual developer and/or team, depending largely on how they tend to think about computation.
Not that this is a groundbreaking deduction, but it's something that's easily forgotten :D
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
I 100% agree. To clarify, my point was just that performane can be a reason to prefer
ifstatements, but only after the code has been found to be a performance bottleneck. Prematurely using low-level constructs where a higher-level abstraction would improve code quality is, as always, bad style.Depending on the situation, I am very much convinced. People say "If the weather is good, we can go to the park tomorrow", not "tomorrow we can do a weather-appropriate activity, where going to the park would be appropriate for sunny weather". This obviously isn't necessarily universal, but it does seem like a tendency.
I did mention those, but only to give a specific example. My main point is independent of data description formats though: The mapping from Rating to minimum age, is (or rather falls on the side of) data, not logic
On the contrary: Data is the only thing we should care about. After all, the only purpose of any program is to take input data and turning it into output data.
Our opinions seem to run parallel here. Looking back at my code example, you end up getting the same level of extensibility. It is easy to add another rating by appending an entry to the map. This is certainly also achieved by your method of encoding this relationship in objects, but my main point of criticism is that it encodes what I would consider a constant¹ as an object method.
¹ note that I don't consider a numeric constant like
42to be any different from a hugely complex constant data-structure. The defining factor is it's immutability during program execution.What I consider naive with that pattern is that it adds complexity to the code. If you were to draw flow-charts of both implementations, one of them ends up showing the relationships, while the other treats them as additional input data.
Not in my experience at least. Assuming performance is not critical, refactoring code with many conditionals can be done in many ways and I personally prefer representing the complex decision logic using data structures. This sometimes goes almost full-circle: depending on the language, data-structures can contain code (usually in the form of functions), which then looks surprisingly similar to an object, which is ultimately just a handle for a collection of behaviours, not unlike a data-structure containing functions.
Hi again.
We agree to disagree :)
I think the main disagreement comes from this perception of software.
On the contrary: Data is the only thing we should care about. After all, the only purpose of any program is to take input data and turning it into output data.
I don't care about data because I see software as a model and predictor and data is accidental.
If we were to design a weather forecaster I would not see temperature and pressure indicators as data flowing into the system. I'd like to see the model as a simulator and predictor of actual conditions.
So out forecasted data like estimated temperature, wind speed and thus would be accidental. What would be essential (IMHO) is the model behaving like real weather.
If you get too coupled to data you cannot change them as long as requirements change. And I personally think end users don't care about data. It is us, developers, who care too much about that. User wish a system do what they would need to achieve manually.
You prefer representing the complex decision logic using data structures and this is fine. you want to see all the information centralized and this is tradeoff decision. This is the structural programming approach and is very good.
I'm just pointing out there other ways of simulating real world.
Again. All my opinions
Definitely. But either way, I still find it very interesting to see how someone else thinks about software systems completely differently, as I don't believe neither of us is inherently more "right" or "wrong" than the other.
To end on a positive conclusion: I think we can extrapolate from this that OOP, with its emphasis on systems and behaviours and FP, with its contrasting emphasis on data flow and transformations can both be the right or wrong tool for any individual developer and/or team, depending largely on how they tend to think about computation.
Not that this is a groundbreaking deduction, but it's something that's easily forgotten :D
It is very nice learning with you
I think there are no silver bullets.
different projects need different solutions