So machen Sie „private“ Felder einer Service-Klasse zugänglich und halten dabei das Prinzip der Einzelverantwortung ein ⇐ C#

[Anonymous]

Dies ist möglicherweise ein XY-Problem, aber nach meinem Verständnis des SRP (Single Responsibility Principle) sollten die Eigenschaften bei einem Order-Objekt in der Order vorhanden sein, Methoden wie SaveOrder() oder ValidateOrder() jedoch in einer OrderService-Klasse, in der die Order als Parameter an die SaveOrder(IOrder)-Methode übergeben wird.
Die Idee dahinter ist, dass die Order nur die für eine Order erforderlichen Informationen enthält (orderID, Preis usw.) und ist von der Logik zur Speicherung getrennt, die in der Verantwortung des Dienstes liegt. (Es kann sein, dass ein IOrderService beispielsweise in SQL und ein anderer in einer Textdatei speichert. In diesem Fall wird dieses Muster auch für das Open/Closed-Prinzip benötigt.)
Wenn wir eine Bestellung jedoch nur einmal pro Lebensdauer der Instanz speichern (oder validieren könnten, wäre dies in diesem Zusammenhang sinnvoller), dann scheint es, als ob wir ein isValidated-Flag benötigen, um auf der Order zu leben, damit wir order.IsValidated lesen können, um zu sehen, ob wir sie speichern müssen oder nicht.
Eine Beispielimplementierung, wie dies meiner Meinung nach erfolgen sollte, finden Sie unten:

Code: Select all

public interface IOrder
{
int OrderID { get; }
int NumberOfPieces { get; }

bool IsValidated { get; }
}

public interface IValidate
{
void SetValidated();
}

public class Order : IOrder, IValidate
{
public int OrderID { get; private set; }

public int NumberOfPieces { get; private set; }

private bool _isValidated = false;
public bool IsValidated
{
get { return _isValidated; }
private set { _isValidated = value; }
}
public void SetValidated()
{
_isValidated = true;
}
}

public interface IOrderService
{
void Validate(IOrder order);
}

public class OrderService : IOrderService
{
public void Validate(IOrder order)
{
if (order is IValidate v)
{
DoValidateWork(order);
v.SetValidated();
}
}

private bool DoValidateWork(IOrder order)
{
//validation logic
return true;
}
}

Das Problem dabei ist meiner Meinung nach, dass die SetValidated()-Methode technisch gesehen von überall in der Anwendung aufgerufen werden kann, indem die Bestellung in IValidated umgewandelt wird, und es anderen Entwicklern in derselben Codebasis ermöglicht, das isValidated-Flag einfach auf true zu setzen und dabei die OrderService-Implementierung zu umgehen.
Gibt es eine Standardmethode zum Kapseln des isValidated-Flags, sodass nur OrderService es aktualisieren kann?
Nach dem, was ich gelesen habe, ist das Verschachteln von Klassen eine schlechte Praxis, und wenn ich die KI frage, sagt sie mir, ich solle Order/OrderService in eine eigene Assembly einfügen und als intern markieren, was absolut lächerlich wirkt.
Wenn jemand irgendwelche Tipps oder Einblicke in bessere Muster hat (oder Gründe, warum die Umwandlung als IValidated eine gute Lösung ist, um meine Bedenken darüber zu zerstreuen), bin ich dankbar für die Gedanken.
Vielen Dank an alle fürs Lesen.