Jay Myers, Software Engineer
October 5, 2016

How is maintaining a spider plant like writing code? The author of this blog posts makes this comparison to illustrate the single responsibility principle – the first of the SOLID design principles.


spider plant

Several years ago a friend of mine gave me a spider plant as a birthday gift. More accurately, she gave each of her friends one of these plants that year on their birthday. Just in case you aren’t aware (or don’t want to have to look it up), a spider plant grows little baby plants off of its stalks. You can break these baby plants off and plant them and eventually they will become full-fledged plants of their own.

Turns out that each of us got a baby plant that had grown off of the same adult plant which she had obtained in much the same way from her Grandmother. Smash cut to present day, and the room I’m sitting in while writing this has a few full sized plants and several baby plants that have just recently been given their own pots. Pretty neat, considering that I’m one of about a dozen people who have plants that are all part of the same, uh, “family” I guess you’d call it.

Now, the plant’s goal in all this isn’t to have people break the smaller plants off and put them into their own pots. It’s doing this to allow its stalks to become heavy enough to droop down and touch the soil, where the smaller plant can take root and spread out like ivy. But since the floor of my bedroom is, to my knowledge, mostly soil free it just serves to weigh the plant down and make it annoying to move or re-pot as it grows larger. It makes dealing with the plant a lot harder than it should be.

Code works in much the same way – in fact, pulling bits apart that don’t belong together is something that we do all the time. The motivations for this are similar to why you might split up a spider plant or, say, move out after college. At a certain point, it becomes evident that it’s detrimental for one entity to have to be responsible for the concerns of two (or more) separate entities. What we’re really talking about here is the single responsibility principle – the first of the SOLID design principles. But let’s try and walk through a relatively simple example to illustrate what this principle is all about.

Our story begins with a class. A simple class that looks something like this.

public class Customer

{

public void SetShippingAddress(string address)

public void SetBillingAddress(string address)

private void ValidateAddress(string address)

}

This class is in charge of keeping track of shipping and billing addresses for a customer (imagine this is a world where each customer only gets one of each). It is also in charge of validating each address, which it does in its ValidateAddress method. But then, one day, the shipping department approaches you and tells you that we will no longer be accepting any new shipping addresses that use P.O. boxes. Fine – no big deal, we’ll just do something like this.

public class Customer

{

public void SetShippingAddress(string address)

public void SetBillingAddress(string address)

private void ValidateAddress(string address, bool isShipping)

}

So now the ValidateAddress method has a little bit of extra logic that checks to see if we’re dealing with a shipping address and if we are then it rejects any that contain a P.O. box. And this works for a while. Until one day, Billing comes to you and says that we will no longer be accepting new billing addresses from Texas or Maine due to some new laws in those states. Ok, well, we can add extra logic into our method to handle that, but now this ValidateAddress method is getting a little unruly. So, maybe we can split it apart into two separate methods.

public class Customer

{

public void SetShippingAddress(string address)

public void SetBillingAddress(string address)

private void ValidateShippingAddress(string address)

private void ValidateBillingAddress(string address)

}

Let’s just ignore the fact that there is probably some basic shared validation between these two methods for now (we’ll come back to that later). I mean, this is ok I guess – but it doesn’t really sit right that we had to keep changing the Customer class because shipping and billing address related business rules changed. I mean, sure, a customer has both of those things – but does it need to hold their business rules? What if we had something that looked like this?

public class Customer

{

public void SetShippingAddress(ShippingAddress address)

public void SetBillingAddress(BillingAddress address)

}

Where ShippingAddress and BillingAddress were separate classes that contained the business rules for what constituted valid addresses. Then, as rules around those kinds of addresses change, the Customer class remains unchanged. That is what the principle is really all about – a class having only one reason to change.

What about all that shared logic, you say? Shouldn’t it be pulled out into some shared address validation library? Well… maybe. In this particular example, it most likely makes sense to have a shared address validation (or perhaps a base Address class that is in charge of such things). But in another scenario, that may not be the case. Consider something in charge of displaying these addresses for instance – it’s entirely possible that Shipping and Billing could start out with the same display format, only to deviate from one another at a later point in time. In that case, a shared library for display would have two reasons to change – the demands of the Shipping users and the demands of the Billing users.

Now, I know that this was a pretty contrived example. But if you’re at all like me and enjoy watching long talks about software architecture and design then I would encourage you to watch this explanation of the single responsibility principle. I know it helped me grasp the concept – hopefully, it can be beneficial to you as well.

Links:

Spider plant – https://en.wikipedia.org/wiki/Chlorophytum_comosum
Single Responsibility Principle – https://8thlight.com/blog/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
SOLID – https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
This explanation – https://www.youtube.com/watch?v=Gt0M_OHKhQE&ab_channel=gnbitcom

