What is the best way to pass high level data, like the grid data of a map, to something really low level like a single unit or character?
I guess I could pass it to the unit manager and then to the unit or store it somewhere globally, but both ways seem dirty and horrible.
What is considered best practice?
Related
Having a class-level variable and instantiating the object at the same time creates a problem for Unit Testing because you can't really mock the dependency.
Does this mean the Kotlin feature by lazy should be avoided as it hinders proper unit testing, or is there a way to overcome this? Thanks.
A lazy is just a val that gets initialised later - if you need to change all your vals to vars so you can poke around at them while testing, that's probably a bad sign.
If your lazy is creating objects, then that's where dependency injection comes in - pass in the dependency, or something that provides the dependency, and then you can mock that when the lazy initialiser calls it.
If you're just trying to change the internal state so you can test a particular scenario, that's trickier. Ideally with a unit test you're testing the behaviour of a single component, and how it interacts with other things - if it provides the expected input and output. You shouldn't need to poke around at the internals, at least not in a way that isn't already part of the design and part of the expected use case.
But sometimes you want to recreate state, which is possible using the normal API, but takes a lot of code. That's a trickier call when the component isn't already designed that way - if it's that important, you might want to make it configurable, either through constructor parameters or by passing in some kind of config object.
Making things public that should be private just for testing is usually a sign that you should find another way to do your test. Changing a val to a var just for testing is especially bad, because it breaks the usual immutability guarantees and now your code has to handle all the "possibly changed" warnings even though you know it's really a val. I don't think lazy really makes much difference here - it's just a fancy getter, an internal implementation detail. I think your issues are more down to how the code is structured, and injecting your dependencies will probably help a lot
I've been using Vuex, and it's adherence to only altering state through it's mutators or actions makes me think your store should only include as flat an object as you can, with only primitives types.
Some threads even prescribe normalising your data (so instead of nested object trees you have objects with arrays of id's to indicate tree relationships). This probably matches closely to your JSON api.
This makes me think that storing classes (that may have methods to alter themselves) in your flux store is an anti-pattern. Indeed even hydrating your store's data into a class seems like you're moving against the tide unless your class performs no modifications to its internal data.
Which then got me thinking, is using any class in a Vue/Vuex/Reactive/Flux an anti-pattern?
The libraries seem explicitly designed to work with plain JS objects and the general interactions you have with the API (data in, data out) makes me feel like a more functional approach (sans immutability) is what the original designers were thinking about.
It also seems be easier to write code that runs from function => test => state mutator wrapper around function.
I understand that JS objects and JS classes behave very similarly (and are basically the same thing), but my logic is if you don't design with classes in mind, then you're more likely to not pollute your state with non-flux state changes.
Is there a general consensus in the community that your flux code should be more functional and less object orientated?
Yes. You are absolutely right in what you are thinking. State containers like Redux, Vuex are supposed to hold your data constructs and not functions. It is true that functions in JavaScript are simply objects which are callable. You can store static data on functions too. But that still doesn't qualify as pure data. It is also for this same reason that we don't put Symbols in our state containers.
Coming back to the ES classes, as long as you are using classes as POJO i.e. only to store data then you are free to use those. But why have classes if you can have simple plain objects.
Separating data from UI components and moving it into state containers has fundamental roots in functional programming. Most of the strict functional languages like Haskell, Elm, OCaml or even Elixir/Erlang work this way. This provides strong reasoning about your data flows in your application. Additionally, this is complemented by the fact that, in these languages, data is immutable. And, thus there is no place for stateful Class like construct.
With JavaScript since things are inherently mutable, the boundaries are a bit blur and it is hard to define good practices.
Finally, as a community, there is no definite consensus about using the functional way, but it seems that the community is heading towards more functional, stateless component approaches. Some of the great examples are:
Elm
ReasonML
Hybrids
swiss-element
Cycle.js
And now, even we have functional components in both Vue and React.
First of all: This is not an question of opinion (I'm afraid someone will flag this question), I'm interested in the technological background or the decisions for this.
That being said: Redux's store needs to be serializable. It is not allowed or frowned upon to use model classes and write their instances in the store. This is highly annoying to me. The applications logic ends up in actions or reducers where models would be a nice thing to have.
I am wondering why. What is the technological decision behind this? Why not write class instances to the store?
1) Class in instances are mutable, which leads to the same problems redux has tried to address around predictability of state by championing immutability. It also means you have to do more manual shouldComponentUpdate checks for changes if pairing with React (as references to mutated instances will be the same even if their internal state has changed)
2) Immutability makes it possible to move back and forth between states (eg during time travel debugging), something that cannot be done when mutations have occurred within instances
3) Serialisation means its very easy to persist and rehydrate the store (to/from JSON) for more advanced uses such as server side rendering and offline use
If you are interested I just wrote a more in depth answer to a similar question with an example of how it is possible to use the best of both worlds https://stackoverflow.com/a/47472724/7385246
I'll give you an example about path finding. When you wnat to find a path, you can pick a final destination, a initial position and find the fastest way between the two, or you can just define the first position, and let the algorithm show every path you can finish, or you may want to mock this for a test and just say the final destination and assume you "teleport" to there, and so on. It's clear that the function is the same: finding a path. But the arguments may vary between implementations. I've searched a lot and found a lot of solutions: getting rid of the interface, putting all the arguments as fields in the implementation, using the visitor pattern...
But I'd like to know from you guys what is the drawback of putting every possible argument (not state) in one object (let's call it MovePreferences) and letting every implementation take what it needs. Sure, may you need another implementation that takes as argument that you didn't expect, you will need to change the MovePreferences, but it don't sound too bad, since you will only add methods to it, not refactor any existing method. Even though this MovePreferences is not an object of my domain, I'm still tempted to do it. What do you think?
(If you have a better solution to this problem, feel free to add it to your answer.)
The question you are asking is really why have interfaces at all, no, why have any concept of context short of 'whatever I need?' I think the answers to that are pretty straightforward: programming with shared global state is easy for you, the programmer, and quickly turns into a vortex for everyone else once they have to coalesce different features, for different customers, render enhancements, etc.
Now the far other end of the spectrum is the DbC argument: every single interface must be a highly constrained contract that not only keeps the knowledge exchanged to an absolute minimum, but makes the possibility of mayhem minimal.
Frankly, this is one of the reasons why dependency injection can quickly turn into a mess: as soon as design issues like this come up, people just start injecting more 'objects,' often to get access to just one property, whose scope might not be the same as the scope of the present operation. [Different kind of nightmare.]
Unfortunately, there's almost no information in your question. Do I think it would be possible to correctly model the notion of a Route? Sure. That doesn't sound very challenging. Here are a few ideas:
Make a class called Route that has starting and ending points. Then a collection of Traversals. The idea here would be that a Route could completely ignore the notion of how someone got from point a to point b, where traversal could contain information about roads, traffic, closures, whatever. Then your mocked case could just have no Traversals inside.
Another option would be to make Route a Composite so that each trip is then seen as the stringing together of various segments. That's the way routes are usually presented: go 2 miles on 2 South, exit, go 3 miles east on Santa Monica Boulevard, etc. In this scenario, you could just have Routes that have no children.
Finally, you will probably need a creational pattern. Perhaps a Builder. That simplifies mocking things too because you can just make a mock builder and have it construct Routes that consist of whatever you need.
The other advantage of combining the Composite and Builder is that you could make a builder that can build a new Route from an existing one by trying to improve only the troubling subsegments, e.g. it got traffic information that the 2S was slow, it could just replace that one segment and present its new route.
Consider an example,
Say if 5 arguments are encapsulated in an object and passed on to 3 methods.
If the object undergoes change in structure, then we need to run test cases for all the 3 methods. Instead if the method accepts only the arguments they need, they need not be tested.
Only problem I see out of this is Increase in Testing Efforts
Secondly you will naturally violate Single Responsibility Principle(SRP) if you pass more arguments than what the method actually needs.
I have a factory class that creates an object based on a parameter it receives. The parameter is an identifier that tells it which object it should create.
Its first step is to use the data access layer to pull information for the object.
Its next step is to do some cleansing / transformations on the data.
Finally it creates the required object and returns it.
I want to ensure that the cleansing / transformation step went OK but the object that it returns does not expose any state so I'm not sure how to test it easily.
The data access layer and the database structure can't change because they have to work with legacy code.
I could test it further on in the system after the object gets used but that would lead to big tests that are hard to maintain.
I've also thought of exposing the state of the object, or putting the responsibility in another class and testing that, but both those options seem like I'm changing the system for testing.
Any thoughts on other ways to test something like this?
It sounds to me like you are trying to test too much within a unit test.
This is a symptom of your Unit trying to do too much.
You are trying to do three things here.
Get data from the data access layer.
Clean the data.
Build the object
To fix I would move each of these responsibility into their own units ( classes / methods ) as you have suggested. Then you can test each unit on its own.
You are hesitant to do this as you don't want to change the system for testing. However, the advantage of unit testing is that it highlights flaws in the design. Not only are you changing the system for testing, you are improving it and making it more granular and thus more maintainable and reusable.
Your factory object is trying to do too much here. I recommend refactoring your code to give the responsibility of cleansing the data to another object, and testing that object's behaviour.
I've also thought of exposing the state of the object, or putting the
responsibility in another class and testing that, but both those
options seem like I'm changing the system for testing.
That's right, you are changing the system for testing. And it's a good thing. This is an example of Test Driven Design driving out a better design exhibiting looser coupling and higher cohesion, by forcing you down the path of giving your classes fewer responsibilities. (Ideally, each class would only have just one responsibility.) That's one of the key benefits of TDD, so don't fight it.
I know two ways to achieve this:
- in Java, by using reflection.
- (and the best, IMO) programming focused on interfaces, so you can implement the interfaces whereby you can access the data.