Following issue: In a client/server environment with Spring-Boot and Kotlin the client wants to create objects of type A and therefore posts the data through a RESTful endpoint to the server.
Entity A is realized as a data class in Kotlin like this:
data class A(val mandatoryProperty: String)
Business-wise that property (which is a primary key, too) must never be null. However, it is not known by the client, as it gets generated quite expensively by a Spring #Service Bean on the server.
Now, at the endpoint Spring tries to deserialize the client's payload into an object of type A, however, the mandatoryProperty is unknown at that point in time, which would result in a mapping exception.
Several ways to circumvent that problem, none of which really amazes me.
Don't expect an object of type A at the endpoint, but get a bunch of parameters describing A that are passed on until the entity has actually been created and mandatoryProperty is present . Quite cumbersome actually, since there are a lot more properties than just that single one.
Quite similar to 1, but create a DTO. One of my favorites, however, since data classes can't be extended it would mean to duplicate the properties of type A into the DTO (except for the mandatory property) and copy them over. Furthemore, when A grows, the DTO has to grow, too.
Make mandatoryProperty nullable and work with !! operator throughout the code. Probably the worst solution as it foils the sense of nullable and non-nullable variables.
The client would set a dummy value for the mandatoryProperty which is replaced as soon as the property has been generated. However, A is validated by the endpoint and therefore the dummy value must obey its #Pattern constraint. So each dummy value would be a valid primary key, which gives me a bad feeling.
Any other ways I might have overseen that are more feasible?
I don't think there is a general-purpose answer to this... So I will just give you my 2 cents regarding your variants...
Your first variant has a benefit which no other really has, i.e. that you will not use the given objects for anything else then they were designed to be (i.e. endpoint or backend purposes only), which however probably will lead to cumbersome development.
The second variant is nice, but could lead to some other development errors, e.g. when you thought you used the actual A but you were rather operating on the DTO instead.
Variant 3 and 4 are in that regard similar to 2... You may use it as A even though it has all the properties of a DTO only.
So... if you want to go the safe route, i.e. no one should ever use this object for anything else then its specific purpose you should probably use the first variant. 4 sounds rather like a hack. 2 & 3 are probably ok. 3 because you actually have no mandatoryProperty when you use it as DTO...
Still, as you have your favorite (2) and I have one too, I will concentrate on 2 & 3, starting with 2 using a subclass approach with a sealed class as supertype:
sealed class AbstractA {
// just some properties for demo purposes
lateinit var sharedResettable: String
abstract val sharedReadonly: String
}
data class A(
val mandatoryProperty: Long = 0,
override val sharedReadonly: String
// we deliberately do not override the sharedResettable here... also for demo purposes only
) : AbstractA()
data class ADTO(
// this has no mandatoryProperty
override val sharedReadonly: String
) : AbstractA()
Some demo code, demonstrating the usage:
// just some random setup:
val a = A(123, "from backend").apply { sharedResettable = "i am from backend" }
val dto = ADTO("from dto").apply { sharedResettable = "i am dto" }
listOf(a, dto).forEach { anA ->
// somewhere receiving an A... we do not know what it is exactly... it's just an AbstractA
val param: AbstractA = anA
println("Starting with: $param sharedResettable=${param.sharedResettable}")
// set something on it... we do not mind yet, what it is exactly...
param.sharedResettable = UUID.randomUUID().toString()
// now we want to store it... but wait... did we have an A here? or a newly created DTO?
// lets check: (demo purpose again)
when (param) {
is ADTO -> store(param) // which now returns an A
is A -> update(param) // maybe updated also our A so a current A is returned
}.also { certainlyA ->
println("After saving/updating: $certainlyA sharedResettable=${certainlyA.sharedResettable /* this was deliberately not part of the data class toString() */}")
}
}
// assume the following signature for store & update:
fun <T> update(param : T) : T
fun store(a : AbstractA) : A
Sample output:
Starting with: A(mandatoryProperty=123, sharedReadonly=from backend) sharedResettable=i am from backend
After saving/updating: A(mandatoryProperty=123, sharedReadonly=from backend) sharedResettable=ef7a3dc0-a4ac-47f0-8a73-0ca0ef5069fa
Starting with: ADTO(sharedReadonly=from dto) sharedResettable=i am dto
After saving/updating: A(mandatoryProperty=127, sharedReadonly=from dto) sharedResettable=57b8b3a7-fe03-4b16-9ec7-742f292b5786
I did not yet show you the ugly part, but you already mentioned it yourself... How do you transform your ADTO to A and viceversa? I will leave that up to you. There are several approaches here (manually, using reflection or mapping utilities, etc.).
This variant cleanly seperates all the DTO specific from the non-DTO-specific properties. However it will also lead to redundant code (all the override, etc.). But at least you know on which object type you operate and can setup signatures accordingly.
Something like 3 is probably easier to setup and to maintain (regarding the data class itself ;-)) and if you set the boundaries correctly it may even be clear, when there is a null in there and when not... So showing that example too. Starting with a rather annoying variant first (annoying in the sense that it throws an exception when you try accessing the variable if it wasn't set yet), but at least you spare the !! or null-checks here:
data class B(
val sharedOnly : String,
var sharedResettable : String
) {
// why nullable? Let it hurt ;-)
lateinit var mandatoryProperty: ID // ok... Long is not usable with lateinit... that's why there is this ID instead
}
data class ID(val id : Long)
Demo:
val b = B("backend", "resettable")
// println(newB.mandatoryProperty) // uh oh... this hurts now... UninitializedPropertyAccessException on the way
val newB = store(b)
println(newB.mandatoryProperty) // that's now fine...
But: even though accessing mandatoryProperty will throw an Exception it is not visible in the toString nor does it look nice if you need to check whether it already has been initialized (i.e. by using ::mandatoryProperty::isInitialized).
So I show you another variant (meanwhile my favorite, but... uses null):
data class C(val mandatoryProperty: Long?,
val sharedOnly : String,
var sharedResettable : String) {
// this is our DTO constructor:
constructor(sharedOnly: String, sharedResettable: String) : this(null, sharedOnly, sharedResettable)
fun hasID() = mandatoryProperty != null // or isDTO, etc. what you like/need
}
// note: you could extract the val and the method also in its own interface... then you would use an override on the mandatoryProperty above instead
// here is what such an interface may look like:
interface HasID {
val mandatoryProperty: Long?
fun hasID() = mandatoryProperty != null // or isDTO, etc. what you like/need
}
Usage:
val c = C("dto", "resettable") // C(mandatoryProperty=null, sharedOnly=dto, sharedResettable=resettable)
when {
c.hasID() -> update(c)
else -> store(c)
}.also {newC ->
// from now on you should know that you are actually dealing with an object that has everything in place...
println("$newC") // prints: C(mandatoryProperty=123, sharedOnly=dto, sharedResettable=resettable)
}
The last one has the benefit, that you can use the copy-method again, e.g.:
val myNewObj = c.copy(mandatoryProperty = 123) // well, you probably don't do that yourself...
// but the following might rather be a valid case:
val myNewDTO = c.copy(mandatoryProperty = null)
The last one is my favorite as it needs the fewest code and uses a val instead (so also no accidental override is possible or you operate on a copy instead). You could also just add an accessor for the mandatoryProperty if you do not like using ? or !!, e.g.
fun getMandatoryProperty() = mandatoryProperty ?: throw Exception("You didn't set it!")
Finally if you have some helper methods like hasID(isDTO or whatever) in place it might also be clear from the context what you are exactly doing. The most important is probably to setup a convention that everyone understands, so they know when to apply what or when to expect something specific.
Occasionally I come across methods with an uncomfortable number of parameters. More often than not, they seem to be constructors. It seems like there ought to be a better way, but I can't see what it is.
return new Shniz(foo, bar, baz, quux, fred, wilma, barney, dino, donkey)
I've thought of using structs to represent the list of parameters, but that just seems to shift the problem from one place to another, and create another type in the process.
ShnizArgs args = new ShnizArgs(foo, bar, baz, quux, fred, wilma, barney, dino, donkey)
return new Shniz(args);
So that doesn't seem like an improvement. So what is the best approach?
I'm going to assume you mean C#. Some of these things apply to other languages, too.
You have several options:
switch from constructor to property setters. This can make code more readable, because it's obvious to the reader which value corresponds to which parameters. Object Initializer syntax makes this look nice. It's also simple to implement, since you can just use auto-generated properties and skip writing the constructors.
class C
{
public string S { get; set; }
public int I { get; set; }
}
new C { S = "hi", I = 3 };
However, you lose immutability, and you lose the ability to ensure that the required values are set before using the object at compile time.
Builder Pattern.
Think about the relationship between string and StringBuilder. You can get this for your own classes. I like to implement it as a nested class, so class C has related class C.Builder. I also like a fluent interface on the builder. Done right, you can get syntax like this:
C c = new C.Builder()
.SetX(4) // SetX is the fluent equivalent to a property setter
.SetY("hello")
.ToC(); // ToC is the builder pattern analog to ToString()
// Modify without breaking immutability
c = c.ToBuilder().SetX(2).ToC();
// Still useful to have a traditional ctor:
c = new C(1, "...");
// And object initializer syntax is still available:
c = new C.Builder { X = 4, Y = "boing" }.ToC();
I have a PowerShell script that lets me generate the builder code to do all this, where the input looks like:
class C {
field I X
field string Y
}
So I can generate at compile time. partial classes let me extend both the main class and the builder without modifying the generated code.
"Introduce Parameter Object" refactoring. See the Refactoring Catalog. The idea is that you take some of the parameters you're passing and put them in to a new type, and then pass an instance of that type instead. If you do this without thinking, you will end up back where you started:
new C(a, b, c, d);
becomes
new C(new D(a, b, c, d));
However, this approach has the greatest potential to make a positive impact on your code. So, continue by following these steps:
Look for subsets of parameters that make sense together. Just mindlessly grouping all parameters of a function together doesn't get you much; the goal is to have groupings that make sense. You'll know you got it right when the name of the new type is obvious.
Look for other places where these values are used together, and use the new type there, too. Chances are, when you've found a good new type for a set of values that you already use all over the place, that new type will make sense in all those places, too.
Look for functionality that is in the existing code, but belongs on the new type.
For example, maybe you see some code that looks like:
bool SpeedIsAcceptable(int minSpeed, int maxSpeed, int currentSpeed)
{
return currentSpeed >= minSpeed & currentSpeed < maxSpeed;
}
You could take the minSpeed and maxSpeed parameters and put them in a new type:
class SpeedRange
{
public int Min;
public int Max;
}
bool SpeedIsAcceptable(SpeedRange sr, int currentSpeed)
{
return currentSpeed >= sr.Min & currentSpeed < sr.Max;
}
This is better, but to really take advantage of the new type, move the comparisons into the new type:
class SpeedRange
{
public int Min;
public int Max;
bool Contains(int speed)
{
return speed >= min & speed < Max;
}
}
bool SpeedIsAcceptable(SpeedRange sr, int currentSpeed)
{
return sr.Contains(currentSpeed);
}
And now we're getting somewhere: the implementation of SpeedIsAcceptable() now says what you mean, and you have a useful, reusable class. (The next obvious step is to make SpeedRange in to Range<Speed>.)
As you can see, Introduce Parameter Object was a good start, but its real value was that it helped us discover a useful type that has been missing from our model.
The best way would be to find ways to group the arguments together. This assumes, and really only works if, you would end up with multiple "groupings" of arguments.
For instance, if you are passing the specification for a rectangle, you can pass x, y, width, and height or you could just pass a rectangle object that contains x, y, width, and height.
Look for things like this when refactoring to clean it up somewhat. If the arguments really can't be combined, start looking at whether you have a violation of the Single Responsibility Principle.
If it's a constructor, particularly if there are multiple overloaded variants, you should look at the Builder pattern:
Foo foo = new Foo()
.configBar(anything)
.configBaz(something, somethingElse)
// and so on
If it's a normal method, you should think about the relationships between the values being passed, and perhaps create a Transfer Object.
The classic answer to this is to use a class to encapsulate some, or all, of the parameters. In theory that sounds great, but I'm the kind of guy who creates classes for concepts that have meaning in the domain, so it's not always easy to apply this advice.
E.g. instead of:
driver.connect(host, user, pass)
You could use
config = new Configuration()
config.setHost(host)
config.setUser(user)
config.setPass(pass)
driver.connect(config)
YMMV
When I see long parameter lists, my first question is whether this function or object is doing too much. Consider:
EverythingInTheWorld earth=new EverythingInTheWorld(firstCustomerId,
lastCustomerId,
orderNumber, productCode, lastFileUpdateDate,
employeeOfTheMonthWinnerForLastMarch,
yearMyHometownWasIncorporated, greatGrandmothersBloodType,
planetName, planetSize, percentWater, ... etc ...);
Of course this example is deliberately ridiculous, but I've seen plenty of real programs with examples only slightly less ridiculous, where one class is used to hold many barely related or unrelated things, apparently just because the same calling program needs both or because the programmer happened to think of both at the same time. Sometimes the easy solution is to just break the class into multiple pieces each of which does its own thing.
Just slightly more complicated is when a class really does need to deal with multiple logical things, like both a customer order and general information about the customer. In these cases, crate a class for customer and a class for order, and let them talk to each other as necessary. So instead of:
Order order=new Order(customerName, customerAddress, customerCity,
customerState, customerZip,
orderNumber, orderType, orderDate, deliveryDate);
We could have:
Customer customer=new Customer(customerName, customerAddress,
customerCity, customerState, customerZip);
Order order=new Order(customer, orderNumber, orderType, orderDate, deliveryDate);
While of course I prefer functions that take just 1 or 2 or 3 parameters, sometimes we have to accept that, realistically, this function takes a bunch, and that the number of itself does not really create complexity. For example:
Employee employee=new Employee(employeeId, firstName, lastName,
socialSecurityNumber,
address, city, state, zip);
Yeah, it's a bunch of fields, but probably all we're going to do with them is save them to a database record or throw them on a screen or some such. There's not really a lot of processing here.
When my parameter lists do get long, I much prefer if I can give the fields different data types. Like when I see a function like:
void updateCustomer(String type, String status,
int lastOrderNumber, int pastDue, int deliveryCode, int birthYear,
int addressCode,
boolean newCustomer, boolean taxExempt, boolean creditWatch,
boolean foo, boolean bar);
And then I see it called with:
updateCustomer("A", "M", 42, 3, 1492, 1969, -7, true, false, false, true, false);
I get concerned. Looking at the call, it's not at all clear what all these cryptic numbers, codes, and flags mean. This is just asking for errors. A programmer might easily get confused about the order of the parameters and accidentally switch two, and if they're the same data type, the compiler would just accept it. I'd much rather have a signature where all these things are enums, so a call passes in things like Type.ACTIVE instead of "A" and CreditWatch.NO instead of "false", etc.
This is quoted from Fowler and Beck book: "Refactoring"
Long Parameter List
In our early programming days we were taught to pass in as parameters everything needed by
a routine. This was understandable because the alternative was global data, and global data is
evil and usually painful. Objects change this situation because if you don't have something
you need, you can always ask another object to get it for you. Thus with objects you don't
pass in everything the method needs; instead you pass enough so that the method can get to
everything it needs. A lot of what a method needs is available on the method's host class. In
object-oriented programs parameter lists tend to be much smaller than in traditional
programs.
This is good because long parameter lists are hard to understand, because they become
inconsistent and difficult to use, and because you are forever changing them as you need
more data. Most changes are removed by passing objects because you are much more likely
to need to make only a couple of requests to get at a new piece of data.
Use Replace Parameter with Method when you can get the data in one parameter by making
a request of an object you already know about. This object might be a field or it might be
another parameter. Use Preserve Whole Object to take a bunch of data gleaned from an
object and replace it with the object itself. If you have several data items with no logical
object, use Introduce Parameter Object.
There is one important exception to making these changes. This is when you explicitly do
not want to create a dependency from the called object to the larger object. In those cases
unpacking data and sending it along as parameters is reasonable, but pay attention to the pain
involved. If the parameter list is too long or changes too often, you need to rethink your
dependency structure.
I don't want to sound like a wise-crack, but you should also check to make sure the data you are passing around really should be passed around: Passing stuff to a constructor (or method for that matter) smells a bit like to little emphasis on the behavior of an object.
Don't get me wrong: Methods and constructors will have a lot of parameters sometimes. But when encountered, do try to consider encapsulating data with behavior instead.
This kind of smell (since we are talking about refactoring, this horrible word seems appropriate...) might also be detected for objects that have a lot (read: any) properties or getters/setters.
If some of the constructor parameters are optional it makes sense to use a builder, which would get the required parameters in the constructor, and have methods for the optional ones, returning the builder, to be used like this:
return new Shniz.Builder(foo, bar).baz(baz).quux(quux).build();
The details of this are described in Effective Java, 2nd Ed., p. 11. For method arguments, the same book (p. 189) describes three approaches for shortening parameter lists:
Break the method into multiple methods that take fewer arguments
Create static helper member classes to represent groups of parameters, i.e. pass a DinoDonkey instead of dino and donkey
If parameters are optional, the builder above can be adopted for methods, defining an object for all parameters, setting the required ones and then calling some execute method on it
You can try to group your parameter into multiples meaningful struct/class (if possible).
I would generally lean towards the structs approach - presumably the majority of these parameters are related in some way and represent the state of some element that is relevant to your method.
If the set of parameters can't be made into a meaningful object, that's probably a sign that Shniz is doing too much, and the refactoring should involve breaking the method down into separate concerns.
I would use the default constructor and property settors. C# 3.0 has some nice syntax to do this automagically.
return new Shniz { Foo = foo,
Bar = bar,
Baz = baz,
Quuz = quux,
Fred = fred,
Wilma = wilma,
Barney = barney,
Dino = dino,
Donkey = donkey
};
The code improvement comes in simplifying the constructor and not having to support multiple methods to support various combinations. The "calling" syntax is still a little "wordy", but not really any worse than calling the property settors manually.
You haven't provided enough information to warrant a good answer. A long parameter list isn't inherently bad.
Shniz(foo, bar, baz, quux, fred, wilma, barney, dino, donkey)
could be interpreted as:
void Shniz(int foo, int bar, int baz, int quux, int fred,
int wilma, int barney, int dino, int donkey) { ...
In this case you're far better off to create a class to encapsulate the parameters because you give meaning to the different parameters in a way that the compiler can check as well as visually making the code easier to read. It also makes it easier to read and refactor later.
// old way
Shniz(1,2,3,2,3,2,1,2);
Shniz(1,2,2,3,3,2,1,2);
//versus
ShnizParam p = new ShnizParam { Foo = 1, Bar = 2, Baz = 3 };
Shniz(p);
Alternatively if you had:
void Shniz(Foo foo, Bar bar, Baz baz, Quux quux, Fred fred,
Wilma wilma, Barney barney, Dino dino, Donkey donkey) { ...
This is a far different case because all the objects are different (and aren't likely to be muddled up). Agreed that if all objects are necessary, and they're all different, it makes little sense to create a parameter class.
Additionally, are some parameters optional? Are there method override's (same method name, but different method signatures?) These sorts of details all matter as to what the best answer is.
* A property bag can be useful as well, but not specifically better given that there is no background given.
As you can see, there is more than 1 correct answer to this question. Take your pick.
If you have that many parameters, chances are that the method is doing too much, so address this first by splitting the method into several smaller methods. If you still have too many parameters after this try grouping the arguments or turning some of the parameters into instance members.
Prefer small classes/methods over large. Remember the single responsibility principle.
You can trade complexity for source code lines. If the method itself does too much (Swiss knife) try to halve its tasks by creating another method. If the method is simple only it needs too many parameters then the so called parameter objects are the way to go.
If your language supports it, use named parameters and make as many optional (with reasonable defaults) as possible.
I think the method you described is the way to go. When I find a method with a lot of parameters and/or one that is likely to need more in the future, I usually create a ShnizParams object to pass through, like you describe.
How about not setting it in all at once at the constructors but doing it via properties/setters? I have seen some .NET classes that utilize this approach such as Process class:
Process p = new Process();
p.StartInfo.UseShellExecute = false;
p.StartInfo.CreateNoWindow = true;
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.RedirectStandardError = true;
p.StartInfo.FileName = "cmd";
p.StartInfo.Arguments = "/c dir";
p.Start();
I concur with the approach of moving the parameters into a parameter object (struct). Rather than just sticking them all in one object though, review if other functions use similar groups of parameters. A paramater object is more valuable if its used with multiple functions where you expect that set of parameters to change consistently across those functions. It may be that you only put some of the parameters into the new parameter object.
Named arguments are a good option (presuming a language which supports them) for disambiguating long (or even short!) parameter lists while also allowing (in the case of constructors) the class's properties to be immutable without imposing a requirement for allowing it to exist in a partially-constructed state.
The other option I would look for in doing this sort of refactor would be groups of related parameters which might be better handled as an independent object. Using the Rectangle class from an earlier answer as an example, the constructor which takes parameters for x, y, height, and width could factor x and y out into a Point object, allowing you to pass three parameters to the Rectangle's constructor. Or go a little further and make it two parameters (UpperLeftPoint, LowerRightPoint), but that would be a more radical refactoring.
It depends on what kind of arguments you have, but if they are a lot of boolean values/options maybe you could use a Flag Enum?
I think that problem is deeply tied to the domain of the problem you're trying to solve with the class.
In some cases, a 7-parameter constructor may indicate a bad class hierarchy: in that case, the helper struct/class suggested above is usually a good approach, but then you also tend to end up with loads of structs which are just property bags and don't do anything useful.
The 8-argument constructor might also indicate that your class is too generic / too all-purpose so it needs a lot of options to be really useful. In that case you can either refactor the class or implement static constructors that hide the real complex constructors: eg. Shniz.NewBaz (foo, bar) could actually call the real constructor passing the right parameters.
One consideration is which of the values would be read-only once the object is created?
Publicly writable properties could perhaps be assigned after construction.
Where ultimately do the values come from? Perhaps some values are truely external where as others are really from some configuration or global data that is maintained by the library.
In this case you could conceal the constructor from external use and provide a Create function for it. The create function takes the truely external values and constructs the object, then uses accessors only avaiable to the library to complete the creation of the object.
It would be really strange to have an object that requires 7 or more parameters to give the object a complete state and all truely being external in nature.
When a clas has a constructor that takes too many arguments, it is usually a sign that it has too many responsibilities. It can probably be broken into separate classes that cooperate to give the same functionalities.
In case you really need that many arguments to a constructor, the Builder pattern can help you. The goal is to still pass all the arguments to the constructor, so its state is initialized from the start and you can still make the class immutable if needed.
See below :
public class Toto {
private final String state0;
private final String state1;
private final String state2;
private final String state3;
public Toto(String arg0, String arg1, String arg2, String arg3) {
this.state0 = arg0;
this.state1 = arg1;
this.state2 = arg2;
this.state3 = arg3;
}
public static class TotoBuilder {
private String arg0;
private String arg1;
private String arg2;
private String arg3;
public TotoBuilder addArg0(String arg) {
this.arg0 = arg;
return this;
}
public TotoBuilder addArg1(String arg) {
this.arg1 = arg;
return this;
}
public TotoBuilder addArg2(String arg) {
this.arg2 = arg;
return this;
}
public TotoBuilder addArg3(String arg) {
this.arg3 = arg;
return this;
}
public Toto newInstance() {
// maybe add some validation ...
return new Toto(this.arg0, this.arg1, this.arg2, this.arg3);
}
}
public static void main(String[] args) {
Toto toto = new TotoBuilder()
.addArg0("0")
.addArg1("1")
.addArg2("2")
.addArg3("3")
.newInstance();
}
}
The short answer is that:
You need to group the related parameters or redesigning our model
Below example, the constructor takes 8 parameters
public Rectangle(
int point1X,
int point1Y,
int point2X,
int point2Y,
int point3X,
int point3Y,
int point4X,
int point4Y) {
this.point1X = point1X;
this.point1Y = point1Y;
this.point2X = point2X;
this.point2Y = point2Y;
this.point3X = point3X;
this.point3Y = point3Y;
this.point4X = point4X;
this.point4Y = point4Y;
}
After grouping the related parameters,
Then, the constructor will take ONLY 4 parameters
public Rectangle(
Point point1,
Point point2,
Point point3,
Point point4) {
this.point1 = point1;
this.point2 = point2;
this.point3 = point3;
this.point4 = point4;
}
public Point(int x, int y) {
this.x = x;
this.y= y;
}
Or even make the constructor smarter,
After redesigning our model
Then, the constructor will take ONLY 2 parameters
public Rectangle(
Point leftLowerPoint,
Point rightUpperPoint) {
this.leftLowerPoint = leftLowerPoint;
this.rightUpperPoint = rightUpperPoint;
}