design_patterns | Illustrated Design Patterns

This became too long for a comment...

The patterns from the GoF book are older than Java. It was Java that later introduced the (silly) distinction between interface and abstract class. When the GoF refers to an interface, they simply mean an abstraction, and you can implement it using any language feature that enables abstraction.

That being said, the GoF Builder Pattern is overcomplicated. The pattern is useful even without polymorphism. And I think that is how it's most often implemented. If you're using Java, that would be Josh Bloch's Builder Pattern from Effective Java.

I don't mean to dismiss the LSP question, but if the real goal here is to learn to use a Builder effectively, then my advice is to ignore the (outdated) version from the GoF and look at a modern implementation where that question doesn't arise. If you really wanted to ask about the LSP, then I suggest a new question focused specifically on that topic, separate from the Builder Pattern.

To more directly address the questions in the OP,

1. The builder pattern can be implemented through abstract classes or through interfaces. It does not matter which. Modern implementations more often use neither.
2. LSP conformity will depend on how you implement (and document) the pattern. It would be possible to violate the LSP (or not) using interfaces or abstract classes. Eliminating both eliminates this question.

A move constructor would be appropriate:

Follow the logic of your code and it's apparent where the problem is.

When you declare, but do not initialize the singleton (var instance *singleton) then instance is nil. Calling GetInstance evaluates instance == nil as true and returns a new *singleton every time it is called. That is why counter2 will never equal expectedCounter - each call to GetInstance is returning a new counter instance.

When you initialize the singleton instance (var instance = &singleton{}) then calls to GetInstance will return that singleton instance since it is not nil.

I imagine you'd want to modify GetInstance to something like this:

I have finally found out an obvious solution by myself: redeclaring the private attribute of the parent class in the subclass:

You can't prevent subclasses from using the same names, no. You can protect names against accidental shadowing, however, by giving the name a double underscore prefix:

What you're doing makes no sense. Decorators are utility classes; they overlay programmatic functionality on to the classes they decorate. They are not something that can nor should be persisted to something like a database.

In other words, if your object is a Driver, then you need to keep it a Driver, not wrap it in an AmountBonus decorator and then attempt to persist that. Later, if you need whatever functionality the AmountBonus decorator adds again, you simply wrap your Driver instance in it again.

It doesn't even look like you're doing anything interesting with the decorator here, but if there is something that occurs just by the act of wrapping a Driver instance, then you'll need to fetch out somehow that wrapped Driver instance afterwards to actually save that and not your decorator.

I have made some modifications to your code :

By turning your private Worker worker { get; set; } into protected Worker worker { get; set; } classes outside cannot access it, but base classes can. This works even if the base class is abstract

Edit: This would also be a good time to learn about C# naming conventions ;) MSDN docs
Edit 2: As this comment points out, you probably want to use a private set with your Worker worker

Edit after question Edit: You still (only if you want) need the Worker in the Bonus class but you do not need to declare private Worker worker; again, as this (correctly pointed out by intellisense) hides the Bonus.worker worker. If the Bonus.Worker is set to protected, and not private, you can use it from your inherited classes without having to declare it again. This would be the result:

Create an instance of the subject under test and provide the necessary dependencies.