This is a super newbie question, I've been programming for a while, but am just learning OOP.
I have a class that works with user input via the C# console.
There are different methods in this class to gather different input sets.
I have another class that takes these input sets and puts them in a database.
What is the best way to pass the input from my input class to my database insert class?
My guess would be:
Array1[] = inputClass.GetParameterSet1();
DatabaseInsertClass.InsertIntoDatabase1(Array1[]);
Is there anything wrong with this or is there a better way to do this? Should I even have two classes (The database class could also take the user input)?
You should have a "data" class, that represents all of your parameters.
Your GetParameters class should create an instance of this class.
Your InsertDatabase class should accept an instance of this class.
public class Data
{
public string value1 {get;set;}
// add more properties here
}
public class GetInputParameters
{
public Data GetParameters()
{
var d = new Data();
d.value1 = Console.ReadLine();
return d;
}
}
public class InsertToDatabase
{
public void InsertRecord(Data value)
{
// database persistance code
}
}
Additionally, you could use a generic list to pass more than once instance of the data class, you could use an array, but a generic list is much easier to work with.
In general I think separating your code out into different layers is a good idea. Right now you have your UI layer (the one that works with console input) and your Data layer (the one that inserts data). That's a good start.
What kind of data are you collecting and then inserting? That might be a good candidate for another class. Let's say it's user info, and a user enters their name, age, gender, etc. Whatever you're collecting it can probably be packaged up into an object. You can then just pass this object along to your Data class. The data class can then digest that information however it needs to.
In your input class:
User user = new User();
//get all user info from console, assigning it to your user object
DatabaseInsertClass.InsertIntoDatabase1(user);
Type safety is the first problem I see with this. A better approach would be to wrap your DB using LINQ to SQL, then simply pass around the business object into an abstracted Save() and Delete() method. That way the actual DB implementation could theorectically be replaced, however your business objects certainly would be of value going forward regardless.
At least two classes is definitely a good idea. You want to try to encapsulate functionality within a class. In a standard console application, I'd suggest creating a class for console I/O, a class for database access, and a class that will allow them to talk to each other, and possibly manipulate the data (i.e. a service class).
So, your console I/O class could wait for data, then call your service class to save the data, and your service would then call upon your database to save the data.
Related
I am trying to write a plugin for Autocad, and there, they have these Extension Dictionaries where you can save data into an Autocad object so that when you close a drawing file, the saved data persists.
Now I need 4 functions to manipulate the extension dictionary:
exist - for checking if an extension dictionary exists
create - for creating an extension dictionary
set - for setting data inside the extension dictionary
get - for getting data from the
extension dictionary
currently, what I have is I have an ExtensionDictionaryManager.cs that is partial broken down into 4 .cs files like this:
partial class ExtensionDictionaryManager
{
public bool Exist() {...}
}
partial class ExtensionDictionaryManager
{
public bool Create() {...}
}
partial class ExtensionDictionaryManager
{
public bool Set() {...}
}
partial class ExtensionDictionaryManager
{
public bool Get() {...}
}
Does this follow the Single Responsibility Principle? Or should I break it down even more into ExtensionDictionaryCreator, ExtensionDictionaryChecker, ExtensionDictionarySetter and ExtensionDictionaryGetter?
My concern is if I did break it into absolute single responsibilities, not grouping related functionalities together, and doing it consistently throughout my program, I would end up with so many objects.
Which would be the right way to do this?
The SRP is difficult to handle. See for example a Message class. Should this class contain a Send() method? Can a method send itself? Or should there be another class MessageSender?
Some people use the SRP only to make classes smaller and smaller, which might ultimately lead to classes containing only one method. But methods that belong togehter should stay together. A good help is how to decide what should be in the same class is: If I have to change a feature, often I have to change several methods. These methods should be in the same class. If I change always the same two classes at the same time, these classes maybe should be united. If I change only one part of a class, or the other, but never both parts at the same time, the class should be split. See also https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137
Coming back to the example with the message: If the mechanism of sending the message is completely unrelated to the data that the message contains, two classes Message and MessageSender might be better. If the format of the message is strongly linked to how to send the message, it might be better to have a single class. But this is always some subjective consideration.
And for your code: I would leave it in one class. See for example List<T>: This is one class for manipulating the list, and not a ListAdder<T>, ListInserter<T>, ListRemover<T>, ... If your autocad changes, you will have to change the the algorithm of checking whether something exists, of creating, and so on, all at the same time. That's why they belong into one class.
In the below adapter design pattern sample code, why a new class is introduced instead of using multiple interface in the client?
interface ITarget
{
List<string> GetProducts();
}
public class VendorAdaptee
{
public List<string> GetListOfProducts()
{
List<string> products = new List<string>();
products.Add("Gaming Consoles");
products.Add("Television");
products.Add("Books");
products.Add("Musical Instruments");
return products;
}
}
class VendorAdapter:ITarget
{
public List<string> GetProducts()
{
VendorAdaptee adaptee = new VendorAdaptee();
return adaptee.GetListOfProducts();
}
}
class ShoppingPortalClient
{
static void Main(string[] args)
{
ITarget adapter = new VendorAdapter();
foreach (string product in adapter.GetProducts())
{
Console.WriteLine(product);
}
Console.ReadLine();
}
}
I have the below queries related to the above code.
What, if ShoppingPortalClient directly inherits VendorAdaptee?
In which scenario we need adapter class?
why instead of simple inheritance a needed class, creating this pattern to access another class method?
Sometimes you have a given API that you can't change (legacy/external-library/etc...) and you want to make your classes be able to work with that API without changing their code.
Lets say you use an API which has an ISomethingToSerialize
public interface ISomethingToSerialize
{
object[] GetItemsToSerialize();
}
That API also has a Serialize function:
public class SerializationServices
{
byte[] Serialize(ISomethingToSerialize objectToSerialize);
}
Now you have a class in your code, and you don't want or not able to change it, let's call it MyUnchangeableClass.
This class doesn't implement ISomethingToSerialize but you want to serialize it using the API so you create AdapterClass which implement ISomethingToSerialize to allow MyUnchangeableClass to use it without implementing it by itself:
public class AdapterClass : ISomethingToSerialize
{
public AdapterClass(MyUnchangeableClass instance)
{
mInstance = instance;
}
MyUnchangeableClass mInstance;
public object[] GetItemsToSerialize()
{
return mInstance.SomeSpecificGetter();
}
}
Now you can use
MyUnchangeableClass instance = ... //Constructor or factory or something...
AdapterClass adapter = new AdapterClass(instance)
SerializationServices.Serialize(adapter);
to serialize an instance of MyUnchangeableClass even though it doesn't meet the requirements of the API by itself.
You've got the idea totally wrong. The VendorAdaptee is the instance of code that produce data, where the ShoppingPortalClient is the one who wants to consume it.
Let me explain what would be the real world situation. You are implementing the shop, and someone else has been implemented a service to give you data about their products(VendorAdaptee). The simple way of doing it is to simply call their methods and use the data, right? But it is their service and they might want to change it later while you don't want to upload your whole solution and release a new version. Therefore, you need an adapter in between to make sure that the data will be send to your real code with the format that you need, and you simply don't care about the address, method name or data format that has been supported by your vendor.
about your questions:
Inheritance is not in any way the case. Conceptually speaking, a shop is not a vendor in any way. considering the code, you have nothing similar in any of those 2, and the behavior is totally different. one is providing data while the other use it.
The main reason you would use an adapter is for legacy code that you don't want to mess with - or a third party that you won't to fit into a certain interface.
There are other reasons, usually depending on how you find easier to develop and if using the adapter design pattern makes sense to you. I don't see it as very useful in other cases though.
First of all I also don't think this is a good example for Adapter pattern. Adapter pattern is much meaningful when you can't directly use one particular kind of class(say A) in your class(say B), instead you implement another class(say C) which can be directly used inside your class (B) and it(C) can directly use the first one(A).
You might ask what will be the examples where B cannot directly use A. There's few.
A's methods don't return the type which is ideally needed by B.
So we don't to mess up with adding the conversion need by B inside B. Instead we give responsibility to C to do it for B.
It might not look natural for B to contain A. etc.
Back to your questions
(1) It is meaningful if you ask,
What, if ShoppingPortalClient directly 'uses' VendorAdaptee?
Just because it is the main class, it has been used as a demo, not to show the structure. And one thing to add, just because you want to call another class's method, don't inherit it unless it is meaningful. In this scenario composition is preferred. For the question why not 'using', just assume it cannot. But you rather ask why cannot. The answer I can give in this example is just assume it is not natural to call Adaptee. That's why I said it is not a good example. :)
(2), (3) I think you can get the answer from the description I have provided so far.
I'm writing a CAD program. Let's say I have in input class, this class reads various data from a text file and creates lots of lists/dictionaries and .... These data need to be accessed by other methods in other classes to be modified. Now here is how I have done it so far:
I have one static class: Building.cs When I create/or load a project this class holds all the data like list of columns, beams, points, etc. All of these are stored as private fields. I can access these using the class's public methods like GetColumns or GetPoints ...
Now I also have non-static classes. They contain 2-3 public methods. and do some stuff on various parts of the building.
public static class Building
{
private static List<Column> columns;
private static List<Beams> beams;
private static List<Points> points;
public static List<Column> GetColumns()
{
return Columns;
}
}
public class ColumnsService()
{
private List<Columns> columns;
public GroupColumns(List<Columns> columns)
{
this.columns = columns;
}
public void Group()
{
// group columns
}
}
var columns = Building.GetColumns();
var columnsService = new ColumnsService(columns);
columnsService.Group();
I was wondering is this the way to go? How else can I store the data. The data needs to be accessible throughout the lifetime of the program to most of the classes. What are the best practices.
What, semantically, is a Building?
To me, the name implies that it's an instance of a structure. That, in the overall business domain, there can be many "buildings" and at any given moment one is interacting with one of them.
If that's the case, then it seems unintuitive to me to make it static. If there's more than one, it should be an instance model. It would contain attributes which describe it and operations which interact with it. The business domain being modeled should drive the structure of this object before any consideration is given to how other objects are going to interact with it.
So let's assume we make it an instance model:
public class Building
{
// attributes and operations
}
Then, as you ask, how do other objects interact with it?
Depends on the interactions.
Let's say an object needs to "render" a building in some way. Let's call it BuildingPrinter for lack of a better term. Clearly it needs a Building to "print". So it requires one for that operation:
public class BuildingPrinter
{
public void Print(Building building)
{
// implementation
}
}
Or perhaps you have an object which "wraps" a building in some way. Something which can't meaningfully exist without a building, regardless of the operations performed. I can't think of one for that particular business domain, so let's just call it a BuildingWidget. Since it needs a building to exist at all, it requires one:
public class BuildingWidget
{
private Building currentBuilding;
private BuildingWidget() { }
public BuildingWidget(Building building)
{
currentBuilding = building;
}
}
The point is, from the perspective of the models which construct the overall domain, if something is required then it must be supplied. The models shouldn't go out to some global data store, tightly coupling with that data store, to get what they need. This is called the Dependency Inversion Principle.
But where will the consuming code which orchestrates the interactions of these models get instances of a Building? There are a number of potential solutions to that.
Two common patterns would be to have a static factory or a repository. For example:
public class BuildingFactory
{
public static Building FetchBuilding(int buildingId)
{
// implementation
}
}
This factory might have a static cached building object. The building itself isn't static, but for performance reasons an instance of it is cached statically so that it's not constantly re-fetched from a backing data store (such as a database). You might also add methods to invalidate the cache and re-fetch, or encapsulate that logic into the factory itself (such as always re-fetch after 5 minutes or after 10 accesses or some other rule). (Behind the scenes, this factory might even use a repository, shown below, to re-fetch that instance. In which case, you guessed it, a BuildingRepository would be required on the BuildingFactory constructor.)
This factory object may also be responsible for creating a building based on some specifications, if for example you have reason to make the Building constructor private.
Or, to re-fetch from data, consider a repository:
public class BuildingRepository
{
public Building GetBuilding(int buildingId)
{
// fetch from database
}
public Building SaveBuilding(Building building)
{
// save to database, return updated version
}
}
Then other code throughout the domain, including the consuming code, can use these objects to get/save buildings. The factory is static, so that can be invoked anywhere. The repository is instance but doesn't need to be globally distinct, so that can be instantiated anywhere (or pulled form a dependency injection container).
public class ScheduleRatesController
{
protected CoreDataManager dataManager;
public ScheduleRatesController()
{
dataManager = new CoreDataManager();
}
// testing
public ScheduleRatesController(CoreDataManager manager)
{
dataManager = manager;
}
public virtual void GetTranQuotesToFillRatesAndPayments(ref List<int> ids)
{
ids.AddRange(new List<int>());
}
}
So to give you guys some background, we're splitting one DB query into a bunch of different ones, and we want subclasses to basically each take on a DB call for their GetTranQuotesToFillRatesAndPayments() method that represents it's specific query.
What you see above is the base class I have. I made those two methods virtual as I plan on having subclasses override them to perform their own stuff. So one could be like:
public override void GetTranQuotesToFillRatesAndPayments(ref List<int> ids)
{
ids.AddRange(dataManager.GetLoanTranQuotes());
}
and etc. My question is, is this the best/cleanest way to perform a pattern like this?
The code that calls this is going to contain a huge list of filtered id's, that it's going to need to fill by calling each classes call to GetTranQuotesToFillRatesAndPayments(). Let me know if this doesn't make sense. I'm kind of getting turned off by the fact that I'm going to need to call the same method like 6 times, each on a different class. I think that might be messy in itself even though the goal of it was to make it clean. I don't want to have something like this on the calling side:
List<int> ids = new List<int>();
ScheduleRatesController controller = new LoanController();
controller.GetTranQuotesToFillRatesAndPayments(ref ids);
controller = new TradeController();
controller.GetTranQuotesToFillRatesAndPayments(ref ids);
etc.
Let me know if you need any more background or info.
Thanks.
Several design remarks:
Using the ref keyword usually indicates design problems and should be avoided. There is no need to pass a reference value using the ref keyword (any List<T> is always passed by reference). Your program would work equally without it.
A better idea than passing your list to the method would be to return your data from the method, and allow callers to decide what to do with it. Maybe you will only want to find a single value at some other place in your program, and creating a new list is an overkill. Also, you should try to add as little functionality as possible to each class (Single Responsibility Principle), and your class is right now responsible for fetching the data and deciding how it should be stored.
Naming: your method name is really complex. Also, the name "controller" doesn't usually represent an object responsible for fetching data.
On the other hand, you have a CoreDataManager class (btw, Manager is a bad suffix for any class), which appears to contain a bunch of methods which return various data. What is the need for ScheduleRatesController then? Does it only copy this to a list?
Business logic should be separated from your Data access layer. You should consider using Repository pattern, or similar (check this answer, for example), to ensure that your data class only fetches the data from the DB.
If you have several classes which need to fulfill a certain contract, start by creating the interface which they need to implement. Don't think about reusing code at this time. Your code, for example, forces all subclasses to use the CoreDataManager, while one day it may turn out that a certain "controller" might need to be composed of different objects.
Use a List<Func<List<int>,List<int>>>. Which is basically a list of functions with the following type signature:
List<int> MyFunc(List<int> foo);
You can then pass the list of functions to a method that works like the following:
public List<int> GetAllIds(List<Func<List<int>,List<int>>> functionList) {
var listOfIds = new List<int>();
foreach(var f in functionList) {
listOfIds = f(listOfIds);
}
return listOfIds;
}
You can use lambdas to compose functionList like so:
functionList.Add(list => {
list.AddRange(dataManager.GetLoanTranQuotes());
return list;
});
Now you do not have to depend on any specific inheritance hierarchy. You can use function composition to produce the whole list.
I'm currently struggling to understand how I should organize/structure a class which I have already created. The class does the following:
As its input in the constructor, it takes a collection of logs
In the constructor it validates and filters the logs through a series of algorithms implementing my business logic
After all filtering and validation is complete, it returns a collection (a List) of the valid and filtered logs which can be presented to the user graphically in a UI.
Here is some simplified code describing what I'm doing:
class FilteredCollection
{
public FilteredCollection( SpecialArray<MyLog> myLog)
{
// validate inputs
// filter and validate logs in collection
// in end, FilteredLogs is ready for access
}
Public List<MyLog> FilteredLogs{ get; private set;}
}
However, in order to access this collection, I have to do the following:
var filteredCollection = new FilteredCollection( specialArrayInput );
//Example of accessing data
filteredCollection.FilteredLogs[5].MyLogData;
Other key pieces of input:
I foresee only one of these filtered collections existing in the application (therefore should I make it a static class? Or perhaps a singleton?)
Testability and flexibility in creation of the object is important (Perhaps therefore I should keep this an instanced class for testability?)
I'd prefer to simplify the dereferencing of the logs if at all possible, as the actual variable names are quite long and it takes some 60-80 characters to just get to the actual data.
My attempt in keeping this class simple is that the only purpose of the class is to create this collection of validated data.
I know that there may be no "perfect" solution here, but I'm really trying to improve my skills with this design and I would greatly appreciate advice to do that. Thanks in advance.
EDIT:
Thanks to all the answerers, both Dynami Le-Savard and Heinzi identified the approach I ended up using - Extension Methods. I ended up creating a MyLogsFilter static class
namespace MyNamespace.BusinessLogic.Filtering
{
public static class MyLogsFilter
{
public static IList<MyLog> Filter(this SpecialArray<MyLog> array)
{
// filter and validate logs in collection
// in end, return filtered logs, as an enumerable
}
}
}
and I can create a read only collection of this in code by doing
IList<MyLog> filteredLogs = specialArrayInput.Filter();
ReadOnlyCollection<MyLog> readOnlyFilteredLogs = new ReadOnlyCollection<MyLog>(filteredLogs);
It sounds like you do three things to your logs:
Validate them
Filter them
and
Access them
You want to store the logs in a collection. The standard List collection is a good fit since it doesn't care what's in it, gives you LINQ and allows you to lock the collection with a read-only wrapper
I would suggest you separate your concerns into the three steps above.
Consider
interface ILog
{
MarkAsValid(bool isValid);
... whatever data you need to access...
}
Put your validation logic in a separate interface class
interface ILogValidator
{
Validate(ILog);
}
And your filtering logic in yet another
interface ILogFilter
{
Accept(ILog);
}
Then with LINQ, something like:
List<MyLog> myLogs = GetInitialListOfLogsFromSomeExternalSystem();
myLogs.ForEach(x => MyLogValidator(x));
List<MyLog> myFilteredLogs = myLogs.Where(x => MyLogFilter(x));
The separation of concerns makes testing and maintainability much better. And stay away from the singletons. For many reasons including testability they are out of favor.
The way I see it, you are looking at a method that returns a collection of filtered log, rather than a collection class wrapping your business logic. Like so:
class SpecialArray<T>
{
[...]
public IEnumerable<T> Filter()
{
// validate inputs
// filter and validate logs in collection
// in end, return filtered logs, as an enumerable
}
[...]
}
However, it does look like what you really wish is actually to separate the business logic in charge of filtering the logs from the SpecialArray class, perhaps because you feel like the logic touches many things that do not really concern SpecialArray, or because Filter does not apply to all generic cases of SpecialArray.
In that case my suggestion would be to isolate your business logic in another namespace, perhaps one that uses and/or requires other components in order to apply said business logic, and offer your functionality as an extension method, concretly :
namespace MyNamespace.Collections
{
public class SpecialArray<T>
{
// Shenanigans
}
}
namespace MyNamespace.BusinessLogic.Filtering
{
public static class SpecialArrayExtensions
{
public static IEnumerable<T> Filter<T>(this SpecialArray<T> array)
{
// validate inputs
// filter and validate logs in collection
// in end, return filtered logs, as an enumerable
}
}
}
And when you need to use that business logic, it would look like this :
using MyNamespace.Collections; // to use SpecialArray
using MyNamespace.BusinessLogic.Filtering; // to use custom log filtering business logic
namespace MyNamespace
{
public static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main2()
{
SpecialArray<Logs> logs;
var filteredLogs = logs.Filter();
}
}
}
Some thoughts:
As you correctly point out, using an instanced class improves testability.
Singletons should be used if (A) there is only one instance of the class in your whole system and (B) you need to access this instance at multiple different places of your application without having to pass the object around. Unnecessary use of the Singleton pattern (or any other kind of "global state") should be avoided, so unless (B) is satisfied in your case as well, I'd not use a singleton here.
For simple dereferencing, consider using an indexer. This will allow you to write:
FilteredCollection filteredlogs = new FilteredCollection( secialArrayInput );
//Example of accessing data
filteredlogs[5].MyLogData;
If your class only consists of a constructor and a field to access the result, using a simple method might be more appropriate than using a class. If you want to do it the fancy way, you could write it as an extension method for SpecialArray<MyLog>, allowing you to access it like this:
List<MyLog> filteredlogs = secialArrayInput.Filter();
//Example of accessing data
filteredlogs[5].MyLogData;
If you want to inherit the interface of SpecialArray for you final filtered array then derive from SpecialArray instad of having an instance member. That would allow:
filteredCollecction[5].MyLogData;
etc..