Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I have this class here:
#Component
class UpdateRule(
private val rulesRepo: UpdateRuleRepo
) : UpdateRuleStoreGateway, UpdateRuleLoadGateway {
override fun store(rule: UpdatRule) {
//some code
}
override fun loadAll(): List<UpdateRule> {
//some code
}
Since I'm new to Spring and Kotlin, I'm not familiar with this syntax. What does the val inside the brackets mean (private val rulesRepo: UpdateRuleRepo) and what do the interfaces after the colon do (: UpdateRuleStoreGateway, UpdateRuleLoadGateway)? Is this Kotlin specific or Spring specific syntax and where can I read more about it?
This is Kotlin syntax, not Spring-specific.
What does the val inside the brackets mean (private val rulesRepo: UpdateRuleRepo)
The part between the parentheses () is the list of arguments for the primary constructor of the class. When a constructor argument is marked val or var, it also declares a property of the same name on the class.
In this case, it means rulesRepo is a constructor argument of the class UpdateRule, but also a property of that class. Since it's a val, it means the property is read-only (it only has a getter).
You can read more about this in the docs about constructors.
what do the interfaces after the colon do (: UpdateRuleStoreGateway, UpdateRuleLoadGateway)?
The types listed after the : in a class declaration are the parent classes (or interfaces) extended (or implemented) by that class. In this case it means UpdateRule implements both interfaces UpdateRuleStoreGateway and UpdateRuleLoadGateway.
This is described in the docs about implementing interfaces.
Val is var but final to put it simply. Final means it cannot be reassigned to another object/primitive data. But do keep it mind that it doesn't mean internal data is immutable. It's not like Python tuple! Individual element/member variables can be modified, but the whole thing cannot be reassigned(think of variable as a pointer, and it's referencing to the same object, although the internal details of the object may change over time)
Kotlin var is different from Java var by the way.
More on that here: https://www.baeldung.com/kotlin/java-kotlin-var-difference
I personally find kotlin var similar to TypeScript let.
Related
This question already has answers here:
What is the difference between var and val in Kotlin?
(41 answers)
Closed 1 year ago.
I am learning Spring Boot with kotlin and I am so confused with the usage of var or val for entity property. In some tutorial they use val and the other use var. So I don't know which is the right one to declare property for entity. At least enlightenment me about this. Please & Thanks!!
val and var both are used to declare variables but the main difference between them could be defined as;
val: is used when you declare a variable with a value which you don't want to change or update, it is kind of a constant variable which can only be initialized once. And when you try to change its value, it will show an error like Val can not be reassigned. it is known as immutable variable in kotlin.
On the other hand,
var: is used when you intend to declare a general variable whose value could be changed or updated anywhere in the class. It could be initialized or reassigned multiple times and it is known as mutable variable in kotlin.
I hope this will help you. There is a good definition with example.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I'm programming a piece of software that consumes APIs from different services and the methods would be the same but different execution. I wonder if the code can be organized in interfaces or I just keep working like this:
type endPoint struct{
serverName string
}
func (this *endPoint) getLastDateURL () string{
if this.Name ="A"{
return "api.someAWebsite.com/getLastDate"
}
if this.Name ="B"{
return "api.someBWebsite.com/getLastDate"
}
return ""
}
func (this *endPoint) processData () output{
if this.Name ="A"{
//process in some way
return
}
if this.Name ="B"{
//process in some different way
return
}
return
}
The interface alternative I'm thinking is about this:
struct endPoint interface{
getLastDateURL()
processData()
}
...
Do each method for each API provider
How would I use it then?
My end goal is to have maintainable and clean code. Honestly hate the fact that I'd have to write the same methods for each end point to implement the interface, but perhaps I do not have the Interface concept just so clear yet or there is little advantage in using interfaces in this case with again, the end goal of maintainable and clean code.
Thanks.
// "struct endPoint interface" is invalid, and signatures are missing their return types:
type endPoint interface{
getLastDateURL() string
processData() output
}
How would I use it then?
I can't give a complete solution since you haven't shown how you're using your current code, but in general you'd have:
Something that instantiates an implementation - whatever would be setting Name in the current implementation would instead create an instance of a concrete type implementing endPoint
Something that calls getLastDateURL and/or processData - instead of receiving an *endPoint struct, it would receive an endPoint interface value, and then wouldn't care what the underlying implementation is; it would just call the methods, pretty much just like it does today
My end goal is to have maintainable and clean code.
This is probably a good way to achieve that, but it depends on context not shown in the question.
Honestly hate the fact that I'd have to write the same methods for each end point to implement the interface
You're already writing an implementation for each end point, you're just writing them all in the same methods. The amount of code you have to write is almost identical, but the resulting code is cleaner & more organized - for example, each concrete implementation could be in its own file, rather than having to be all in the same methods. With many/complex providers, your current solution becomes increasingly difficult to navigate if you ever need to change it or add a provider.
Use the double dispatch pattern:
Define a typed func on endPoint for each class it supports.
Define an interface that has a func that accepts an endPoint object.
Have all classes that want to use endPoint implement that interface’s func and pass themselves to the typed endPoint method.
To invoke it, call the interface method passing endPoint.
IMHO you should do it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am trying to use the MVVM architecture to develop a To-Do list app. A ToDoItem is stored in a JSON file and contains various properties (e.g. Title, Description, and Difficulty). The app assigns a Difficulty to the ToDoItem based on input parameters from the user and other properties of the ToDoItem.
Should the method which calculates the Difficulty be part of the ToDoItem model? If not, would it be better in the ToDoItemViewModel or in another class?
It is perfectly ok for model classes to expose methods that are specific to the domain model they are representing. Consider the following case:
class Car
{
public double Fuel { get; private set; }
public void AddFuel(double amount)
{
//todo
}
}
It is perfectly fine for such a class to expose that method, within wich you can perform all sort of validations (that the tank is not already full, etc).
On thing that you should not expose (in most cases) in a model class is data persistence, which does not belong to the domain that is being represented by the model.
Another thing to consider is Inmutability, which is in general always a good thing. I would say that for a ToDoItem does not make sense to expose a way to change its Difficulty, so this should be a readonly property, therefore it should be injected in the constructor IMO
Consider then the semantic dimension of your implementation, for a Car it makes sense to have a way to change the amount of Fuel it has, ask yourself: Does it makes sense for a TodoItem to change its difficulty after having been created?
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
When making a subclass, its inner classes will always subclass from the parent, not its child.
class Create
class Draft < self
# code
class Update < Create
# Update::Draft's is implicitly created, but its parent is Create, not `Update`. Why?
Create::Draft.superclass will return Create. That's fine. But Update::Draft.superclass will return Create too. I want Update::Draft to inherit from Update class.
Ruby doesn't have nested classes, which also means it doesn't have virtual classes (obviously, since virtual classes are a special case of nested classes). If you want to use virtual classes, you need to use a language which supports them, such as Beta, gBeta, or newspeak (I don't know of any others).
Since virtual classes are nested classes that are virtual, you can sort-of fake them in Ruby with methods (which are nested inside classes and virtual) returning classes (which are first-class objects in Ruby, and thus can be returned by methods).
That still doesn't solve the problem that the superclass expression is evaluated only once, during class declaration, and not everytime for every message send, though. Again, newspeak does this, so you could just use that.
There are other problems with your code. For example, you somehow want an Update::Draft class to magically appear. If you want a fourth class, you need to define a fourth class. There is no fourth class. There isn't even a fourth constant. It's just constant lookup rules. Update doesn't have a constant named Draft, so Ruby continues looking in the lexically enclosing class (which is Object), which also doesn't have a constant named Draft, so it continues looking in the superclass and finds it there. Nothing appeared. It was always there.
Since there is only one class, it cannot have to different superclasses at different times, you really need to classes.
What you basically want is class hierarchy inheritance, which is a feature enabled by virtual classes. newspeak's parser combinator library is a great example of the use of class hierarchy inheritance.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am sure I am not the only one who's facing this problem but I am unable to find a solution till now. The problem is as below.
I have published a web service (on which I don't have any control and I cannot change it) from a legacy system and all the clients are using it. I receive requests from the web service and object which i get is a very complex one but for the sake of an example lets say I receive object A from the web service call which contains several other objects like Object B, Object C in it etc and in addition objects B & C also have some primitive data types as well as some other objects in them. My problem is that I want to validate the whole Object A (all the including objects and sub objects), which design pattern is recommended here? Secondly, the main point here is that I can get different types of Object A from the web service. What i really mean by different types of object A is that the Object A depends upon the client i.e. some clients will send Object A without filling the data in the containing Object B or even they can fill Object B partially and then send it in Object A. So I have to validate the Object A based on the client (as some clients will require containing Object B some will not, some will require few elements in Object B etc). So in other words I will have a place where I will also store the validation rules for each client which will tell me something like this that client ABC wants field abc in Object B to be of type string and the maximum length is 25 chars and it is mandatory to have data in that field.
Some validations which I would like to perform is
Checking fields of some object (say Object B) for data types, length of a particular field, is the field required for this client or is it optional etc etc...
Any concrete working example will be extremely useful.
The structure of the Object A for this particular example is as follows.
public class A
{
private B objectB;
private C objectC;
// and so on
}
public class B{
private E objectE;
private String name;
private int age;
// and so on
}
public class C
{
private F objectF;
private String address;
private String country;
}
public class E
{
// Members here
}
public class F
{
// Members here
}
P.S: I have given arbitrary names to the classes and the members just for the general understanding. O yes I forgot to mention that I am using java here but it doesn't really matter as the design principles or patterns can be applied to any language. Hoping to hear from you guys soon.. :)
Validation is a Cross Cutting Concern. There are several ways and several design patterns can be implemented.
In Asp.net it is being done via attributes, in Java Spring it is done via Annotations to keep the code clean, readable and maintainable.
You can find tons of different approaches, what you need to keep in mind is the approach of these frameworks follow. ie code maintenance, readability and clean code.
There is no silver bullet. You can even write validation in your code.
Each class should know how to validate itself. You can derive each class from an interface (say IValidatable) that has a .Validate() method. When you call .Validate() on object A, have it validate itself, and then call .Validate() on all children. Those children can validate themselves in a similar fashion.
I think this is a really simple version of the command pattern. Sort of.
You could also compose a Validator that you can attach to your class. The validator can know how to validate email addresses, regular addressess etc. This is a bit more extensible as you are basically creating a toolbox to attach to your class that only contains the tools it needs.