Skip to main content
Software Engineering

Return to Answer

added 128 characters in body
Source Link
Flater
Flater
  • 59.5k
  • 8
  • 112
  • 171

Considering those edge cases means that we're dealing with partially similar models, not fully identical ones. The consequence here is that you can't just build one reusable component to handle both of them, you need three: one for A, one for B, and one for the A/B similarities. That's a taller order, which costs more effort and complexity, and I'd start arguing that unless there is particularly unique logic here (i.e. complex business validation, not just plain validation for empty strings etc), I'd lean away from reusability here.

What I'm saying here is that you can argue this either way, and I don't think there's a clear winner here based on what you've presented.

I get the feeling that your question might be rooted in a near-dogmatic application of reusability. Your mention of "code repitition" suggestsuggests it, in my opinion,opinion; as does the fact that your question spends no time justifying the concept of reuse, merely pointing out that it could be reused and therefore that it should.
Admittedly Or, to put it differently:

enter image description here

Admittedly, this is inference on my part, but in my defense I have spent years identifying these kinds of developer behaviors and addressing them as part of a team's dev culture, which is why I'm trying to offer that here as well. The main thing I point out in these cases is:

What I'm saying here is that you can argue this either way, and I don't think there's a clear winner here.

I get the feeling that your question might be rooted in a near-dogmatic application of reusability. Your mention of "code repitition" suggest it, in my opinion, as does the fact that your question spends no time justifying the reuse, merely pointing out that it could be reused and therefore that it should.
Admittedly, this is inference on my part, but in my defense I have spent years identifying these kinds of developer behaviors and addressing them as part of a team's dev culture, which is why I'm trying to offer that here as well. The main thing I point out in these cases is:

Considering those edge cases means that we're dealing with partially similar models, not fully identical ones. The consequence here is that you can't just build one reusable component to handle both of them, you need three: one for A, one for B, and one for the A/B similarities. That's a taller order, which costs more effort and complexity, and I'd start arguing that unless there is particularly unique logic here (i.e. complex business validation, not just plain validation for empty strings etc), I'd lean away from reusability here.

What I'm saying here is that you can argue this either way, and I don't think there's a clear winner here based on what you've presented.

I get the feeling that your question might be rooted in a near-dogmatic application of reusability. Your mention of "code repitition" suggests it, in my opinion; as does the fact that your question spends no time justifying the concept of reuse, merely pointing out that it could be reused and therefore that it should. Or, to put it differently:

enter image description here

Admittedly, this is inference on my part, but in my defense I have spent years identifying these kinds of developer behaviors and addressing them as part of a team's dev culture, which is why I'm trying to offer that here as well. The main thing I point out in these cases is:

Source Link
Flater
Flater
  • 59.5k
  • 8
  • 112
  • 171

Stating the bleeding obvious here: promoting reusability entails introducing an additional abstraction which allows for said reuse.

Less obvious is that there's a difference between theoretical elegance and practical effort. Yeah, reusability would probably apply to some of these fields. But we have to weigh it against the cost of introducing reusability in a concept that generally is built on the supposition that commands are designed as independent entities. Once you tie them together, you open the door to (changes to) one command breaking the other, or alternatively to paint yourself in a corner of your reusable logic needing to cater to slightly different needs between them in the future.

Interestingly, I think you're dealing with one of both options here. From your comment:

For the Approve, yes, it doesn't necessarily need the full details.

This strongly suggests that you need to define the approval command as its separate thing, since it makes no sense to have this include fields (nor any related types that comprise these fields) that it simply does not care about. Tying this to the other commands makes no sense, the drawbacks outweigh the benefits.

However, you have a relatively strong case that the models for the Save/Submit steps need to be identical, since the only difference between them is what you subsequently do with the data, not the a distinction in the data itself. Submit having data that Save doesn't would infringe on the purpose of having the Save command in the first place. Save having data that Submit does not have makes it inherently irrelevant as you'd never use that saved data to eventually submit it.

In saying that, there are edge cases to this. For example, you might not allow certain data to be saved in advance and only to be supplied "live", so to speak. Similarly, you might allow for a "notepad" field to be stored in a save model, which won't be used in the actual submission and is only being used as a reminder for the people who are step-by-step building the form before its eventual submissions.

What I'm saying here is that you can argue this either way, and I don't think there's a clear winner here.

I get the feeling that your question might be rooted in a near-dogmatic application of reusability. Your mention of "code repitition" suggest it, in my opinion, as does the fact that your question spends no time justifying the reuse, merely pointing out that it could be reused and therefore that it should.
Admittedly, this is inference on my part, but in my defense I have spent years identifying these kinds of developer behaviors and addressing them as part of a team's dev culture, which is why I'm trying to offer that here as well. The main thing I point out in these cases is:

Just because it's identical does not mean it's the same.

What I mean by that is that just because two things are exactly the same right now, does not inherently mean that they share the same lifecycle. When deciding whether you should merge two identical items into one, you have to ask yourself the question:

If I need to change one of them in the future, am I absolutely sure that the other one needs to be changed in an identical way, in every case?

I am not across your entire set of business requirements, so I can't provide a final judgment on this. All I can say is that in my interpretation of your question you appear to be personally biased towards implementing reusability just because you can, so I would suggest you re-evaluate if this is actually the right path or if you're taking it because you're used to taking it.