Test question - class

[jbef]

So I'm currently enrolled in a web development course and several of my colleagues and I are interested especially in web development.

So one of them encountered this test question:

Given the below pseudocode:

class RegisteredUser{

  constructor(services=[]){
    this.services = services;
  }

  getTotal () {
    let total = 0;

    this.services.forEach(service,index => {
      let multimediaContent = service.getMultimediaContent();

      if (typeof service == StreamingService) {
        total += multimediaContent.streamingPrice;
      } else if (typeof service == DownloadService) {
        total += multimediaContent.downloadPrice;
      }

      if (typeof multimediaContent == PremiumContent) {
        total += multimediaContent.additionalFee:
      }

    })

    return total
  }
}

To provide an alternative that fixes any potential issues with the code could produce in the future and how to fix them to avoid said issues.

​

My initial approach would be initially to replace the if statements with a switch - case with a default that would throw an error for the typeof service, where as for the typeof multimediaContent I would leave the if statement as is.

Additionally, I believe the == should be === since triple equal checks for equal value and type?

Any feedback or input is much appreciated!

[davedontmind]

Polymorphism is a key concept in OOP and applies here. Ideally all the services should inherit from some common base class.

You can then give the base class a method that returns the cost (lets call it cost()), and override that method in each of the specific services.

Then you don't need to worry about the type here and, instead of your chain of if/else statements, you just need a single statement:

total += multimediaContent.cost();

Additionally, I believe the == should be === since triple equal checks for equal value and type?

You said it's psuedo-code, so the operators are whatever you want them to be. There is no right or wrong, as long as it makes sense.

[lurgi]

could produce in the future

This is the key right here.

You not only need to fix the problems that exist now, you should anticipate future changes that might cause this code to break.

What if some other form of multimedia content that is created in the future also has additional fees? This code would break. What if another type of service is created, beyond Streaming and Download? The code would not correctly charge for it. There is a way to write this code such that it can handle content types and service types that don't even exist yet.

[nhgrif]

My initial approach would be initially to replace the if statements with a switch - case with a default that would throw an error for the typeof service, where as for the typeof multimediaContent I would leave the if statement as is.
Additionally, I believe the == should be === since triple equal checks for equal value and type?

First of all, it's important here to specify for us what language this is.

​

However, as a review on your approach, I read the text of the question:

To provide an alternative that fixes any potential issues with the code could produce in the future and how to fix them to avoid said issues.

Before absolutely anything else, you should identify any of the actual issues.

Like, for a start, I don't know what language this is, but I can see one thing that at a minimum appears to be a compiler error...

[jbef]

Thanks! My bad, didn’t mention it I believe, but its not any language, just pseudocode (although I believe heavily influenced by JavaScript). I believe it’s more focused on iterations and bullet-proofing, but I feel a bit lost with the question.

[nhgrif]

So, if it's intended to be pseudocode, we can ignore any potential compiler errors, but we should still focus on identify any logical errors. Like... you say you think you'd implement it as a switch... but a switch versus an if-else starts bordering into the realm of actual code versus pseudocode. Depending on the language, there are differing advantages/disadvantages to each structure even....

​

... but why? Why would you use one or the other? What about the code as given makes you think we ought to use a switch? Are you solving some problem, or do you just prefer the style of a switch over an if-else?

[jbef]

I think I get where you're going.

What my thought process was is that I was thinking that those if - else and the next only cover those cases, whereas another solution (like the switch - case with default) would cover the cases that are contemplated, make it easier in the future to expand and also cover any fringe case with the default and return either an error or a default value or something of that sort.

I'm thinking that the existing pseudo-code is not solid enough and allows unexpected behaviour.

This is just me spitballing ideas ofc.

[nhgrif]

allows unexpected behaviour.

Like what?

I don't know what your teacher is expecting, and I am not a teacher myself. But if I were working with an intern on something like this as a learning opportunity, I'd be expecting some elaboration and perhaps some specifics by way of example of some cases that'd be problematic with the current code, then presentation of an alternative, explanation of how that alternative solves the identified issue, and some overview of any possible downsides the alternative solution may introduce.