## Ex05 - Unavoidable redundancy at a certain point?

L4_
BASIC-Programmierer
Beiträge: 104
Registriert: 24. Apr 2012 15:44

### Ex05 - Unavoidable redundancy at a certain point?

Hello,

on the slides of SRP, slide 24, we have a concrete implementation of "BuildingsWithLightsAndShutters".

Lets assume I would implement "BuildingsWithLights", then the method "createRoom" would slightly differ but the method "createFloor" would be the same. So that would be redundant, right?

In the exercise, it looks like I have the same problem with the traits FullRankedCards and PiquetRankedCards.
Here we need to fix the Rank, that means we bound the Rank type so that I can define a method (lets call it "createRank") to build a Rank, just like in the slides.
But here I also have redundancy because for both traits the Rank is build in the same way.

Can we even avoid this redundancy or is it unavoidable in some points?

Kind regards

imaier
Mausschubser
Beiträge: 61
Registriert: 21. Okt 2013 21:27

### Re: Ex05 - Unavoidable redundancy at a certain point?

I am not sure I understand what you mean by redundancy here. Do you maybe mean code duplication or verbosity?

There is a certain amount of verbosity when using the cake pattern as in the home automation example, but you should not need to duplicate method implementations, for example. Sometimes you need to override and simply call the right super method, but I don't consider that duplicated code. You can avoid duplicated method implementations by building a proper trait hierarchy. In your example, BuildingsWithLights is an extension that Michael's design is not too suitable for since it first mixes Lights and Shutters together. Another way to design a trait hierarchy would be to let BuildingsWithLights and BuildingsWithShutters inherit from the appropriate base traits and then let BuildingsWithShuttersAndLight inherit from these two. Anyways, the example on the slides is a very simple version to demonstrate the point of the pattern. A real design would probably be a little bit more complicated but also more difficult to explain.

For your rank example, there really is no need to duplicate a rank creation method. You can define it in the right base trait, and then by simple mix-in composition reuse it everywhere you need it. It is one of the tasks of this exercise to realize that this is possible and how, but it shouldn't be all that difficult.

Thanks,
Ingo

L4_
BASIC-Programmierer
Beiträge: 104
Registriert: 24. Apr 2012 15:44

### Re: Ex05 - Unavoidable redundancy at a certain point?

Well, somehow it helps but I still have the following problem:
imaier hat geschrieben: You can define it in the right base trait, [...]
First, I intended to implement an inner class "Rank" in RankedCards so that any subtrait/class of RankedCards can construct Ranks.
So I thought that would be "the right base trait" to define it.
But then, the hint says "they might need to define additional abstract member types similar to Card above".

Makes sense, there can be other RankTypes.
So I reject the idea of Rank as an inner class and do subtyping in the same way like for Card.

But then at RankedCards, I cannot implement the method for creating a Rank, because the subtype is abstract.
And so for the traits FullRankedCards and PiquetRankedCards, I would have duplicate implementation for "createRank".
Thus, the only way I see is to create another trait which extends from RankedCards, where the type is fixed and the method for creating a Rank is implemented.
Now, am I doing this too complicated or would this be appropriate?

Kind regards

imaier
Mausschubser
Beiträge: 61
Registriert: 21. Okt 2013 21:27

### Re: Ex05 - Unavoidable redundancy at a certain point?

If it's only a constructor without much logic, that's totally fine.

On a related note, notice that the following is legal as I explained during the exercise session:

Code: Alles auswählen

trait A {
type T <: TT
trait TT
}

trait B extends A{
class T extends super.TT {
// my impl...
}
}

Once you make T concrete, you can directly do that with a class. No need to write

Code: Alles auswählen

trait B extends A{
type T = TT
class TT extends super.TT {
// my impl...
}
}

Not sure whether this will help you. As I said earlier, sometimes, the cake pattern is a bit verbose, but there is generally no need to duplicate real logic. I don't consider simple delegation or forwarding such as passing arguments to the right constructor as duplication of logic.