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
I have several classes that all implementing an interface:
interface ISample
{
}
class A:ISample
{
}
class B:ISample
{
}
class C:ISample
{
}
and another class that create them based on some situation for example:
class CreateISample
{
ISample Create(string situation )
{
switch(situation )
{
case "create A":
return new A();
case "Create B":
return new B();
case "Create C":
return new C();
}
}
}
What is the best name for this class?
Create ISample is not good, as then I have:
CreateISample.Create("Create A");
which has two Create as part of name. Also CreateISample may do some other things (for example hold some constant values that relates to all instances, or hold a list of created instances and so on). Then CreateISample is not a good name.
Is there any standard for this? I remember that I read a book about design patterns and they suggested a suitable name for this factory pattern.
you are describing the factory pattern http://en.wikipedia.org/wiki/Factory_method_pattern
generally the convention we use is SampleFactory
But don't overthink it. It's really hard to make names like this from samples. for example it is obvious to most people that a square inherrits from shape. so
ShapeFactory.Create("Square");
would make a lot of sense. so look at your problem to see what kind of thing ISample really is. If i makes sense from a business/problem side other programmers who understand the problem can figure it out.
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 4 years ago.
Improve this question
I am confused with these implementations .In an interview,interviewer asked me what is composition and I gave him typical definition then I wrote this part of code for him.
public class Foo {
private Bar bar = new Bar();
}
But he claimed this implementation is correct
interface IFoo
{
int DoSomthing();
}
class Bar : IFoo
{
public int DoSomthing()
{
throw new NotImplementedException();
}
}
Which one is correct?
Edit: I realize now that both you and your interviewer were correct; answer updated accordingly.
From the wikipedia page on Composition over inheritance:
Composition over inheritance...is the principle that classes should achieve polymorphic behavior and code reuse by their composition (by containing instances of other classes that implement the desired functionality) rather than inheritance from a base or parent class.
Polymorphism is
the provision of a single interface to entities of different types.
So what you did (having Bar be a property of Foo) is Composition because Bar has an instance of Foo through having it as a property.
What your interviewer did was also Composition because, through the interface IFoo, Bar implements the same functionality, and it didn't use inheritance to do so. This appears to be the way it's documented on the linked wiki page but doesn't mean your way is wrong either.
Which method you use for implementing the same functionality in different places would depend on whether it makes sense for Bar to be a property of Foo or not.
Composition denotes a "is-a-part-of" relationship between objects. For example,
class Engine
{
//....
}
class Car
{
Engine engine = new Engine();
//.....
}
we can see, Engine is-a-part-of Car. Composition and inheritance are two different concepts and you probably shouldn't accept a job offer where he would be your boss. :)
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
Imagine we have an interface like below:
public interface ISome
{
void MethodOne();
int MethodTwo();
string MethodThree();
}
A class implements the interface:
public class Some : ISome
{
// Implementation...
}
Here is how it may be used:
public class App
{
public App(ISome)
{
// This class needs the whole interface: All three methods
}
}
I have a new requirement and it only needs one method from it: MethodThree and it can use the implementation provided by Some. Now I have 2 options:
Use ISome in the new class, like App uses it. The problem with this is that the new class does not really depend on the whole interface but only one method.
Split the interface like this using inheritance:
public interface INewSome
{
string MethodThree();
}
public interface ISome : INewSome
{
void MethodOne();
int MethodTwo();
}
The benefits of the 2nd option are:
The new class will depend on INewSome
Some still implements the whole interface so existing code will not break.
Unit testing will be much clearer since we know we just need to mock/stub one method in INewSome
Questions
I cannot think of a benefit for option 1 aside from not having to introduce a new interface. Do you know of a benefit with option 1?
Do you have another suggestion?
Am I overlooking anything and is this good/bad design?
what you have done in the option 2 is correct and goes perfectly with the fourth goal which is Interface Segregation Principle
From Wikipedia many client-specific interfaces are better than one general-purpose interface
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
I have an interface:
public interface IMyObject
{
}
I have an abstract class:
public abstract class MyObject : IMyObject
{
}
And I have a class:
public class MyExtendedObject : MyObject
{
}
There are many interfaces, abstracts and concretes like this in my project. I wonder what is the best scenario to organize the code in namespace (folders in project) point of view. Should I put all related stuff under the same folder or should create, for example a Base namespace for abstract classes, Interfaces namespace for interfaces and another namespace for extended objects?
The best way is subjective and poject dependent.
Like a suggession I would say:
move in separate folder interfaces and abstract classes, so separate them from concrete implementation classes.
+ Absrtacts
-> IMyObject.cs
-> MyObject.cs
+ Concrete
-> MyExtendedObject.cs
Robert C. Martin (one of the founding fathers of Agile and now the Software Craftmanship movement) has a whole talk on that that is really worth watching
It's based on Ivar Jacobson's Object Oriented Software Engineering: A Use Case Driven Approach.
To summarize it in a few sentences, your project structure should reflect what it models and not the technology or particular language constructs you use. In the case of your abstract/interface/concrete classes this means that using a structure where you put all your abstract classes in a folder/namspace/assembly, your concrete classes in another folder/namespace/assembly is not the way to go (even though it is very common to find projects where this approach is taken).