Jay Myers, Software Engineer
October 5, 2016

How is maintaining a spider plant like writing code? The author of this blog posts makes this comparison to illustrate the single responsibility principle – the first of the SOLID design principles.


spider plant

Several years ago a friend of mine gave me a spider plant as a birthday gift. More accurately, she gave each of her friends one of these plants that year on their birthday. Just in case you aren’t aware (or don’t want to have to look it up), a spider plant grows little baby plants off of its stalks. You can break these baby plants off and plant them and eventually they will become full-fledged plants of their own.

Turns out that each of us got a baby plant that had grown off of the same adult plant which she had obtained in much the same way from her Grandmother. Smash cut to present day, and the room I’m sitting in while writing this has a few full sized plants and several baby plants that have just recently been given their own pots. Pretty neat, considering that I’m one of about a dozen people who have plants that are all part of the same, uh, “family” I guess you’d call it.

Now, the plant’s goal in all this isn’t to have people break the smaller plants off and put them into their own pots. It’s doing this to allow its stalks to become heavy enough to droop down and touch the soil, where the smaller plant can take root and spread out like ivy. But since the floor of my bedroom is, to my knowledge, mostly soil free it just serves to weigh the plant down and make it annoying to move or re-pot as it grows larger. It makes dealing with the plant a lot harder than it should be.

Code works in much the same way – in fact, pulling bits apart that don’t belong together is something that we do all the time. The motivations for this are similar to why you might split up a spider plant or, say, move out after college. At a certain point, it becomes evident that it’s detrimental for one entity to have to be responsible for the concerns of two (or more) separate entities. What we’re really talking about here is the single responsibility principle – the first of the SOLID design principles. But let’s try and walk through a relatively simple example to illustrate what this principle is all about.

Our story begins with a class. A simple class that looks something like this.

public class Customer

{

public void SetShippingAddress(string address)

public void SetBillingAddress(string address)

private void ValidateAddress(string address)

}

This class is in charge of keeping track of shipping and billing addresses for a customer (imagine this is a world where each customer only gets one of each). It is also in charge of validating each address, which it does in its ValidateAddress method. But then, one day, the shipping department approaches you and tells you that we will no longer be accepting any new shipping addresses that use P.O. boxes. Fine – no big deal, we’ll just do something like this.

public class Customer

{

public void SetShippingAddress(string address)

public void SetBillingAddress(string address)

private void ValidateAddress(string address, bool isShipping)

}

So now the ValidateAddress method has a little bit of extra logic that checks to see if we’re dealing with a shipping address and if we are then it rejects any that contain a P.O. box. And this works for a while. Until one day, Billing comes to you and says that we will no longer be accepting new billing addresses from Texas or Maine due to some new laws in those states. Ok, well, we can add extra logic into our method to handle that, but now this ValidateAddress method is getting a little unruly. So, maybe we can split it apart into two separate methods.

public class Customer

{

public void SetShippingAddress(string address)

public void SetBillingAddress(string address)

private void ValidateShippingAddress(string address)

private void ValidateBillingAddress(string address)

}

Let’s just ignore the fact that there is probably some basic shared validation between these two methods for now (we’ll come back to that later). I mean, this is ok I guess – but it doesn’t really sit right that we had to keep changing the Customer class because shipping and billing address related business rules changed. I mean, sure, a customer has both of those things – but does it need to hold their business rules? What if we had something that looked like this?

public class Customer

{

public void SetShippingAddress(ShippingAddress address)

public void SetBillingAddress(BillingAddress address)

}

Where ShippingAddress and BillingAddress were separate classes that contained the business rules for what constituted valid addresses. Then, as rules around those kinds of addresses change, the Customer class remains unchanged. That is what the principle is really all about – a class having only one reason to change.

What about all that shared logic, you say? Shouldn’t it be pulled out into some shared address validation library? Well… maybe. In this particular example, it most likely makes sense to have a shared address validation (or perhaps a base Address class that is in charge of such things). But in another scenario, that may not be the case. Consider something in charge of displaying these addresses for instance – it’s entirely possible that Shipping and Billing could start out with the same display format, only to deviate from one another at a later point in time. In that case, a shared library for display would have two reasons to change – the demands of the Shipping users and the demands of the Billing users.

Now, I know that this was a pretty contrived example. But if you’re at all like me and enjoy watching long talks about software architecture and design then I would encourage you to watch this explanation of the single responsibility principle. I know it helped me grasp the concept – hopefully, it can be beneficial to you as well.

Links:

Spider plant – https://en.wikipedia.org/wiki/Chlorophytum_comosum
Single Responsibility Principle – https://8thlight.com/blog/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
SOLID – https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
This explanation – https://www.youtube.com/watch?v=Gt0M_OHKhQE&ab_channel=gnbitcom