Return to Answer

Given how limited my knowledge of your program is right now my advice is to leave those 3 lines alone.

The issue is you're describing the problem structurally. Some program... End of some method... three lines... There's no story here. No context for this idea to live in.

You're trying to fit an idea into your structured frame of thinking about code and it's flat out breaking it. The concept of "doing one thing" makes no sense when you can literally stuff the entire program into one thing.

This rule isn't about structure. It's about ideas. You could insist that an aardvark riding a bicycle is one thing, but it's a damn weird thing. An aardvark on it's own and a bicycle on it's own are less weird so I'm against the AardvarkBicycle class.

If that seems unsatisfying because it's subjective I say too bad. We're designing software that humans can understand so get used to dealing with our weird human bias.

In his latest book Clean Architecture Uncle Bob redefines the Single Responsibility Principle, when applied specifically to classes, in the context of who the code is responsible to. No class can serve two masters. This is a fine consideration but you're insane if it's your only one. In this view, theoretically, it'd be fine to identify all your stakeholders and give them each their own class and stop decomposing right there. Bleh. That is not what Uncle Bob is saying.

If you insist on thinking structurally the best reason to pick a class over a function is because there is some persisting data that you want to use to change your behavior. Some data that you learn at a different time then when you exhibit your behavior. Now if you only have one behavior a closure might be good enough, if your language has that. If you have two behaviors that need to vary based on this same data you are firmly in object land. Objects are bags of functions that change their behavior together

If you'll join me in also thinking semantically, not just structurally, you'll find it makes sense to extract something as a class if you can think of a good noun that ensures when someone looks inside and sees the details they find pretty much what they expected. If you surprise them you've failed. For functions it's the same story, just with a verb. In either case the fancy term for this is abstraction.

And don't think I didn't notice you using nouns as verbs in the question title :P

If you still feel like you must extract this code I recommend reading up on the hole in the middle pattern

With this limited knowledge of your program, right now my advice is to leave those 3 lines alone.

The issue is you're describing the problem structurally. Some program... End of some method... three lines... There's no story here. No context for this idea to live in.

You're trying to fit an idea into your structured frame of thinking about code and it's flat out breaking it. The concept of "doing one thing" makes no sense when you can literally stuff the entire program into one thing.

This rule isn't about structure. It's about ideas. You could insist that an aardvark riding a bicycle is one thing, but it's a damn weird thing. An aardvark on it's own and a bicycle on it's own are less weird so I'm against the AardvarkBicycle class.

If that seems unsatisfying because it's subjective I say too bad. We're designing software that humans can understand so get used to dealing with our weird human bias.

In his latest book Clean Architecture Uncle Bob redefines the Single Responsibility Principle, when applied specifically to classes, in the context of who the code is responsible to. No class can serve two masters. This is a fine consideration but you're insane if it's your only one. In this view, theoretically, it'd be fine to identify all your stakeholders and give them each their own class and stop decomposing right there. Bleh. That is not what Uncle Bob is saying.

If you insist on thinking structurally the best reason to pick a class over a function is because there is some persisting data that you want to use to change your behavior. Some data that you learn at a different time then when you exhibit your behavior. Now if you only have one behavior a closure might be good enough, if your language has that. If you have two behaviors that need to vary based on this same data you are firmly in object land. Objects are bags of functions that change their behavior together

If you'll join me in also thinking semantically, not just structurally, you'll find it makes sense to extract something as a class if you can think of a good noun that ensures when someone looks inside and sees the details they find pretty much what they expected. If you surprise them you've failed. For functions it's the same story, just with a verb. In either case the fancy term for this is abstraction.

And don't think I didn't notice you using nouns as verbs in the question title :P

If you still feel like you must extract this code I recommend reading up on the hole in the middle pattern

Given how limited my knowledge of your program is right now my advice is to leave those 3 lines alone.

The issue is you're describing the problem structurally. Some program... End of some method... three lines... There's no story here. No context for this idea to live in.

You're trying to fit an idea into your structured frame of thinking about code and it's flat out breaking it. The concept of "doing one thing" makes no sense when you can literally stuff the entire program into one thing.

This rule isn't about structure. It's about ideas. You could insist that an aardvark riding a bicycle is one thing, but it's a damn weird thing. An aardvark on it's own and a bicycle on it's own are less weird so I'm against the AardvarkBicycle class.

If that seems unsatisfying because it's subjective I say too bad. We're designing software that humans can understand so get used to dealing with our weird human bias.

In his latest book Clean Architecture Uncle Bob redefines the Single Responsibility Principle, when applied specifically to classes, in the context of who the code is responsible to. No class can serve two masters. This is a fine consideration but you're insane if it's your only one. In this view, theoretically, it'd be fine to identify all your stakeholders and give them each their own class and stop decomposing right there. Bleh. That is not what Uncle Bob is saying.

If you insist on thinking structurally the best reason to pick a class over a function is because there is some persisting data that you want to use to change your behavior. Some data that you learn at a different time then when you exhibit your behavior. Now if you only have one behavior a closure might be good enough, if your language has that. If you have two behaviors that need to vary based on this same data you are firmly in object land. Objects are bags of functions that change their behavior together

If you'll join me in also thinking semantically, not just structurally, you'll find it makes sense to extract something as a class if you can think of a good noun that ensures when someone looks inside and sees the details they find pretty much what they expected. If you surprise them you've failed. For functions it's the same story, just with a verb.

And don't think I didn't notice you using nouns as verbs in the question title :P

