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 9 years ago.
Improve this question
Apart of the atypical reasons to have classes with hundred members (eg DAO pattern to access hundred objects), what would be the best approach: Have only one class with all members or instead hundred of partial classes each one with one member ?
One partial class for each member looks nice because it facilitates the construction of automated solutions to insert and delete members, just creating or deleting files (classes).
Does C# or something in .Net limit the amount of partial classes ? What about others performances or resources consumption at design time or compilation, supposing that at runtime the two alternatives are the same ?
DETAILING A SAMPLE:
Databases with hundred of objects that need to be accessed from a DaoFactory (DAO pattern) would typically has one member to each object in the database. We aren't discussing the business behind that, why this system has and how it works, but we have a situation, and all objects need to be "exposed" by a DaoFactory. Of course, multiple DaoFactories grouping the objects can minimize its size (amount of members), but only if the division consider all possible relations between them, so all possible of database transactions combined among them to group them.
So, supposing that we cannot divide this DaoFactory, we have a class with hundred of members, and partial classes is an alternative like the one I asked, to have a kind of tool that can maintain it just creating or deleting partial class to each member.
That's not what partial classes are used for. Partial classes are supposed to be used when you do not want to touch the code in the main class. A very good example is the code generated by EF.
Or, when a couple of developers want to work on the same big class. They each develop part of the class as a partial class.
But, you don't divide a class into partial classes just because the class is big.
What would be the point of a class with a hundred, quite likely unrelated members.
If your're going to be generating code, as it appears you might from it facilitates construction of automated solutions... to do data access, create an abstract class or classes, possibly (likely, in fact) generic that implements the common functionality required.
Have your code generator construct suitable concrete instance of the same.
This approach works for manual construction as well.
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 5 years ago.
Improve this question
I've seen a lot of different coding patterns over the last several years, and I was struck by vast differences between different shops and programmers. At my previous employer, nearly every single class had a defined interface, even if only a single class implemented that interface, and the interfaces were used as parameters instead of the classes themselves.
At my current employer, interfaces are practically unheard of, and I don't think I've ever seen a custom interface ever defined. As such, classes are pretty much exclusively passed around.
I understand that interfaces are a contract that defines what members and functions a class will implement, but are there any real reasons to define interfaces for some/most classes that will never share similarities to other classes?
For example, most of our operations are simple CRUD actions. While we handle reporting and other tasks, nearly every operation is either some sort of insert, update, delete, or select. Our data models tend to be pretty similar to our database structure at their base level. As we move higher through the application layers, we may combine or alter certain objects to contain related properties, but everything is pretty linear.
I'm just having a hard time seeing why interfaces would be such a good thing to implement in our situation, whereas my last company heavily relied upon them.
The primary benefit to all classes implementing an interface and then passing them around is that it greatly increases the ease of mocking them for unit tests.
If you always pass concrete classes around, the mocks have to derive from them. If they don't have virtual members, the mocks cannot override any behavior, and even if there are virtual members you may get side-effect code from the base class that you don't want in that environment.
None of these problems exist with interfaces, clean mocks are very easy (especially with a framework like NSubstitute). The interfaces also allow for implementing various patterns like Strategy, and help support the Open-Closed Principle (among others).
Granted, an interface for every class can seem to be a bit overkill, but at least interfaces around every process-external facing class is an excellent practice.
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 6 years ago.
Improve this question
Good Morning,
I am working on WindowsForm. I came up with 2 solutions. I wanted to know which solution is good practice to follow?
Solution 1:
I have a written a common static methods for validation like phone-text box, mandatory_textbox-key press etc.I have many common methods like this. So what i did is i created a utility class and placed all these static methods in it. Then used these methods across the application.
Solution 2:
i got an idea, so what i did is i created a baseform-inherited Form class, Then i inherited this baseform in all the other forms(Multi-level inheritance).
In the baseform i moved all the validation methods from Utility class and made then non-static.
I also taught about UserControl. If i do that i have work with the alignment tasks again. So that only came up with the two solutions
So Can you suggest which to follow?
You can move the static methods inside non static classes, and pass concrete objects (maybe through interfaces) to the classes/methods who needs that functionality. This way you keep your code easy to test, and decoupled.
By example if you have a class PhoneNumberValidator implementing the interface IValidator which have a method bool Validate(string phoneNumber), and pass it where you need to validate a phone number.
I guess this wuould be the best practice to have a decoupled application.
There in no straightforward answer on whether one should declare methods as static or not. It depends on the context and functionality of your application.
Going with some assumptions for your situation, consider following thoughts on high level -
If the validation is related to one particular form only, and not applicable for other forms, declare it within your form class ans private method. If these validations do not require any class instance, you may declare them static.
If some validations are common for different form, you may declare them as static. Do take caution and do not pass controls to these methods, instead pass the values that you want to validate for better design.
Consider declaring validations in base form only if those are applicable to all or if not most of the forms, and again, if they do not use any instance object, you may mark them as static
A good discussion here.
Use User Control instead of a separate form, if these common controls are being used in every form. Static methods are supposed to be used for utils kind of requirements.
Some times ago I tried to use both solution described by you for different tasks. Every of this have own pluses and minuses.
So, in first case we have only one ststic class and one implementation of every static methods in memory. We can apply this methods to any quantity of other object instances. But we need access this class in every namespace where we will use it.
So, if we will make some changes in any code of this class, it will be applied to all object instances related this class. Sometimes it's convenient, sometimes not.
In second case we will got new instance of base form in memory (less efficient), but we also have one base implementation of methods for inherited forms like first approach. As additional benefit we always can override methods for special cases (if it's needed) for some specific instances only.
In any case, only you can make right decision based on your task context.
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 have a certain class Thing, and an interface that it implements, named IThing. Everybody who uses IThing can presume that it's really a Thing, since it's the only class which implements this interface, but at the same time he understands that he can only access a certain subset of the public members of Thing, and there's a pretty good design reason for this — basically, IThing is a read-only version of Thing (it's a little bit more complex than that, but let's pretend it's just read-only/write distinction for the sake of the question).
Is it a good convention though? As an alternative, I could name this interface IThingReadOnly or name the class ThingWritable, or something like this, but it seems that these names would be bulky and less readable in a big codebase.
I also use extension methods extensively for both interface and class, so I have ThingExtensions and IThingExtensions as well. It's very useful, because everyone who reads the code of this extensions can operate from an assumption that it only uses public members of Thing and IThing, respectively. However, having both ThingExtensions and IThingExtensions files sitting alongside in a project seem a little bit off for some reason.
So, which one is a better option — to keep Thing and IThing alongside, or to rename one of them?
Update about close vote:
This is an opinion-based question, because it's question about best practice — but it's not a primarily opinion-based question (please mind the distinction). SO has a lot of great question and answers about best practices, so I think that either there's a difference between this question and other best-practice question that I don't see, or this question has just the same right to exist as any other best-practice question.
First off I´d suggest using extension-methods just for types you do not have control on, e.g. the .NET-types like IEnumerable. However you may consider create two different interfaces, one base interface for reading (let´s call it IThingRead) and another one that represents your actual Thing-type (IThingWrite) with some write-modifiers.
Anyway creating an interface for every class is good practice and eases testing by mocking up some uof your types.
If you're sure that you will not need another implementation of the interface and you don't need to mock the interface for test purpose, you can simply remove the interface and use the concrete class.
Otherwise keep using IThing and Thing (this is the normal naming convention).
I would create only IThingExtensions though
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
I am trying to restructure an application, and right now there are two classes which are subclasses of another class.
Both of these classes have a method. This method essentially does the same thing (get user information) but from different data sources and parses them differently (say one uses the Facebook API and the other a database). They also take in different parameters.
Does it structurally make sense to leave both methods in the subclasses with the same method name? Or is there a cleaner way of organizing the methods within the subclasses?
Even though both methods are logically GetUserInfo, it is also correct that one is logically GetUserInfoFromFB and the other GetUserInfoFromDB.
You could create an abstract GetUserInfo method, but since the methods get different parameters, it could easily get messy. It is easily feasible, however, if the parameters can be logically refactored as properties of the subclass (or properties of logical class to hold them together, that being a property of the subclass).
Edit: The strategy pattern is applicable here, but is what I would consider "messy". Your case as you presented it is small in scale, so the the strategy pattern just might be an overkill.
tl;dr If you do not think your case justifies the strategy design pattern, it is perfectly fine to leave it as it is.
This is a perfect place to apply the strategy pattern.
Rather than having a different GetUserInformationMethod call for each class, create a new class (or a delegate type) that exists just to get user information. Have a UserInformationGetter attribute which is an instance of your user information fetching class/delgate in the base class, and have the base class's GetUserInformation method invoke the delegate/class to get user information.
The challenge of different parameters could be handled in a number of different ways, which depends on the parameters. If the parameters are related to the details of implementation (e.g. database connection strings), and not variant across users then you should tie that information to the UserInformationGetter class.
If the information is dependent on the user, there are a number of strategies. I would suggest you create a type that encapsulates all the information about the user that is used to fetch user data in either case. Then you can pass this object to the methods, rather than parameters that vary accoridng to the method of data access.
This way, you can vary the user information fetching strategy of your base classes independently of anything else which might vary between the classes. Additionally, you can vary the way you get user information at runtime, allowing your program to adapt to changing requirements easily.
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 8 years ago.
Improve this question
My application is mainly composed of Campaigns. They are the main object of my model.
I have two types of campaign:
Ad hoc: Campaigns that are run once immediately
Scheduled: Campaigns that are scheduled for future and can be run multiple times according to their schedule.
There are shared attributes between these two and there are attributes that are specific to each. What is the best way to design this data model? Interfaces or Abstract classes?
Let's say both types of campaigns can have an Id and a Name and:
Only Ad hoc campaigns have a DataTable called Recipients
Only Scheduled campaigns have a List<DateTime> called Schedule
If you're kind enough not to vote me down or ask to close this question, please provide a basic structure of your recommended model including access modifiers and the abstract/virtual or another keyword that will help me have a better structure for my model.
This is very difficult to answer without a very good understanding of what you're doing and it is unfortunately very opinion based.
However at a very simple level if you use an interface you will often have to duplicate code between the implementing properties (methods, properties and so on). A base class provides this functionality to them. For this reason I often use a base class unless there's a specific reason why an interface is more appropriate.
I would suggest different types of campaigns are all campaigns in essence and so have a base class. However they will target different entities (people, charities, companies) which will all need a way of contacting them (email/phone/address) I'd suggest that these unrelated entities (beyond the fact they can be targeted by a campaign) are a better example of when to use an interface.
However you will need to think about which methods you would override and which is the cleaner solution.
Generally speaking, if they share common behavior (code), that code should exist in an abstract class. If they perform the same role, put them behind an interface.
In your case you seem to have two shared properties, both a simple value, which does not really define behavior, so just based on those properties I'd go for just an interface.
If you do decide to create an abstract class (perhaps there is some code both types would like to share), you could still keep the interface. You could some day have a third campaign type that does not share behavior with the other ones (so does not implement the same abstract class), but does perform the same role (so does implement the same interface).
As for access modifiers in an abstract class, if both classes share only two properties, you just define them in the abstract class without abstract or virtual keyword.