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 4 years ago.
Improve this question
I want to create an application that maintains a list of Computer objects, checks those objects for availability (using Ping) and if they're available use PSExec to add or remove users to/from the list of administrators.
Currently I can not figure out how to build my classes - which class should be responsible for what (I want to use the common patterns, such as SRP, as good as possible without "overkilling" it.).
When looking at the availability-check, should there be an "extra" class doing the ping request or should this be done by the computer object (instance) itself? If an extra class should be used, how should the computer (and other) object(s) be notified about the changed availability? With a Property?
Tho thoughts regarding this kind of stuff drives me crazy and prevents me from getting any further...
I know there is no correct answer as this is obviously a design and opinion question but I'd appreciate it if I could get an experts opinion here - hopefully this brings me back on track.
Hi I have come up with the following according to the description provided. The Computer class is adhering to SRP as it is only concerned with Computer objects. All the operations are delegated to specialized classes. Currently I have added only a class to check availability. We can also add a specialized class for adding removing users.
Open for discussion and refinement.
public class Computer
{
// properties of the computer class
public IList<User> Users;
// IAvailabiity checker
private readonly IAvailabilityChecker _checker;
// constructor
public Computer(IAvailabilityChecker checker)
{
this._checker = checker;
}
// operations
public void AddUser()
{
if (this._checker.IsAvailable())
{
// add user
}
}
public void RemoveUser()
{
}
}
public class User
{
}
public interface IAvailabilityChecker
{
bool IsAvailable();
}
public class AvailabilityChecker
{
public bool IsAvailable()
{
// availability checker logic
return true;
}
}
Related
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
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.
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 5 years ago.
Improve this question
I'm trying to improve my coding standards by implementing interfaces and abstract classes when necessary, however I would like to ask about practises regarding abstract classes.
I'm creating a web application and one aspect of the site I need to do some data processing, I have created an abstract class and it looks something like this.
public abstract class TestAbstractClass
{
public abstract void doDataProcessing();
}
And I need to implement this 'doDataProcessing' method a few times throughout the application dependent on where the user is on my site, it will do VERY similar data processing, just with one or two different things.
For example:
User is on certain page:
public Page1Class: TestAbstractClass
{
public override void doDataProcessing()
{
//do data processing
}
}
User is on another page
public Page2Class: TestAbstractClass
{
public override void doDataProcessing()
{
//do data processing but with slight change
}
}
User is on another page
public Page3Class: TestAbstractClass
{
public override void doDataProcessing()
{
//do data processing but with another change
}
}
Would this be best practise? Or is it better just making one class, and just doing various conditional statements on what is being passed into the 'doDataProcessing()' method?
I feel if I do it using the method I have posted, I will be having a lot of duplicate code in these 3 classes, is that OK?
I hope this makes sense.
This feels like you need to decompose the solution a bit more. doDataProcessing sounds like it is something that could be broken into smaller pieces. There are high-level design patterns that could help you structure this.
If doDataProcessing is a similar thing but with small changes, then look at the Strategy pattern or the Decorator pattern.
If you are not going to have any implementation in the base doDataProcessing then just go with an interface as #phuzi recommended. Abstract classes are best used if you have some logic that is exactly the same in most cases, and in odd scenarios you can override and/or extend the base logic in the inherited classes.
EDIT
From the information you gave me I would probably do the following:
public abstract class TestAbstractClass
{
public void Process()
{
MethodThatGetsCalledEveryTime();
doDataProcessing();
}
public virtual void doDataProcessing()
{
// can add frequent logic here
}
protected void MethodThatGetsCalledEveryTime()
{
// do stuff here
}
}
this way you can ensure that the "MethodThatGetsCalledEveryTime" will always be called, and if you add additional logic to doDataProcessing that will run as well from the appropriate place.
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 7 years ago.
Improve this question
If object oriented programming is focused on objects, which consist of methods and data, what is the best OOP-focused approach to working with databases, using C#?
For example, I want to log something using C# classes, and record the logs in a SQL table. All other factors being neutral, would it be more "proper," object-oriented speaking, to do:
Create a class for what's being logged, and include methods for database access
(The methods are tied closely to data)
public class Activity
{
public string ActivityProperty { get; set; }
public void SQLMethod1() {}
public void SQLMethod2() {}
}
...or,
Create a class for what's being logged, and create a class for database access
(Methods are not closely tied to data, but the way data is accessed is treated itself as an object, i.e. referencing EF or another ORM)
public class Activity
{
public string ActivityProperty { get; set; }
}
public class SQLMethods
{
public string SQLProperty { get; set; }
public void SQLMethod1(Activity activityParam) { }
public void SQLMethod2(Activity activityParam) { }
}
...or, perhaps a better design would be more "object-oriented"?
Generally speaking, I prefer not to put database access logic into classes because it hinders your ability to use them in other scenarios in which data access is not required. So I think your second option is the more flexible one.
However, if you are already aware of ORM solutions such as Entity Framework, I would suggest using one of those. EF takes an approach closer to your second one in which you use POCOs (plain old C# classes) and other EF classes take care of moving data from those objects into the database and back.
So overall my suggestion would be to use Entity Framework with the code first methodology.
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 8 years ago.
Improve this question
I am working with C#.NET and basically have a page containing many areas.
In my code-behind, I basically want to be able to do something like:
bool result1 = MyClass.Section["area1"].Process();
bool result4 = MyClass.Section["area4"].Process();
I need to write a class that would call some kind of "Process" method and be able to have it accept a parameter like "area1" inside that method.
Any help on getting me started with this would be greatly appreciated, thank you!
Following the normal .NET naming conventions I'll assume you mean, by your example, that MyClass is being referenced statically rather than by instance (which may not be a big change). Given that assumption, it appears you have a class like:
static class MyClass
{
public static IIndexer Section { get; }
}
IIndexer in this case could be any type that implements an indexer property that takes a string and returns a type that has a method named Process which in turn returns a bool. IIndexer could theoretically look like:
interface IIndexer
{
ISomething this[string] { get; }
}
Next we'll fill in the ISomething blank above with a simple IProcess interface so we don't have to know anything about your specific implementation:
interface IProcess
{
bool Process();
}
So now the indexer above can be changed to:
IProcess this[string] { get; }
Of course, none of the above has any real executable code, but outlines the objects necessary to do what you're after. Now when you go to run your code using your fulfilled contracts the call chain is pretty simple:
bool result1 = MyClass.Section["area1"].Process();
// MyClass.Section > IIndexer.this[string] > IProcess.Process
To POC the idea, a good way to mock the IIndexer implementation might be to use Dictionary<string, IProcess> as it'll give you a usable indexer for your purposes.