If you still feel like you must extract this code I recommend reading up on the hole in the middle pattern

Given how limited my knowledge of your program is right now my advice is to leave those 3 lines alone.

The issue is you're describing the problem structurally. Some program... End of some method... three lines... There's no story here. No context for this idea to live in.

You're trying to fit an idea into your structured frame of thinking about code and it's flat out breaking it. The concept of "doing one thing" makes no sense when you can literally stuff the entire program into one thing.

This rule isn't about structure. It's about ideas. You could insist that an aardvark riding a bicycle is one thing, but it's a damn weird thing. An aardvark on it's own and a bicycle on it's own are less weird so I'm against the AardvarkBicycle class.

If that seems unsatisfying because it's subjective I say too bad. We're designing software that humans can understand so get used to dealing with our weird human bias.

In his latest book Clean Architecture Uncle Bob redefines the Single Responsibility Principle, when applied specifically to classes, in the context of who the code is responsible to. No class can serve two masters. This is a fine consideration but you're insane if it's your only one. In this view, theoretically, it'd be fine to identify all your stakeholders and give them each their own class and stop decomposing right there. Bleh. That is not what Uncle Bob is saying.

If you insist on thinking structurally the best reason to pick a class over a function is because there is some persisting data that you want to use to change your behavior. Some data that you learn at a different time then when you exhibit your behavior. Now if you only have one behavior a closure might be good enough, if your language has that. If you have two behaviors that need to vary based on this same data you are firmly in object land. Objects are bags of functions that change their behavior together

If you'll join me in also thinking semantically, not just structurally, you'll find it makes sense to extract something as a class if you can think of a good noun that ensures when someone looks inside and sees the details they find pretty much what they expected. If you surprise them you've failed. For functions it's the same story, just with a verb. In either case the fancy term for this is abstraction.

And don't think I didn't notice you using nouns as verbs in the question title :P

If you still feel like you must extract this code I recommend reading up on the hole in the middle pattern

Given how limited my knowledge of your program is right now my advice is to leave those 3 lines alone.

The issue is you're describing the problem structurally. Some program... End of some method... three lines... There's no story here. No context for this idea to live in.

You're trying to fit an idea into your structured frame of thinking about code and it's flat out breaking it. The concept of "doing one thing" makes no sense when you can literally stuff the entire program into one thing.

This rule isn't about structure. It's about ideas. You could insist that an aardvark riding a bicycle is one thing, but it's a damn weird thing. An aardvark on it's own and a bicycle on it's own are less weird so I'm against the AardvarkBicycle class.

If that seems unsatisfying because it's subjective I say too bad. We're designing software that humans can understand so get used to dealing with our weird human bias.

In his latest book Clean Architecture Uncle Bob redefines the Single Responsibility Principle, when applied specifically to classes, in the context of who the code is responsible to. No class can service two masters. This is a fine consideration but you're insane if it's your only one. In this view, theoretically, it'd be fine to identify all your stakeholders and give them each their own class and stop decomposing right there. Bleh. That is not what Uncle Bob is saying.

If you insist on thinking structurally the best reason to pick a class over a function is because there is some persisting data that you want to use to change your behavior. Some data that you learn at a different time then when you exhibit your behavior. Now if you only have one behavior a closure might be good enough, if your language has that. If you have two behaviors that need to vary based on this same data you are firmly in object land. Objects are bags of functions that change their behavior together

If you'll join me in also thinking semantically, not just structurally, you'll find it makes sense to extract something as a class if you can think of a good noun that ensures when someone looks inside and sees the details they find pretty much what they expected. If you surprise them you've failed. For functions it's the same story, just with a verb.

If you still feel like you must extract this code I recommend reading up on the hole in the middle pattern

Given how limited my knowledge of your program is right now my advice is to leave those 3 lines alone.

The issue is you're describing the problem structurally. Some program... End of some method... three lines... There's no story here. No context for this idea to live in.

You're trying to fit an idea into your structured frame of thinking about code and it's flat out breaking it. The concept of "doing one thing" makes no sense when you can literally stuff the entire program into one thing.

This rule isn't about structure. It's about ideas. You could insist that an aardvark riding a bicycle is one thing, but it's a damn weird thing. An aardvark on it's own and a bicycle on it's own are less weird so I'm against the AardvarkBicycle class.

If that seems unsatisfying because it's subjective I say too bad. We're designing software that humans can understand so get used to dealing with our weird human bias.

In his latest book Clean Architecture Uncle Bob redefines the Single Responsibility Principle, when applied specifically to classes, in the context of who the code is responsible to. No class can serve two masters. This is a fine consideration but you're insane if it's your only one. In this view, theoretically, it'd be fine to identify all your stakeholders and give them each their own class and stop decomposing right there. Bleh. That is not what Uncle Bob is saying.

If you insist on thinking structurally the best reason to pick a class over a function is because there is some persisting data that you want to use to change your behavior. Some data that you learn at a different time then when you exhibit your behavior. Now if you only have one behavior a closure might be good enough, if your language has that. If you have two behaviors that need to vary based on this same data you are firmly in object land. Objects are bags of functions that change their behavior together

If you'll join me in also thinking semantically, not just structurally, you'll find it makes sense to extract something as a class if you can think of a good noun that ensures when someone looks inside and sees the details they find pretty much what they expected. If you surprise them you've failed. For functions it's the same story, just with a verb.

And don't think I didn't notice you using nouns as verbs in the question title :P

If you still feel like you must extract this code I recommend reading up on the hole in the middle pattern