kayintveen's avatar

Aproach for structuring classes that are fairly similar but not quite

I'm stuck procrastinating how to approach the following, and since its something i expect is not easy to refactor later i like anybodies advice on this. Currently i am creating a small app that connects to 3rd party services. They all use products to be send to these services so in general the functionality around each service will be the same but not really. So first of all each service has its own specifications.

Service A

  • ID
  • Name
  • Api Key
  • Api Secret

Service B

  • ID
  • Name
  • FTP User
  • FTP Password

So first question is i want to create a "services" model but its a little dumb i think to make db columns for api key, secret and ftp credentials. since there will be probably be 100 services in the end and while id and name are always applicable the fields can very. I'm thinking of storing this as metadata json inside a "credentials" json db column. But im not sure if thats the correct path. Also i need to somewhere specify the needed fields per service.

also connected to that there will be other functions connected to send the products. one will create a xml file the other a csv another will push to api or upload a file to the ftp. I'm a little afraid of making different models for these. Or making different classes for each. but i think its the way to go right?

0 likes
3 replies
ohffs's avatar

Without knowing more about the problem I'm wary of giving much advice. Have you tried stubbing out code - maybe as a test - and see what's common, what might be a nice way of interacting with the service/classes? It sounds like you kind of want to generalise your API to hide the details of the remote ones?

Might be worth looking through the Whip Monstrous Code Into Shape series. It sounds like maybe the 'Consider Strategizing' one might be helpful, from my memory of it anyway :-)

kayintveen's avatar

Thank for your response. What i now did is i made a connections folder where my entities are inside. These entities got public properties called "attributes" These attributes contain for example

public $attributes = [
        'api_key' => 'string',
        'api_secret' => 'string',
    ];

These generate string input fields in my create file. these files have a structures classname and filename. So i only have to create a new class with the same prefix but different name and im able to store new attributes for a different model entity.

These entities can then be expanded upon specific specification. but are thus very flexible. Not sure if this is a one of the dozen design best practices but feels lot more structured then made before.

shez1983's avatar

i am not sure what is service A, but B looks like a way to send data... now if you can explain a bit about various services then someone could help you better but trying to 'combine' different services e.g. facebook service with FTP service is a bad idea IMO..

Please or to participate in this conversation.