We Keep Coding

Best way to implement this? [closed]

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
Hi I'm a unity developer working on a bar manger game and I'm just wondering on the best way to implement a drinks system where it sets the value of the drink, number of servings in the barrel, name of the drink price of the whole barrel.
Here is some code I was working on before:
This is the interface method
public interface IDrinkSystem
{
string SetDrinkName(string nameToSet);
float SetDrinkValue(float drinkValue);
int AmmountOfServingsInBarrel(int Servings);
float PriceOfBarrel(float price);
}
This is the class method of doing it
public class DrinkSystem
{
public void NewDrink(string drinkName, float drinkValue, int barrelServings, float barrelPrice)
{
// Have getters and setters for all values in separate methods
}
}
What is the best way for making it easy to expand and at a push can I make an array of the NewDrink to store all the drinks i have or is there abetter way of doing this.

Use ScriptableObjects, as if they were files.
For every type of drink, have a ScriptableObject which you can fill in from Unity easily (even your artist can do this), and then at runtime, you load them into objects of a single DrinkEntity class which loads these values.
This way you don't end up with dozens or hundreds of "DrinkSystemBeer"/"DrinkSystemWhiskey"/etc classes, but you can still keep all your code clean and pattern-friendly.
IMPORTANT: NEVER operate with the ScriptableObjects directly. Simply load them into a DrinkEntity on its constructor. Treat ScriptableObject as if they were xml or json files from which you read your data.

Changing an Existing class - Best Practice Open/Closed Principle [closed]

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 2 years ago.
Improve this question
I am trying to figure out the best way to change an existing class.
So the class is called ExcelReport and it has one method Create(data,headings). This is live and used in many places. Now recently I want to change the method so I can format columns in Excel.
Create(data, headings, columnformats)
So as not to upset my existing programs the best I can come up with is to add another method Create2(data,headings,columnformats) to the class.
I got a lot of suggestions saying I should modify the existing class with a overloaded method, which I did. But does this not break the Open/Close Principle as my existing class was in production?
Should I have created a new class ExcelReport2(and Interface) with the new improved method and passed this into my new program using dependency injection?

OCP
In object-oriented programming, the open–closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification";[1] that is, such an entity can allow its behaviour to be extended without modifying its source code.
Your solution
You will most likely want to create more options later on for this.
And since you asked for an open/closed principle answer we need to take that into account (open for extension, closed for change).
A more robust alternative is to create a new overload:
void Create(CreationOptions options);
Looks trivial, right? The thing is that any subclass can introduce their own options like MyPinkThemedFormattedCellsCreationOptions.
So your new option class would look like this as of now:
public class CreationOptions
{
public SomeType Data { get; set; }
public SomeType Headings { get; set; }
public SomeType[] ColumnFormats { get; set; }
}
That's open for extension and closed for change as new features doesn't touch the existing API, since now you only have to create sub classes based on CreationOptions for new features.

unit testing of class without dependencies [closed]

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 2 years ago.
Improve this question
Imagine I have the following class:
public class MyWeirdCollection
{
private IList<string> _myTrueList;
private IList<string> _myFalseList;
public MyCollection()
{
_myTrueList = new List<string>();
_myFalseList = new List<string>();
}
public void Add(string item, bool listType)
{
if (listType)
{
_myTrueList.Add(item);
}
else
{
_myFalseList.Add(item);
}
}
public IList<string> Get(bool listType)
{
return listType ? _myTrueList : myFalseList;
}
}
How would I go about unit testing the Get and Add methods? I'm doubting between 2 possible solutions:
Making the 2 lists protected instead of private, so I can create an inheriting TestableWeirdCollectionClass that exposes the content of the lists to the test
Leave the class as it is and test Add and Get together? i.e. calling Add to add some elements and then Get to see if the correct values come back.
I'm leaning towards option no. 2, but would like some more opinions. Thanks.

Definitely go for the option 2. Pretty much every test I can imagine must go though Add, then Get, together.
When testing you are ultimately testing the public interface, not the internal state. The whole idea of the test code is that you give items to it, then you get them back with the appropriate key. In your particular case it uses private lists to hold the items, but this may not be the case (you might store them to a database or file, rely on another class or something else). This is ultimately an implementation detail, the important bit is that Add and Get always play together, therefore you should it.

I would strongly recommend option 2. The reason is that your whole class should be consider a unit, and be tested as such. Making methods public for the sole purpose of unit testing can be motivated in some rare cases for very complex classes, but should be avoided if at all possible.
See also
Is it bad practice to make methods public solely for the sake of unit testing.
Would you rather make private stuff internal/public for tests, or use some kind of hack like PrivateObject

Trying to properly organize huge class [closed]

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 5 years ago.
Improve this question
I have huge class that implements usage of some client:
public class Client : IClient
{
internal Client(string username, string password){
//login process here
}
//some private methods that make sure connection stays alive, etc
public void Action1(string param1){
//something here...
}
public void Action2(string param1, string param2){
//something else here...
}
}
As it currently is, it's 5000+ lines long mainly because of lots of different public methods.
I'm wondering what is the best practice to properly organize and refactor this, preferably without making method calls more complicated?

Use partial classes and group things into logical sets per each partial class.
Also, if some methods make logical set, consider wrapping them into separate class.
Those 2 should reduce your lines of code per file dramatically.

Usually big class are "hiding" inside other classes (see uncle Bob on "Clean Code").
In your case I'd split the class creating Action classes and making some machanics that lets the Client use some sort of IAction or BaseAction. Thus splitting the logic of every action into a separate class.
To be more precise I'd rather need some more info and code.

Enum vs. concrete classes to denote an object type [closed]

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 7 years ago.
Improve this question
Basically, I need to implement a resources (gold, steel, etc.) functionality and their quantity, and I am wondering if it is better to use a single resource class with resourceType field or it is better to use many ConcreteResource classes that inherit Resource. Here are some examples for better understanding of my question:
Using enum:
class Resource
{
private ResourceType resourceType;
private int quantity;
}
enum ResourceType
{
ConcreteResource1,
ConcreteResource2
}
Using concrete classes:
abstract class Resource
{
private int quantity;
}
class ConcreteResource1 : Resource
{
}
class ConcreteResource2 : Resource
{
}

It really depends on the use of the objects.
There are a lot more features obtained by using classes:
It can be inherited,
It can have methods,
It can have properties, fields etc...
So, in general, if your objects aren't alike in their methods, variables, interfaces, etc, (that is, they are two quite different objects) you should use class. But if your objects are nearly identical except for the "type", then Enum should be sufficient.
In your example, suppose the two metals are used quite differently, one has set of methods [A1,A2,...,An], and another [B1,B2,...,Bm], then it is best if they are distinguished by class perhaps inheriting from the same MetalBase class.
However, if they are used almost identically, then you should consider using Enum