It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have an utility library with the class ConsoleApp, which has only static method like GetIntValue(string name) to ask user to enter the integer value of the parameter with specified name, or functions to parse command line parameters.
As for me ConsoleApp is an utility class, and inheriting it just to get avoid "ConsoleApp." in the code looks like BaseBeen anti-pattern.
But on the other side, ConsoleApp will be inherited only by the classes that is really Console applications, in this way, it's not a BaseBeen.
So, is it really BaseBeen?
SOLID design principles (particularly SRP, O/CP, and DIP) suggest that you're better providing that functionality via delegation (e.g. strategy pattern). Has-A is better than Is-A, etc.
However, you're pretty squarely in first-world-problems territory here because Program.cs is very much on the transient end of your codebase. Clearly you might need to parse some command line parameters before your bootstrapper runs (e.g. to configure your bootstrapper!), so you might find it challenging to inject some kind of value provider.
So, I'd say yes it's an antipattern, however there are probably more important things to worry about.
See e.g. http://s3.amazonaws.com/hanselminutes/hanselminutes_0145.pdf page 8 where Uncle Bob talks about DIP:-
"Main is the most concrete of our
functions and it will create all of our instances and all of the
factories ... and it will then
hand off to the abstract part ... and the
abstract core will manipulate it as though it were in this fantasy
world where everything was abstract."
If Main has to call some static methods, that's ok. If you want to inherit from a utility class to make it easier for you, that maybe smells a bit but I don't really care. Just make sure you know where the boundary is. If you're using your static utility class outside of Main then you're likely to have a problem.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have read that reflection is particularly useful when dealing with plugins. Could someone kindly highlight the benefits in this particular situation? Both in C# or Java.
"At the highest level of abstraction, the host application must be able to load plug-ins and then communicate with plug-ins to take advantage of their designed services. Both of these tasks can be implemented in different ways depending on a developer’s choice of language and platform. If the choice is C# and .NET, then reflection can be used for loading plug-ins, and interfaces or abstract classes can be used as a means for generic communication."
If you Google some of that you can see the article and read some more on it.
Why don't you just Google it?
In case of .NET you can use an interface to create a basic layout of a plugin. Let's call it 'IPlugIn'. Then you load an Assembly with a class implementing IPlugIn. Now you can look through all the types if one is derived by IPlugIn or define Attributes on the assembly to indicate which class is a plugin.
In my opinion you do not need to rely on reflection for plugin implementation. I'd suggest using usual interfaces and services. Define some interfaces for your plugins to implement and let them consume the services that will help them integrate with the framework you want to provide them.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Interface should be used when none of the implementation details are available to the current scope of the code.
Abstracts should be used when some of the implementation details are available to you.
Query - Why still these terms are required? Why can't Business objects directly communicate with DataAccess.SqlServer Layer?
Interface should be used when none of the implementation details are
available to the current scope of the code.
Not really. What you're referring to is encapsulation. There is the concept of "information expert." Only the class that knows how to do something should be the one doing it. Interfaces are used for polymorphism and decoupling. When consuming code wants to treat certain types of objects the same way, that code can use all of those objects the same way by treating them as the interface type.
Abstracts should be used when some of the implementation details are
available to you
I'm not sure what you mean here. I think you're confused because this doesn't sound right. Abstract classes are used the same way interfaces are, except that they're allowed to have implementation in them.
Query - Why still these terms are required? Why can't Business objects
directly communicate with DataAccess.SqlServer Layer?
They can, but at the cost of maintainability, flexibility, and testability. If you want to replace your data layer with another, you can't because the consuming code has a direct dependency on the current data layer. If you want to unit test your logic, you can't without hitting the DB. If you put your database classes behind an interface, you could mock the data layer in unit testing and test your logic classes without hitting the database.
Very Short Example
public Foo FooLogic
{
IFooData fooData = DataAccessFactory.GetDataClass<IFooData>();
return fooData.GetFoo();
}
Now your logic class isn't tied to a particular data class. The factory can return a real FooData implementation, or it can return a mock data object, or a new data access layer can be put in place without affecting the code in the logic class.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Is there a good practice to split part of complex method's functionality to several smaller methods only in terms of good code readability (but maybe paying some performance for methods calling)? Or this is some kind of "bad style"?
The very basic rule is that your method should do only one thing. If you detect that is doing many different things, then you have a clear refactoring oportunity.
If you reach the point where your method has a single responsability but the size is too long anyway, try to extract "helper" functionality to separated methods. You might even detect code that can be promoted to separated classes.
TDD development is a great methodology to avoid this kind of issues since it really helps to clearly separate concerns and to avoid a bunch of code on single methods just for the sake of testability. If you don't write concise methods, it becames too hard to test them properly.
If you think about reusing code (The DRY principle), you should consider refactoring. Split the method content into different small module based on the functionality so that it can be reusable. Ex : If you have a method which saves a customer registration details and create a new order for him. you could probably check that many methods like CheckUserExist, SaveUser and SaveOrder. You should be able to reuse this functionalities in other areas of your code as necessary. Splitting it into modular pieces makes your code more readable too.
Unclebob (Robert C. Martin) considers that methods should be no larger than 4-5 lines of code. His motto, concerning this, is "Extract till you drop". Personally, i believe this is a very good practice.
Visual Studio allows you to extract a method by pressing CTRL+R, M.
in addition to Claudio's answer, there are some SMELLS that if detected, it means that you have to refactor and split your code.
1- non-DRY code: if you find yourself copying/pasting some lines into more than one place, this is a bad smell that needs to be placed in a center placed, and to be called from as many as it should be.
2- Methods with hundreds of lines: any good method should not exceed 50 lines of code, maybe more or less than this number, but rest assured that this method of 346 lines is not a good thing to do.
3- Too many parameters: a long list of parameters in your methods make readability and code quality worse.
4- code invasion: Methods that are using many blocked from another class, should exist inside this class.
Hope that helps.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
What is the use of interface in projects except the use of loosely coupling?
Does it reduce memory usage while passing it as argument?
Please list the advandages deeply.
I think you should have look to oop example and specially Design pattern whihc help you to understand why to use interface..
Another important advantage to programming to interfaces is that it provides a means for polymorphism. If I have a collection of IShape and IShape provides a CalculateArea() method, I can supply a new shape to the project by adding a new implementation of IShape. So, yes, this is providing looser coupling by virtue of adhering to the open/closed principle. But, it's also allowing IShape to be treated abstractly by clients without needing to know which specific IShape it is.
Polymorphism is fundamental to object oriented design, and an interface is a way to achieve that (the other being inheritance).
I'd also throw in that interface implementation tends to be expressive in terms of code intentions. If I have some declaration like:
public class Foo : IDisposable, IPersistMyselfToDisk, IRaiseUpdateEvents
I can tell a lot about the class and what it does at a glance -- more so than I could if I simply buried that functionality somewhere in the details of the class. Again, this goes back to decoupling to some degree, but it stands on its own as well.
I think you're going to find that decoupling is wrapped up with just about all advantages of using interfaces since providing classes that are cohesive and loosely coupled is just about as fundamental to OOP as having classes with state and behavior.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I came across one issue as to how to package interface, interface client and inheritance. That is, in the book below, author mentioned that Switachable is more appropriate to deploy with Switch together as a component, rather than Light.
What I want to understand is the reasoning behind it (Both Switch and Switchable are packaged in one component, rather Switchable and Light) , and example if possible.
I think there are cases where both scenarios are valid. One example that is oppoiste of that design is, IStream, FileStream are in one component, ISream client is in another component.
Below is from unclebob's agile in C# ch 33, p497.
Since Light inherits from Switchable, it could also be deployed with Switchable - it seems, however, due to the naming, that the primary class interacting with the Switchable interface will be Switch - which means that the two are tightly-coupled: you should never put tightly-coupled class/interface definitions in separate assemblies.
You could also conceive of other Switchable classes, such as Outlet or a whole set of Appliances. These could be added at a later date, and they would have nothing to do with Light, meaning that Light and Switchable aren't necessarily part of the same component. However, the Switch class would still apply to these new classes and would apply.
(It is true that a different consumer of the Switchable interface could be conceived, but it would likely be an awkward adaptation, such as a ToggleButton that toggled the on/off state by remembering the last method called. However, with the names chosen, Switchable still implies that a Switch could be involved.)
I hope this answers your question.