How to go ahead with cases in which ONLY one derived class needs to
implement a method from a common interface?
If you end up in this situation then generally you have a problem with your design and should refactor.
For example in your calling code you call multiple methods on the class and make decisions based on the results of these methods. This is ...
In approach 1 you can apply a strategy pattern to support different kinds of mutation.
[Con's] More classes
This is not really a downside. Classes organize instance members. You probably have the same number of instance members in either approach. We should not seek to minimize classes at the expense of conflating concepts.
You need metadata
In order for a user to be able to add custom card types that may or may not have specific business rules or behavior, the user must be able to specify whether the behavior applies, and you need to be able to store it.
So you will need a metadata table, sort of like this:
CREATE TABLE CardTypes
C# supports reflection, so you can write a solution to take advantage using introspection. You would use XmlClass.Convert to convert foo (or any class).
In more general terms (and not specific to C#), if you are using a language that does not support reflection you should have foo do the conversion. This is because foo knows the details of what a foo is; ...
There's no real difference between a package-level global (version one for you) and a class variable. They're both implementations of a situation where the state is stored in a single place.
Typically you want to avoid this for many reasons, a few including:
It's difficult to track who is changing state in the case that these global values are visible to ...
To me, I'll create another value object called CrateCreation to model the creation of your crates and let showCrates accept the list of CrateCreation objects instead of the list of the actual Crate objects. The CrateCreation object holds these pieces of information:
The original input values.
The actual Crate object if the creation is success.
You are correct in asserting the Crate object should always be valid. This is a business class that should be enforcing its invariants — which it currently does. The problem lies with taking user input. You must allow user input to violate business rules and constraints. You will need at least 2 other classes:
A "view model" or "parameter" object that ...
You are trying to implement something like the DDD Repository Pattern. I suggest reading this article that talks about how to do this in C#.
In short, each entity in your program will have a Repository to worry about persistence operations like CRUD and more.
I have a third option for you: Genomes are data. I mean, have value semantics. However, let me go over your pros and cons first.
On Method one
This way we will have the option to derive from Mutation class later on to implement various kinds of mutations.
The idea that you are thinking about deriving from the Mutation class suggests to me that you want ...
Method 2 is the default design to have based on the most basic object-oriented principle that behavior should live where the data is. It is also the most maintainable, the simplest one.
So I would go with that, until Method 1 is absolutely needed. You are allowed to refactor things later. So go with the simplest design first and introduce indirections/...
First, let me quote the complete paragraph from P109 of the book:
" But you’d like a little more quality control...!
So you test marketed the SimpleFactory idea, and what you found was that the franchises were using your factory to create pizzas, but starting to employ their own home grown procedures for the rest of the process: they'd bake things a little ...