|
Its been discussed everywhere that a class cannot inherit from multiple classes but can implement multiple interfaces. My question is how many interfaces can be implemented on a single class?
Shouldn't a class have a single responsibility? In case of multiple interface implementation, doesn't it allow classes to have multiple responsibilities?  What exactly is the idea behind classes going for multiple interfaces and implementing them all on a class? What number of interfaces is good or is bad? (Though "number" may not have a meaning here, I mean to ask what goes into deciding that a class should/shouldn't implement an interface) 
Any help in this area from anybody shall be of great help. 
|
|
|
|
|
There is no limit to how many interfaces a class can implement.
It clearly depends on your requirement.
The class gets complex with each additional interface implemented.
Allowing multiple interfaces to class gives us some benefit of being robust and scalable.
Practically, a typical class implements one or two interfaces. but, again it depends on what you want to achieve.
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
Ravi Sant wrote: There is no limit to how many interfaces a class can implement.
I seriously doubt that.
Everything on a computer has a limit.
|
|
|
|
|
yes practically everything has limit, but if limit is very huge, compare to practical requirements
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
This is a good question. I guess the answer is that the 'single responsibility' principle is at a somewhat higher level than interfaces, many of which specify a behaviour and not a 'responsibility' as such. For example, would you consider INotifyPropertyChanged or IEnumerable<T> to be 'responsibilities'? I wouldn't, I'd say they label the class as having particular behaviours but tell you nothing about what the class actually does.
Another case where it can make sense is where you have a class (or an aggregate class with references to several others) whose responsibility is as a data store. This could be auto-generated from an entity management framework or just in-memory classes. You could specify several interfaces on it for different ways of looking at the data – typically, at least, some of those classes will be enumerable, but you could also create custom interfaces for domain-specific things that you want to be able to do with data. For example let's say you're writing a graphics library, and you want graphs to draw series, you might have a ISeriesDataProvider, and it would make sense to make any of your data storage classes that wrapped a list of numbers implement that. The responsibility of that class is not to provide numbers for a graph – it's still to store the data – but it is a useful behaviour.
So your primary thinking is correct: you should only inherit from one 'responsibility provider', whether that be a class or an interface. (Sometimes you inherit from none and write the responsibility into this class, of course.) But you can implement any number of 'behaviour decoration' interfaces.
Defining the difference between 'responsibility provider' and 'behaviour decorator' is quite tricky but a good clue is that behaviour decorators usually have only a small number of methods or properties, and what those methods/properties do (and are called) is generic, not domain-specific. For example IEnumerable has one method, INotifyPropertyChanged one event, and my hypothetical ISeriesDataProvider has one property (the data), and the names of those single entities tell you nothing about the rest of the class. IEnumerator has three, which are quite general; I'd consider it a borderline case based on that, though because we know what it is, it is clearly a responsibility provider (an enumerator is there only to enumerate). IList has several and most of them have list-related names (add, remove, etc), so it is clearly a responsibility provider, and you shouldn't generally implement it unless your class is primarily a list.
Note that I just made up the terms 'responsibility provider' and 'behaviour decorator' in the process of writing this post and they may have proper names which I'm not aware of.
|
|
|
|
|
@BobJanova
Thank you very much for replying to my question. 
The main problem I was facing, as you rightly pointed out, was in distinguishing the meaning between responsibility and behaviour and hence couldn't tell if I can implement interfaces IA to IZ on a class without affecting its responsibilites. Through your terms "responsibility provider" and "behaviour decorator" I now understand interface implementation clearly. Thank you very much for the help. 
|
|
|
|
|
goodpeapul wrote: Shouldn't a class have a single responsibility?
Generally, an interface represents a lightweight "behavior" (that is independent of other behaviors) while a class represents a heaver weight "provider of services" (with potentially predefined methods operations). So it's perfectly acceptable for a class to implement several interfaces while still having a single overall responsibility.
/ravi
|
|
|
|
|
Thank you very much Ravi Bhavnani. The information you have provided here was useful to me.
|
|
|
|
|
goodpeapul wrote: My question is how many interfaces can be implemented on a single class?
In my humble opinion asking "how many" is not quite the right focus on the broad issue of why and how to use Interfaces.
Clearly Interfaces can have multiple uses:
1. to enforce an implementation contract on implementers of an Interface. That "contract" forcing you at compile-time to deal with failure to 'meet the terms of the contract.'
2. to encapsulate "shared behavior" used consistently across implementers of the Interface.
3. via casting instances of Interface implementers to the Interface: to expose a limited subset of functionality, or content, of the instance to other Objects.
4. via discriminate use of implicit and explicit Interfaces to obtain the advantages of all of the above while avoiding semantic confusion, or overlap.
imho the idea of "single responsibility" is as applicable to a set of behaviors (methods, functions), as it is to classes.
Interfaces are one tool to help achieve that.
It may be of interest to you to read Erich Gamma's comments on interfaces here in this 2005 interview:[^]: scroll down to the section titled "Program to an interface, not an implementation."
From a humble student of Interfaces and their strategic uses.
best, Bill
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." Bjarne Stroustrop circa 1990
|
|
|
|
|
I am working on a C# WPF application that makes use of the OpenNET CF Desktop Communication library. My program waits for an Active Sync connection and uploads a small EXE. The EXE gets the device manufacturer and model and writes them to text files. I then copy those text files back to the desktop PC to grab that data. I wish I knew how to run those over a socket, but that's for another day. I would like to create a separate thread so that I don't block the main UI. This separate thread must NOT complete until it detects that the EXE I uploaded has finished and created the text files. I would like to have it essentially sleep for 1 second and check, and if it gets to more than 5 seconds alert the user that an error occurred. The problem I'm having is figuring out how to sleep the thread. I'm using a while loop that runs so long as those text files are not present. Once I go into a while loop, all variables are local. As a result, I cannot access the DispatcherOperator so I can invoke the sleep in the form of a 'Wait'. In place of it I am currently sleeping the main thread, but this blocks the UI. How can I achieve the effect of this separate thread waiting for the text files to be output by the EXE I uploaded to the mobile computer, but also not blocking the main UI?
<pre lang="c#">
private void MonitorOEMInfoProcess()
{
System.Threading.Thread MonitorThread = new System.Threading.Thread(
new System.Threading.ThreadStart(
delegate()
{
System.Windows.Threading.DispatcherOperation dispatcherOp = Dispatcher.BeginInvoke(
System.Windows.Threading.DispatcherPriority.Normal,
new Action(
delegate()
{
while (!m_rapi.DeviceFileExists(@"\Application\OEMName.txt") || !m_rapi.DeviceFileExists(@"\Application\OEMVersion.txt"))
{
System.Threading.Thread.Sleep(1000);
}
}
));
dispatcherOp.Completed += new EventHandler(dispatcherOp_Completed);
}
));
MonitorThread.Start();
}
|
|
|
|
|
I may be totally wrong at this but it looks like you're starting a background thread via
new Thread(ThreadStartDelegage). That's fine so far.
But the background thread itself wraps its work in a Dispatcher.Begininvoke() so that it actually runs, and Sleep()s, in Dispatcher's thread. This can or can not be the main thread, depending on how you created Dispatcher.
Ciao,
luker
|
|
|
|
|
I'm not sure which method to use (dispatcher or not). All I do know is that I need the process to run asynchronously from the main thread and to not block the UI while it checks for the presence of those files on the mobile computer. I have another glitch with it: the files may already be present on the device from a previous run, and so just checking for the presence of those files is a bad idea. What I really need to check for is if the EXE that I kick off on the mobile computer is finished, and that the text files that it writes to are available. There are some instances where I try to copy the file back to the desktop PC and the RAPI service can't copy it because the process running on the mobile computer still 'owns' it. Since there isn't a way for me to monitor that process directly, I've decided that sleeping for 5 seconds is enough. I want that sleep, however, to be asynchronous and not blocking the main UI. When a device connects and ActiveSync brings up its windows, I want to minimize them. If those windows are over top of my application and I minimize them, the sleep is currently blocking the UI and so the UI window shows remnants of those ActiveSync windows until the sleep finishes and the UI updates again.
Regards,
Scott
|
|
|
|
|
You have BobJanova's answer that does the file lookup in a separate thread without blocking the UI.
But regarding the other problems you mention, I suggest you should think again if it's worth developing the file handling way. You already mentioned that in the long run you would rather choose a socket-based communication. Maybe now is the time to get that version going.
Ciao,
luker
|
|
|
|
|
private void MonitorOEMInfoProcess()
{
System.Threading.Thread MonitorThread = new System.Threading.Thread(
new System.Threading.ThreadStart(
delegate()
{
while (!m_rapi.DeviceFileExists(@"\Application\OEMName.txt") || !m_rapi.DeviceFileExists(@"\Application\OEMVersion.txt"))
{
System.Threading.Thread.Sleep(1000);
}
}));
MonitorThread.Start();
}
Dispatcher is for synchronising things back to the main thread, you don't need it here.
|
|
|
|
|
The first code works, however I need to be able to read contents of multiple files from a particular directory.
Start simple and build from there I figure. Doing something wrong somewhere, as the 2nd code only brings up the dos window without any data.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
namespace readtest
{
class Program
{
static void Main(string[] args)
{
StreamReader sr = new StreamReader("C:\\Users\\Random.txt");
string str = sr.ReadLine();
string[] words = str.Split('|');
foreach (string word in words)
{
Console.WriteLine(word);
} Console.ReadKey();
}
}
}
This is the one I need to have working. I must be structuring something wrong. I've tried different ways, but no luck.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
namespace ConsoleApplication2
{
class Program
{
static void Main(string[] args)
{
string[] files = Directory.GetFiles("C:\\Users", ".txt");
foreach (string file in files)
{
StreamReader sr = new StreamReader(file);
string str = sr.ReadLine();
{
Console.WriteLine(file);
}
} Console.ReadKey();
}
}
}
|
|
|
|
|
Member 8363084 wrote: string[] files = Directory.GetFiles("C:\\Users", ".txt");
you have to use * here as
string[] files = Directory.GetFiles("C:\\Users\\", "*.txt");
regards
|
|
|
|
|
try
string[] files = Directory.GetFiles("C:\\Users\\", "*.txt");
Although it may read a bit better with an @ sign
string[] files = Directory.GetFiles(@"C:\Users\", "*.txt");
"You get that on the big jobs."
|
|
|
|
|
To cut to the chase, our current connection string is:
Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties='Excel 12.0 Xml;HDR=YES;'
We really do not have the option of pushing a TypeGuessRows registry change to all users in order to force Excel to scan the whole column.
Can TypeGuessRows be given as an extended property to the ACE Provider?
Note: I know this isn't necessarily a C# specific question, but I'm writing in C# using an OleDbCommand, using the connectionString above.
"I need build Skynet. Plz send code"
|
|
|
|
|
There's no way to force TypeGuessRows in the connection string to a different value. I think your only option is to append "IMEX=1" to the connection string, which forces Excel to read all column data as text only. You'll then have to parse out out values from the strings returned.
|
|
|
|
|
btw, MS advised that the following should be correct:
Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties='Excel 12.0 Xml;HDR=YES;Imex=1;ImportMixedTypes=Text;TypeGuessRows=0;
"I need build Skynet. Plz send code"
|
|
|
|
|
Update 1
CreateFile hooking now works, but only when I suspend the state of the program when it is started, hook the process and then resume the process. I need to be able to do this when a process is opened without interacting with my program. (Meaning I am not able to start it suspended, I need a way to hook the process start or something.) It has been suggested to use Drivers... I'm all ears!
Next issue, when I hook an already running process, I need to be able to determine the file handle linked to gw.dat, and reopen the file to that same handle using ReOpenFile and new share peramaters. Are there any ideas on how to do this? I am not familiar with doing something like this, much less in an unmanaged environment....
Related Questions:
WIN32 API override (Specifically CreateFile) in C# [Solved and very helpful]
How to tell what method opens a file [Solved and not helpful]
Suspend specific process on launch C# [Not Solved, hoping for easier answer...]
Run code inside process with EasyHook
Change a handle in unmanaged code without pre-existing knowledge of process internals [From injected DLL]
Original
Note: I figured I would post this here to get input, and in case anyone tries something similar in the future.
Before you read any further please understand that I do not intend to go any farther then allowing the client to be run more then once. The only advantage will be the same as having two computers next to each other.
I am using C# with EasyHook.
Background: Guild Wars is an MMORPG, for the most part there are mainly only two files. gw.exe which is less then a MB is executed, opens gw.dat (With exclusive rights), checks for updates, loads the rest of the game from gw.dat. gw.dat just holds everything else.
gw.exe makes sure it is not running already when it first starts, and if it is it will just force the prior process to the foreground. If you remove the mutex you cannot properly open a second gw.exe because the first has exclusive rights to the one and only gw.dat.
Yes, it is possible to remove the mutex and run multiple gw.exe processes pointing to different gw.dat files with some registry changes but the gw.dat gets over 4GB and it is just annoying.
Possible Solution: Trough looking around I have put together a DLL, and can successfully inject it into the gw.exe process using EasyHook. I can hook methods of other DLL's, and can interface with the injecting program. Originally it had been suggested I hook CreateFileW and change the call so it does not force exclusivity to the file. It turns out that either I hook the process too late for CreateFileW is not the function used to connect to the file. (Figured this out)
It was also suggested that I could call ReOpenFileW to change current handles to gw.dat to share mode. I can't seem to be able to run anything that isn't inside a hook so I can't call ReOpenFileW. (Though I can hook it)
Intended Result: Basically, what I intend to achieve is injecting a DLL into gw.exe, forcing it to remove a file lock, and remove the mutex (mutex can be done externally but I figure while I'm in there why not?)
Are there any ideas? Alternative solutions?
I have been working on this easyhook solution for a few days now, but in all honesty if it is doomed, or there is an easier way to do this I am all ears!
Quick Note: While doing something like this is against the EULA of the game, there has never been a problem with it in the past and there have been no bannings for this specific type of modification!
Also, if you want to try your hand at doing this or want a first hand look at what is being done by gw.exe (I tried to understand the assembly but I never learned that art....) The gw.exe can be downloaded here, and can be run without an account. You just can't play the game. If needed I can upload my current source! I'll have to clean it up a bit though....
modified 9-Nov-11 22:19pm.
|
|
|
|
|
How do you start/hook? Do you start the gw.exe process in a suspended state?
|
|
|
|
|
I hand't thought of doing that actually... I was intending to hook every process run automatically without needing to start the process with my code at all. Though I suppose suspended state would just make sense till I get things running....
At the moment I detect process start by watching for it with ManagementEventWatcher like so:
string queryString =
"SELECT TargetInstance" +
" FROM __InstanceCreationEvent " +
"WITHIN " + 1 + " " +
" WHERE TargetInstance ISA 'Win32_Process' " +
" AND TargetInstance.Name = '" + processName + "'";
string scope = @"\\.\root\CIMV2";
watcher.EventArrived += ProcessStarted;
watcher.Start();
I then hook using EasyHook:
Config.Register(
"A FileMon like demo application.",
"FileMon.exe",
"FileMonInject.dll");
RemoteHooking.IpcCreateServer<FileMonInterface>(ref ChannelName, WellKnownObjectMode.SingleCall);
RemoteHooking.Inject(
TargetPID,
"FileMonInject.dll",
"FileMonInject.dll",
ChannelName);
modified 8-Nov-11 15:01pm.
|
|
|
|
|
The hooking code might run too late then, or maybe it doesn't and there's an other problem, but I think it's a good theory
|
|
|
|
|
Is there a quicker way to hook a process or detect it's initialization? Such as hooking the process creator itself? Not sure what that would be on a global scale....
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
