I have a class with a public method that takes a couple of parameters, like this:
The Process method needs to call different private methods to actually process the data. Is it better to pass all the parameters down the road or should I use a field to provide the information to the private methods?
// Variant 1: Parameters
public void Process(string param1, string param2, int param3)
{
processStep1(param1, param2, param3);
processStep2(param1, param2);
processStep3(param1, param2, param3);
}
// Variant 2: Fields
public void Process(string param1, string param2, int param3)
{
m_Param1 = param1;
m_Param2 = param2;
m_Param3 = param3;
processStep1();
processStep2();
processStep3();
}
In my eyes the variant 1 has the advantage of being free of side-effects (methods cannot change the value of a field). It mighthave advantages if it comes to unit testing because it's easier to test a specific function.
Variant 2 looks much more clear to me. You don't have to pass any parameters around and it's possible to change the contents of the fields if neccessary.
Is there a clear winner? Are both approaches valid and when to use which one?
From the description of your question I'd say Variant 1 is a clear winner, since, as you correctly identified, has more advantages than Variant 2. Side effects and testability are huge factors.
I'd add that Variant 2 is a form of a global state and unnecessary. Why would you want to have member variables used by a method which aren't needed in the object? What kind of object is it? Do you have other methods using these member variables?
Variant 1 has a clear interface for each step and you don't fall into the trap of accessing other state not really available from the parameters.
I'd only choose Variant 2 if the constructor initializes the member variables that are needed for the function process and is only used for this Process method.
Related
What would you call a stateful function/object x() -> bool with the following behavior: on the first call it returns TRUE, on all consecutive calls it returns FALSE. Maybe there is a pattern name already for such functionality?
The closest concept is the read-once object pattern from the Secure by Design book. Look at the paragraph below describing the object that allows to request the password only once.
A read-once object is, as the name implies, an object designed to be read once. This object
usually represents a value or concept in your domain that’s considered to be sensitive
(for example, passport numbers, credit card numbers, or passwords). The main purpose
of the read-once object is to facilitate detection of unintentional use of the data
it encapsulates.
public final class SensitiveValue {
private transient final AtomicReference<String> value;
public SensitiveValue(final String value) {
validate(value);
this.value = new AtomicReference<>(value);
}
public String value() {
return notNull(value.getAndSet(null),
"Sensitive value has already been consumed");
}
#Override
public String toString() {
return "SensitiveValue{value=*****}";
}
}
I don't know the full context of your problem but the book suggests to use the read-once object pattern in favor of security perspective. #jaco0646 also pointed out in the comments that the concept is similar to the circuit breaker pattern. Though it doesn't force for the object to always return the same value on consecutive calls. Instead, it temporary makes to obtain the stub value to give the external service some time to recover.
I'm honestly not sure what this is called, and if I did I'm sure I could google it in about 5 seconds.
I want to be able to write a class that I can sort of "index into" the way you do with a collection, eg:
Public Class FooClass
Public Function magicKeyword(param as String) as String
If param = "foo" Then
Return "bar"
Else
Return "baz"
End If
End Function
...
End Class
And then use it like this:
Dim myObj as New FooClass
Dim output as String = myObj("foo") '<-- this is what I want to know how to do
' output = "bar"
What is this called, and what syntax would I use for the function?
Out of curiosity, can this also be done as a Shared function so the class itself can do it? e.g.:
Dim output as String = FooClass("foo")
What you are describing is implementing a custom collection, and Microsoft provides a pretty good guide on how to accomplish this.
It should be said, however, that the collection classes already provided in .NET should be able to handle most use cases. A truly custom collection is overkill in many instances.
I'm looking at a well-known problem and therefore there has to be a design pattern or a mix of patterns to solve it.
With the following classes and properties:
CTask
Name
Duration
TaskArea
CTaskArea
Name
CPerson
Name
Abilities
CAbility
Name
CTool
Name
CleaningTime
CConstraint
Name
Constraint
CTask, CPerson, CTool could have constraints e.g. Task A could only be done by persons with ability X, or person A could not do tasks of TaskArea X and so on.
For example, when I create a new CTask, CPerson or CTool I could imagine a constraint config dialog with dropdowns like:
Class | Operator | Class | Property | Value
CPerson | NOT | CTool | Name | Hammer
What design pattern provides the opportunity to dynamically configure constraints for all the classes, without forcing the classes to know additional information or take additional dependencies on each other?
Can I use an interface for objects to express that they accept constraints being applied somehow, or to discover classes which should be configurable with constraints?
Why not to have contraints_for_xxx property at each object having a constraint for particular xxx property?
When some child property is to be added into a collection, it is first run through constraints collection. If any constraint item returns false... exception is thrown, heaven thunders etc.
Constraints can be filled in object's constructor or later via some setupConstraints() call.
CPerson can look like (PHP example):
class Person
{
protected $constraintsAbc = null;
public function setConstraintsAbc(array $constraints)
{
$this->constraintsAbc = $constraints;
}
public function setABC($value)
{
foreach ($this->constraintsAbc as $constraint) {
if (!$constraint->isValid($value)) {
throw new Exception("Constraint {$constraint->getName()} is not happy with value $value");
}
}
$this->abc = $value;
}
}
class PersonSetup
{
public function setupPerson(Person $person)
{
$constrains[] = new PersonAbcConstraint("Value > 5");
$person->setContraintsABC($constrains);
}
}
This is, of course, fictious example. There is a problem here in some code duplication since you have constraintsAbc, setConstraintsAbc and setAbc as different hard-coded fields. But you can abstract this into some virtual "constraintable" field collection if you like.
this is the solution im ok with:
class CCouldHaveConstraints_Base
{
public virtual GetInstance();
public virtual GetClassName();
public virtual GetPropertyListThatCouldHaveConstraints();
}
class CPerson : CCouldHaveConstraints_Base
{
private String m_PersonName;
private String m_PersonAge;
public String PersonName
{
get {return this.m_PersonName;}
set {this.m_PersonName=value;}
}
public String PersonAge
{
get {return this.m_PersonAge;}
set {this.m_PersonAge=value;}
}
public override GetInstance()
{
return new CPerson;
}
public override GetClassName
{
return "Person";
}
public list<string> GetPropertyListThatCouldHaveConstraints()
{
list <string> ConstraintPropsList = new list<string>;
ConstraintPropsList.Add ("PersonName")
}
}
// class contains a list of all objects that could have constraints
class CConstraint_Lst
{
private list<CConstraint> m_ListOfConstraints;
private list<CCouldHaveConstraints_Base> m_ListOfObjectsThatCouldHaveConstraints;
}
// e.g Person | Person.Name | Tim | NOT | Tool | Tool.Name | "Hammer"
class CConstraint
{
private String m_ClassName_A;
private String m_ClassProperty_A;
private String m_ClassProperty_A_Value;
private String m_Operator;
private String m_ClassName_B;
private String m_ClassProperty_B;
private String m_ClassProperty_B_Value;
}
Is that enough code to figure out how im thinking?
Regards,
Tim
You've already made a great conceptual leap to model the constraints as CConstraint objects. The remaining core of the question seems to be "How do I then organize the execution of the constraints, provide them with the right inputs, and collect their outputs? (the outputs are constraint violations, validation errors, or warnings)"
CConstraints obviously can't be evaluated without any input, but you have some choices on how exactly to provide them with input, which we can explore with questions:
Do they get given a 'global state' which they can explore and look for violations in?
Or do they get given a tuple of objects, or object graph, which they return a success or failure result for?
How do they signal constraint violations? Is it by throwing exceptions, returning results, adding them to a collection of violations, or removing violating objects from the world, or triggering repair rules?
Do they provide an "explanation" output that helpfully explains which object or combination of objects is the offending combination, and what rule it violates?
Compilers might be an interesting place to look for inspiration. We know a good compiler processes some complicated input, and produces one or more easy-to-understand error messages allowing the programmer to fix any problem in their program.
Compilers often have to choose some pattern of organizing the work that they're doing like recursion (recursive descent), or a visitor pattern (visit a tree of objects in some arrangement), or stateful pattern matching on a stream of input approach (syntax token recognition by regex matching, or processing a stream of characters), or a chain-of-responsibility (one processor validates and processes input, passes it to the next processor in the chain). Which is actually a whole family of design patterns you can choose from.
Probably one of the most flexible patterns to look at which is useful for your case is the visitor pattern, because you can extend your domain model with additional classes, all of which know how to do a 'visiting' phase, which is basically what 'validation' often entails - someone visits all the objects in a scenario, and inspects their properties, with an easily extensible set of logics (the validation rules) specific to those types of objects, without needing to worry about the mechanics of the visiting procedure (how you traverse the object graph) in each validation rule.
So I have a service method that modifies a model object
public function doSomething() {
$model = new Model();
// Modify the model with a bunch of private methods
return $model;
}
If I want to test doSomething, I really only have $model to work with. And the only way I can write assertions on $model is to use its public interfaces.
$this->assertEquals($model->getName(), 'name');
What confuses me here is what exactly am I testing with that assertion? Am I testing that getName works properly or am I testing doSomething works properly?
In order for me to test doSomething, I have to assume that getName works. So how do I make sure that is the case?
Based on your code, I would test that I got an instance of Model returned. And then using the public accessors or assertAttributeEquals to check that the properties of the object were correct. This does test the getters of the model, however the object having certain properties is what you are expecting to happen.
Though as your class is both creating the object and modifying it. I would change the method to take a Model as an argument. This way in my test I can create a mockModel and make sure that any public setters are called with the proper arguments. Doing this, I don't have to worry about any of the logic that Model has for properties that get set.
For Example:
Test Function:
public function testDoSomething() {
$mockModel = $this->getMock('Model');
$mockModel->expects($this->once())
->method('foo')
->with('some argument');
$mockModel->expects($this->once())
->method('bar')
->with('some other argument');
$sut = new SUT();
$sut->doSomething($mockModel);
}
Your function doSomething only needs to become this:
public function doSomething(Model $model) {
/** Do stuff with private methods **/
}
Now you are able to make sure that properties of Model are set with the proper values and not depending on the logic that may or may not exist in the class. You are also helping to specify the contract that Model needs to fill. Any new methods that you are depending on will come out in your integration / system tests.
Your contract with doSomething() is, that it has to return an object of type "Model". Your contract is not getName() working on a returned object. As result, test $model to be of correct type:
$this->assertInstanceOf('Model', $model);
Documentation: PHPUnit -> assertInstanceOf()
As a hint, "[i]deally, each test case is independent from the others" 2014-10-21 wikipedia.org/wiki/Unit_testing.
So, in your test_doSomethingTest*(), you are supposed to test only what happens within that function. Check for return type, and whatever happens withing that function. Testing getName() should be in it's own test_getName*().
Can a class return an object of itself.
In my example I have a class called "Change" which represents a change to the system, and I am wondering if it is in anyway against design principles to return an object of type Change or an ArrayList which is populated with all the recent Change objects.
Yes, a class can have a method that returns an instance of itself. This is quite a common scenario.
In C#, an example might be:
public class Change
{
public int ChangeID { get; set; }
private Change(int changeId)
{
ChangeID = changeId;
LoadFromDatabase();
}
private void LoadFromDatabase()
{
// TODO Perform Database load here.
}
public static Change GetChange(int changeId)
{
return new Change(changeId);
}
}
Yes it can. In fact, that's exactly what a singleton class does. The first time you call its class-level getInstance() method, it constructs an instance of itself and returns that. Then subsequent calls to getInstance() return the already-constructed instance.
Your particular case could use a similar method but you need some way of deciding the list of recent changes. As such it will need to maintain its own list of such changes. You could do this with a static array or list of the changes. Just be certain that the underlying information in the list doesn't disappear - this could happen in C++ (for example) if you maintained pointers to the objects and those objects were freed by your clients.
Less of an issue in an automatic garbage collection environment like Java since the object wouldn't disappear whilst there was still a reference to it.
However, you don't have to use this method. My preference with what you describe would be to have two clases, changelist and change. When you create an instance of the change class, pass a changelist object (null if you don't want it associated with a changelist) with the constructor and add the change to that list before returning it.
Alternatively, have a changelist method which creates a change itself and returns it, remembering the change for its own purposes.
Then you can query the changelist to get recent changes (however you define recent). That would be more flexible since it allows multiple lists.
You could even go overboard and allow a change to be associated with multiple changelists if so desired.
Another reason to return this is so that you can do function chaining:
class foo
{
private int x;
public foo()
{
this.x = 0;
}
public foo Add(int a)
{
this.x += a;
return this;
}
public foo Subtract(int a)
{
this.x -= a;
return this;
}
public int Value
{
get { return this.x; }
}
public static void Main()
{
foo f = new foo();
f.Add(10).Add(20).Subtract(1);
System.Console.WriteLine(f.Value);
}
}
$ ./foo.exe
29
There's a time and a place to do function chaining, and it's not "anytime and everywhere." But, LINQ is a good example of a place that hugely benefits from function chaining.
A class will often return an instance of itself from what is sometimes called a "factory" method. In Java or C++ (etc) this would usually be a public static method, e.g. you would call it directly on the class rather than on an instance of a class.
In your case, in Java, it might look something like this:
List<Change> changes = Change.getRecentChanges();
This assumes that the Change class itself knows how to track changes itself, rather than that job being the responsibility of some other object in the system.
A class can also return an instance of itself in the singleton pattern, where you want to ensure that only one instance of a class exists in the world:
Foo foo = Foo.getInstance();
The fluent interface methods work on the principal of returning an instance of itself, e.g.
StringBuilder sb = new StringBuilder("123");
sb.Append("456").Append("789");
You need to think about what you're trying to model. In your case, I would have a ChangeList class that contains one or more Change objects.
On the other hand, if you were modeling a hierarchical structure where a class can reference other instances of the class, then what you're doing makes sense. E.g. a tree node, which can contain other tree nodes.
Another common scenario is having the class implement a static method which returns an instance of it. That should be used when creating a new instance of the class.
I don't know of any design rule that says that's bad. So if in your model a single change can be composed of multiple changes go for it.