Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
I was thinking about having maybe a getUserById and then a getUserByEmail, if you gonna DRY you can join both together in a getUserBySomething so you avoid repeating most of the query, but then you will have a conditional inside your function that makes the function more complex and it also breaks the Single Responsibility principle and it's worse IMHO.
Single Responsibility does not mean all functions must only do one thing.
For example if we need new behavior, we simply write a new method whose name indicates that single responsibility. It then allows for parameters to change behaviors. It can contain calls to many other functions but strictly only does what the name implies.
I call this a decorator pattern because it adds functionality by use of optional parameters. Allows parts to be added at will, but never departs from what the name implies. It only does that one thing.
The decorated function prefers use of reusable SRP functions because that code is already done and bullet proof. They are closed for modification.
The Concept is so simple but often confuses pepple.
Doing more than one thing in a function composed of SRP Functions is only more fragile if tests prove it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My guideline is once, sometimes twice but never three times.
Single Responsibility principal is king and applies to functional programing too.
I was thinking about having maybe a
getUserByIdand then agetUserByEmail, if you gonna DRY you can join both together in agetUserBySomethingso you avoid repeating most of the query, but then you will have a conditional inside your function that makes the function more complex and it also breaks the Single Responsibility principle and it's worse IMHO.Single Responsibility does not mean all functions must only do one thing.
For example if we need new behavior, we simply write a new method whose name indicates that single responsibility. It then allows for parameters to change behaviors. It can contain calls to many other functions but strictly only does what the name implies.
I call this a decorator pattern because it adds functionality by use of optional parameters. Allows parts to be added at will, but never departs from what the name implies. It only does that one thing.
The decorated function prefers use of reusable SRP functions because that code is already done and bullet proof. They are closed for modification.
The Concept is so simple but often confuses pepple.
Doing more than one thing in a function composed of SRP Functions is only more fragile if tests prove it.