Hot answers tagged

21

If the data never changes and is read only, then just put it in a code file as a list of constants. public readonly string AppStartUpData = "MyAppNeedsThis"; If this data is different per deployment, then an external file is fine. .Net comes with built in .config files (App.Config). One should use those as there are standard ways (built in to the ...


14

You can always add a file into your project and set its build type to Embedded Resource so that it is embedded directly into the application itself. Alternatively a file that is encrypted and placed in an accessible location.


13

A binary file would be the obvious answer, but it depends on how you are loading it - you might as well make life easy for yourself if you can. XML might be a good choice as there are built in methods in C# for reading this. You could add a checksum to your data, so that if the user alters it, the checksum will no longer match (you need to add a check to ...


10

Your option 2 is usually preferred. Option 1 violates the common guideline known as the "Law of Demeter" -- it means that your main program now knows in detail how your Recipe voting works, which makes it harder to change that if you decide to do it another way later. This is an example of unnecessary coupling, which we usually try to minimise.


6

If you don't want the user to even peek at the data, you should serialize it into a binary data file. Only the app would know the length of the chunks to read from it. I don't know C# but in Java you would create the file like this: FileOutputStream fos = new FileOutputStream(file); ObjectOutputStream oos = new ObjectOutputStream(fos); oos....


4

Let's take a look at your domain: 1) You have Recipes Recipes are a collection of Ingredients and according steps to follow in order to get things done. 2) Ingredients have a name and perhaps a category (»vegetable«, »spice«, »whatever«) I see no place where inheritance comes into play. Does it make sense to refactor to an inheritance hierarchy ...


3

Several comments: You've created a closure helper to create a relatively simple object, so you could use a simple function instead of a closure. When you use a substantially more complex construct than necessary, it makes the reader wonder why, and this adds to confusion. The following function does the same without the closure. function ...


2

In addition to @Jules very good answer: Perhaps you are thinking about the decision making at too low a level. Remember, you are trying to provide a useful and complete abstraction to clients/users/callers. So, one way to frame the question is, do you want clients/callers to have an API that is about: recipes that have some relationship with a ...


2

Let's call your first option option A, and the second one option B. Your only peeve about option A is that SingleplayerGameSetup "is basically empty right now.". I think that doesn't matter because obviously your code will grow with time and chances are SingleplayerGameSetup will not be empty forever. You cannot foresee the future. In option B, you would ...


2

Second option makes more sense from an encapsulation and class responsibility standpoint. In fact the word "Shared" is not really required - Settings captures a Seed and AiNations (whatever these might be) for any Game Setups. I wouldn't recommend creating abstract classes just to enable code re-use, unless the abstract class/interface really defines the ...


1

There really is no difference from what you have now and the second option you stated. Once again, you have common members, only they are now encapsulated in one class. This mitigates the problem when you need to add or change something in SharedGameSetupSettings, but if you need to add something else that is common for both SingleplayerGameSetup and ...


1

If the processing time is much more than the time spend on writing to the db for each bolt, you could use an output queue. Each bolt can write it's results to the queue and continue processing. You could use a separate process to write entries from the queue to the table.


1

If you have the locking mechanism in place on the table in the database, then the concurrent writing in it is not possible, so there is no other way to parallelize the writing. Simply, the database is the bottleneck. The only gain that you get is that the processing done by bolts before the data is written into database is done in parallel. Therefore, the ...


1

For your applications, create one repository for each. This is so that your commits only relate to changes of that specific application. This will allow you to keep better track of your versions. For your Data Structures, perhaps you could create one repository for all of them (and consider that repository a "foundational component" library).


1

I have little mathematical background but I do see an approach that might work. I would assign a value to each coordinate in the grid that is determined by the amount and closeness of dotted neighbors. Then apply a threshold: only keep the coordinates that exceed the threshold value. Those will form the result path.



Only top voted, non community-wiki answers of a minimum length are eligible