Is this code a good solution for this task?

Question

interface IJuiceable
{
    void MakeJuice();
}
interface ISliceable
{
    void MakeSlices();
}

class Fruit:IJuiceable,ISliceable
{
    public string Name { get; set; }
    public void MakeJuice()=>Console.WriteLine($"Juice from {Name}");     

    public void MakeSlices()=>Console.WriteLine($"Slices of {Name}");         
}

class Fresh
{
    List<IJuiceable> juices = new List<IJuiceable>();
    List<ISliceable> slices = new List<ISliceable>();

    public void AddToJuices(IJuiceable fruit)=>juices.Add(fruit);       
    public void AddToSlices(ISliceable fruit)=> slices.Add(fruit);

    public void MakeFreshes()
    {
        juices.ForEach(x => x.MakeJuice());
        slices.ForEach(x => x.MakeSlices());           
    }
}

Answer 1

You have not implemented exception handling (the last requirement). Eg. if calling code passes null to AddToJuices or AddToSlices, it won't crash straight away, but as soon as you call MakeFreshes, it will result in an unhandled NullReferenceException once it gets to this null "fruit".

Also note that we don't know what calling code may pass in as an argument - could be some object that implements one of the interfaces, but actually explodes once our code calls its MakeJuice or MakeSlices... The requirement states that it's the responsibility of this code to handle exceptions, so if this was my homework, I'd prefer to be on the safe side here.

Less importantly, you implemented Name as a property of Fruit rather than a field (which is what the description asks for), although public fields actually are considered a bit of a code smell, and a backing field is automatically created for properties, so I would leave it. Aiming at good code style you could make it immutable though (as a readonly field, or a property with a private setter), and set it in the constructor - it stands to reason that name of a given fruit isn't subject to change. juices and slices could be readonly too, but that's nitpicking already.

Apart from the lack of exception handling, it seems okay to me. I like that you used some modern C# features to cut down on verbosity.

Answer 2

Implementation looks good except handling null in AddToJuices(...) and AddToSlices(...) methods.

As a side note to @Konrad Morawski's comment on

Also note that we don't know what calling code may pass in as an argument - could be some object that implements one of the interfaces, but actually explodes once our code calls its MakeJuice or MakeSlices...

Since the methods are expecting a specific type, callers won't be able to pass objects as they want.

Eg

internal class Apple : ISliceable
{
    public void MakeSlices() => Console.WriteLine($"Slices of Apple");

}

You won't be able to pass this implementation to AddToJuices(...)

@Konrad Morawski, correct me if I'm wrong.