Design and Architecture

• "it's not flexible", not if you consider adding an extra case to be a Big Deal, but the alternative is adding an entire new class.
• Even if you are of the opinion that creating new classes is somehow easier than creating new cases, then spend a little time thinking about what would happen when the function signature of that virtual function is changed, or if something about the API used by the subclasses to implement themselves changes. This has the annoying property that the fix you're about to write is highly non-local, you'd have to "hunt down" all the places that need to change - in the best case they correspond to compile errors.
• If a requirement is broken into N cases, but the code is spread out non-locally over N classes, your code does not look like the requirement which makes it harder to check whether it matches.
• "it's not SOLID", maybe, but SOLID is subjective and overrated.
• "horrific", let's not even talk about it.
• The presented "better way" presupposes that we have a convenient instance of the "class that represents a particular reason". How did we get that? Chances are that there's a switch hiding in a factory pattern or something. Moving the problem. And if there is some pattern such as new AddressChanged().Update(), how about we don't wrap it in a class and just call a method that does that.
• Article forgets to point out that in the first place the only domain that was considered is the business logic domain. Even if it makes sense there (which I don't agree with either), it won't make sense anywhere else. There's no way Math.Min would have its if replaced by polymorphism.

swampwiz wrote:

This article purports

Member 14109043 wrote:

There will never have deprecated keywords.

public void SetTotalPrice(ShoppingCart s, Customer c, List<Product> lp)

codecs1 wrote:

the following method will calculate total price and update it to repository,

codecs1 wrote:

I think there is no reason to calculate the Customer one more time

Quote:

in which, many of properties of Object B b will be modified in DoSomething()

public class StudentCriteria
{
    public string Name { set; get; }
    public int? Age { set; get; }
    public DateTime? BeginRegisterDate { set; get; }
    public DateTime? EndRegisterDate { set; get; }

    public ValidationResult Validate ()
    {
        ValidationResult result = new ValidationResult();

        if (Age > 0)
                result.ErrorInfo.Add("Nope, too young.");

        // other checks, adding strings to ErrorInfo.

        return result;
    }
}
//Moveover, we should validate the input parameter StudentCriteria , so we call the following method in FindStudents(...)
//ValidationResult Validate(StudentCriteria sc);
//in which ValidationResult is an object representing the validation result, something like that:
public class ValidationResult
{
    public bool Success { get { return Convert.ToString(ErrorInfo).Length > 0; } }
    public List<String> ErrorInfo { set; get; }
}

codecs1 wrote:

All 'Error' information will be contained in ValidationResult and return to FindStudents

Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.

public static List<Student> FindStudents(StudentCriteria sc);