3

I have a service which is an API client.

It's goal is to instantiate a concrete client you tell it (different providers), implement it's methods (createRequest and doRequest) and forward their call to the concrete client, so, it is a proxy. But also, it needs to persist the response of clients to a database in a transparent way (so, developer does not have to worry about it when using the service).

This way, I'm mixing 2 patterns (proxy and factory for concrete clients) and also adding the persistence responsibility to the service.

My boss told me today that if I don't strictly follow the pattern, then I'm doing something else, but I can't say it is X pattern.

Is it true? Should I strictly follow patterns?

Maybe I could separate the instantiation of concrete clients in a factory that follows a factory pattern, but then it would be adding more files for something I should keep simple and stupid, so I'm afraid that doing a factory would be over-engineering.

public function setClient(string $clientName) {
    if (!isset($this->clients[$clientName])) {
        throw new InvalidClientException('some error');
    }
    $this->clientInstance = new $this->clients[$clientName]();
}
Improve this question
3
  • Who cares whether it is X pattern? There's a reason patterns are called patterns and not laws.
    – user253751
    Dec 15, 2016 at 2:35
  • I think the boss was just pointing to the fact that calling pattern to something that It's not, can lead to confusion. After all, patterns are more a tool for comunication (problem-solution) than code.
    – Laiv
    Dec 15, 2016 at 5:51
  • Reading the previous question I assume that your boss is telling you that your actual solution doesn't implement X pattern. Plus it does too many things (no separation of concerns) what lead instead to the implementation of anti-patterns.
    – Laiv
    Dec 15, 2016 at 7:32

1 Answer 1

Reset to default
8

What I think you should do is solve problems by writing code.

Over time, you will gather enough software development experience so that, when you are solving a problem by writing code, you will recognize when a particular pattern solves that specific problem, and you can implement it using the pattern, with full knowledge of the benefits, costs and tradeoffs involved.

All too often, software developers nowadays treat patterns as "building blocks," and try to assemble programs by stitching software patterns together like a quilt. If this is the way you write programs, then you're doing it wrong. Software patterns are not building blocks, nor do they comprehensively inform software designs. Rather, they are a finite collection of well-known solutions to certain well-known software problems. You use them when you recognize the pattern in the problem, but not before that.

To put it another way: if you have to ask "which hammer should I use to fix this roof," then you don't know enough yet to fix the roof.

Should I strictly follow patterns?

It depends. Does strictly following the pattern most effectively meet your specific requirements?

Note that your boss did not actually say "You must strictly follow the pattern." What he said was, "If you don't strictly follow the pattern, then you can't call it that."

Improve this answer
2
  • "If you don't strictly follow the pattern, then you can't call it that" And at that point patterns just died. The GoF patterns in particular are an abomination in the way they are implemented and no one should ever strictly follow those patterns. So either one can use patterns to describe abstract concepts, or patterns are worthless concepts. I flip flop between the two, but tend toward the latter.
    – David Arno
    Dec 15, 2016 at 6:56
  • Just wanted to add here. The biggest sin in software development is blindly following a pattern. Good software is usually a combination of different patterns all used to solve specific problem types. Before you go defining your own patterns you should get a better handle on the common ones used and understand what problems they are trying to solve. Also remember that when software is designed well the code rarely needs to be complex. The complexity often can be modeled in the design.
    – Adrian
    Dec 15, 2016 at 7:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.