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.
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
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.
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 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 3 years ago.
Improve this question
I like the DI feature of ASP.NET Core, but am finding that some of my classes end up with huge constructor parameter signatures...
public class Foo {
private IBar1 _bar1;
private IBar2 _bar2;
// lots more here...
public Foo(IBar1 bar1, IBar2 bar2, lots more here...) {
_Bar1 = bar1;
_Bar2 = bar2;
// ...
}
public DoSomething() {
// Use _bar1
}
}
In case this looks like a code smell, it's worth pointing out that any controller is going to use AutoMapper, an email service and 2 or 3 managers related to ASP.NET Identity, so I have 4 or 5 dependencies before I start injecting a single repository. Even if I only use 2 repositories, I can end up with 6 or 7 dependencies without actually violating any SOLID principles.
I was wondering about using a parameter object instead. I could create a class that has a public property for every injected dependency in my application, takes a constructor parameter for each one, and then just inject this into each class instead of all the individual Bars...
public class Foo {
private IAllBars _allBars;
public Foo(IAllBars allBars) {
_allBars = allBars;
}
public DoSomething() {
// Use _allBars.Bar1
}
}
The only disadvantage I can see is that it would mean that every class would have every dependency injected into it via the parameter object. In theory, this sounds like a bad idea, but I can't find any evidence that it would cause any problems.
Anyone any comments? Am I letting myself into potential trouble by trying to make my constructor code neater?
What you're describing sounds like the service locator pattern, and while it seems tempting to simplify your code by eliminating all those constructor parameters, it usually ends up hurting maintainability in the long run. Check out Mark Seemann's post Service Locator violates encapsulation for more details about why it should be avoided.
Generally, when you find yourself with a class with dozens of constructor parameters, it means that class might have too many responsibilities. Can it be decomposed into a number of smaller classes with narrower goals? Rather than introducing a "catch-all" class that knows about everything, maybe there's a complex part of your application that you can abstract behind a facade.
Sometimes, you do end up with large coordinator classes that have many dependencies and that's okay in certain circumstances. However, if you have many of these it's usually a design smell.
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;
}
}
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.