|
In this recent QA thread[^], is an example of creating a "class factory" based on an Interface, and then making classes that inherit from that Interface, and then, in the factory method, returning an instance of one of the inheritors cast to the Interface type.
I had set out to see, before reading Abhinav's comment on this thread, later followed by a code example, if I could achieve the same thing via use of an Abstract class definition, and, to my surprise, found that I could.
The curious thing being that I actually believed my code did not work ... until I saw Abhinav's code, and then went into my code, and set a break-point, and found I was indeed returning "pre-cast" objects from my factory method in the same way the use of the 'interface technique' would do 
So, why am I raising a question here ? Because: I am curious what the implications of making an implementation of a "factory class" based on using an Abstract class rather than an Interface are: is it a "bad practice," is it ever preferred as a technique over using an Interface ?
You can see the tested C# WinForms code for the 'abstract' based factory class solution here[^], and I will truly appreciate any comments, or guidance.
thanks, Bill
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
Hi Bill,
this is how I see the matter:
1.
when you decide to use a factory, it tells me you want to be able to get an instance of a number of possible types, where the exact type will depend on some parameters; and you also have good reasons to put the creation of those different instances in a common method because, to you, they share some common behavior, and its that behavior you're interested in.
Example: you could want a factory that returns either a Monkey or a Lion; you would not want a factory that either creates a Monkey or a ProgrammingLanguage.
2.
The common behavior is the only thing that matters to you; if you want Animal behavior, the Monkey-and-Lion example would be good, and both Monkey and Lion could inherit from Animal. Whether the inheritance is direct or distant (e.g. through Mammal or Quadruped or QuadrupedMammal) is irrelevant; the base class possibly being abstract doesn't matter either.
3.
As always in inheritance, a number of languages (all .NET, Java, ...) don't support multiple inheritance, however they offer a cheap almost-replacement (arguable) and that is an interface. So in a factory, if all the Monkeys and Lions ever do for you is walk, then it would be cheaper (i.e. less restrictive, and not consuming the single inheritance) to have Monkeys and Lions implement IWalk, so whatever the factory returns, you can make it Walk(). Much simpler than having the code that calls the factory worry about the exact genealogy of your Animals, Mammals, Quadrupeds, and what have you.
Conclusion: IMO factories should return an interface, unless you're pretty sure about the (stability of the) class hierarchy. It is in fact a weaker form of the "separation of concerns" principle.
PS: you're right, way too interesting to be handled in Q&A 
|
|
|
|
|
Nice explanation
No comment
|
|
|
|
|
Thanks Mark
|
|
|
|
|
That's a most eloquent, and intellectually satisfying answer, thanks, Luc !
If I interpret your words correctly (big IF), then I am inclined to interpret this type of use for interfaces ... beyond the obvious use as a way to establish a 'contract' that specifies what implementors of the interface must provide ... is to model shared 'behavior:' where modeling is-a, or inheritance relationships, is not an absolute requirement. As you say: "weaker form ... of separation of concerns." And more efficient ? At the least, more logically "lean and mean."
I do note the MS docs talk about interfaces in terms of expressing "related functionalities." And proscribes Interfaces as "The interface itself provides no functionality." And, of course, an Interface requires implementors to implement everything defined in the Interface.
While I am still a bit puzzled about what the 'abstract' class was intended for ... by its designers ... compared to just inheriting from a base class ... other than that it, indeed, does express is-a, or hierarchy: that's something I can certainly pursue in my books and on-line.
Since the abstract class does, as interface does, demand its consumers implement things it (optionally) wants to 'use' (via 'override'), and can, as explored here, function as a factory object; the question arises in my head as to what is a 'modal case' in which it would be 'crystal clear' that using 'abstract' as a basis for a factory class is 'best practice' ?
One clear difference that stands out: an abstract class can contain, as in my code-exploration, a static method: an interface cannot.
So, maybe, an interface is a schematic, and using abstract class as a factory object is more equivalent to a tool-chest with a schematic inside, as well as actual ready-to-go tools which can easily be modified on-the-job ?
from a happy Monkey to a wise Lion, Bill
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
Hi Bill,
I agree with what you said. And I'll phrase things differently once more:
an interface indeed is a contract: IWalk could be defined as "offers a public Walk() method". And that is all it is, there is no data defined, and no executable code whatsoever: no static methods, no instance methods. So it is just a spec for the implementer. And it can hide (or ignore) a lot; one of the nicest examples is IEnumerable (generic or not), as is required by foreach. Without knowing anything about your collection, foreach can enumerate all elements of your collection, whether an array, an ArrayList, a List<T>, a string of characters, etc.
A base class, abstract or not, can hold both data members and executable code; so it can provide real functionality (actual methods) as well as helper methods, etc.
An abstract class is a more restricted base class, in that the abstract methods must be replaced (overridden) by its inheritors.
So if you want Monkey and Lion classes, they could inherit from Animal. If you don't ever want to see a mere instance of Animal, then make that class abstract; if you want, or don't mind, a new Animal(), then don't make it abstract.
If Monkey and Lion were to be able to Hunt(), while deriving from an abstract Animal class, you would have to have each of them provide their own Hunt() method, which could rely on some shared methods in the base class.
In summary:
1. a class that inherits from a base class emphasizes the "is a" relationship, and therefore was willing to devote the single inheritance right it has to express that; it may or may not re-implement known behavior.
2. s class that inherits from an abstract class emphasizes the "is a" relationship, but also prevents the creation of non-specialized objects; the price to pay is you need to provide the specialization code in each of the descendants.
3. a class that implements an interface emphasizes the "knows how to" relationship, it does not exhaust the inheritance rights, however it must implement everything it promises it knows how to do.
More comments:
1. the set of available choices may not be perfect, but it is adequate. One could even live without abstract, leaving it out of the language spec (or the app) just opens the door to possibly unwanted situations (e.g. unspecified Animals); .NET would not be viable without interface.
2. every class can implement any number of interfaces, see e.g. the List<T> class which implements a lot of them.
3. typically the API of an interface is rather small, whereas the API of a class could be very big. There is an OO guideline that says something like: try to describe your interfacing specs in many, small interfaces, rather than in few, big interfaces; obviously nobody wants them so small that they become useless on their own, e.g. with collection-like functionality Add() and Remove() would normally be part of the same interface.
|
|
|
|
|
I have done that with abstract base classes in the past, but I prefer to use interfaces now. Interfaces are more flexible, they don't impose a relationship on the classes.
|
|
|
|
|
PIEBALDconsult wrote: Interfaces are more flexible, they don't impose a relationship on the classes.
If you care to expand on this interesting comment, I'd be very interested to know what the "costs" were of having the "relationship on the classes."
And, if you care to comment, why, in the past, did you use abstract classes rather than just inheriting from a base class ?
thanks, Bill
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
BillWoodruff wrote: "costs"
No, a limitation.
BillWoodruff wrote: base class
An abstract base class -- that shouldn't be instantiated on its own. It depends on the situation.
|
|
|
|
|
I think your question has been adequately answered by Luc.
I would use interfaces over abstract classes for a very simple reason - multiple inheritance is not supported in C#.
No matter whether you use classes or interfaces, what you are doing here is achieving "late binding".
|
|
|
|
|
Using an abstract base class means that you're restricting the objects that factory can create to a particular section of the class hierarchy. whereas using an interface allows any type of object to be created. This can either be a positive scope reducer or a negative restriction depending on context.
An obvious case where using a base class instead of an interface would make sense is a UI related factory, returning Control. Other appropriate cases are more problem specific but basically anywhere where it would make no sense to return something that wasn't in a particular hierarchy, probably because some framework or application code expects arguments of that type, would be an appropriate place to use an abstract (or non abstract, even) class.
|
|
|
|
|
In a C#.net 2010 application, I would like to take
values entered into individual checkbox and place each value of the
checkboxes into separate rows in a sql server 2008 r2 table. I would
also like to use linq to sql for this to occur. Since I am new to
working with linq, I am wondering how I could incorporate linq
into one of the options listed below. Would I need to unload all the
values from the checkboxes into a arraylist. Can you tell me
how to complete this task or point me to utls I can use as a
reference?
Here are some of my code examples:
option 1:
[^]foreach (ListItem item in
((CheckBoxList)Form.FindControl("cblActivities")).Items)
{
if (item.Selected)
{
string Activities += item.Value;
}
} [^]
option 2
[^]
IEnumerable<int> allChecked = chkBoxList.Items.Cast<ListItem>()
.Where(i => i.Selected)
.Select(i => int.Parse(i.Value)); [^]
|
|
|
|
|
A few questions I think can clarify the strategy required for your scenario:
1. are all the CheckBox(es) on the Form in their containers (Form, Panel, UserControl, etc.) at design-time, or do they need to be discovered 'dynamically' at run-time, since they may be created on demand, or they may be created as an outcome of a database query ?
2. is a recursive search necessary because you may have, for example, a panel with CheckBox(es) inside another panel with CheckBox(es), or similar ?
3. at this point ... independent of whether CheckBox(es)are all fixed at design-time, or added at run-time ... is there anything preventing you from adding each CheckBox to a List<CheckBox>, or multiple generic Lists of that Type ... if you need to segregate them in functional categories ?
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
In response to your questions:
1. The values for the checkboxes are discovered dynamically at runtime by running a database query.
2. The checkboxlist control is used. The recursive search is required since I need to know what checkboxes are selected. The user basically reads a letter from the customer and supplies the check marks by the applicable subcompanies.
3. I do not need to segregate the checkboxes into functional units.
Basically if 10 boxes are checked by subcompany, I need to add each checkbox area into a separate row in the Plans table. Basically if there are 10 boxes checked, I need to add 10 rows to he Plans table.
|
|
|
|
|
I apologize: I don't think I studied your question thoroughly enough before posing my questions, and did not fully understand the importance of the Linq=>SQL aspect of it.
While I do know what an ASP.NET CheckBoxList is, I have not programmed one directly myself.
My impression, at this moment, is you are describing a data-entry situation where an operator pulls up a Web Form (probably by a database query of some kind) populated with a certain number of CheckBoxLists, or one CheckBoxList, and then, based on scanning a customer letter, checks various CheckBoxListItems, and then you wish to iterate all that are checked, and map which CheckBoxLists have checked entries, and which entires are checked, into a Database table "Plans" in one or two different ways.
There are folks here who are truly expert on ASP.NET that I'm sure will respond.
Hope my responses were not distracting.
best, Bill
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
I had a class written like this:
public void Set<T>(string key, T value)
{
if(value == null)
{
return;
}
...
}
I'm using "reSharper" however within my visual studio (for those who don't know, resharper is a great little tool that helps clean up code and suggests better ways of writing it. Highly recomend it) to help clean up my code, and ReSharper suggested I write the first line of the above code in the following manner:
public void Set<T>(string key, T value) where T : class
What does this "where T : class" mean? I don't understand what it does.
Thanks
|
|
|
|
|
|
I'm not sure if I'm overlooking something here... this "WriteDat" variable is the byte array that I plan to use to write to the memory chip. the variable "nudSerialNumber" is the numericUpDown control that consists of new serial number. I need to plug the serial number into Writedat (without over-writing the first 2 MSB bits). Its in little edian value. (3rd line inside bracket is what threw an exception.)
void InsertSerialNumber(ref byte[] WriteDat)
{
byte[] serialNumberBytes = new byte[2] { WriteDat[0x60], WriteDat[0x61] };
Array.Reverse(serialNumberBytes);
Int32 serialNumberInt = BitConverter.ToInt32(serialNumberBytes, 0);
serialNumberInt &= 0xC0;
int newSerialNumberIntToWrite = (int)(nudSerialNumber.Value);
newSerialNumberIntToWrite |= serialNumberInt;
serialNumberBytes = BitConverter.GetBytes(newSerialNumberIntToWrite);
Array.Reverse(serialNumberBytes);
Array.Copy(WriteDat, 0x60, serialNumberBytes, 0, 2);
}
To clarify this:
WriteDat: 1111 1111 1111 1111 (no serial number applied)
New Ser#: 0000 0000 1010 0011 (serial number from nudSerialNumber
WriteDat: 1100 0000 1010 0011 (new serial number applied)
^^ (first 2 MSB is untouched)
|
|
|
|
|
Your byte array is only 16 bits long and you try to convert it to a 32 bit integer?
Maybe ToInt16 would be more appropriate (ToInt32 expects a 4-byte array)?
Mark Salsbery
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
when you say
Blubbo wrote: 3rd line inside bracket is what threw an exception
my guess is that you are refering to this line of code:
Int32 serialNumberInt = BitConverter.ToInt32(serialNumberBytes, 0);
BitConverter.ToInt32 is looking to read 4 bytes of information and you are only giving it 2 bytes. Try instead using BitConverter.ToInt16 which is designed for the 2 bytes that you are passing in.
BitConverter.ToInt32[^]
BitConverter.ToInt16[^]
best of luck.
as if the facebook, twitter and message boards weren't enough - blogged
|
|
|
|
|
Why are you jumping through hoops like that?
This code may be wrong due to endianness, which you reverse several times over and then apply a weird mask that seems to assume wrong endianness.. anyway I'm going to assume that WriteDat[0x60] is the least significant byte and WriteDat[0x61] is the most significant byte.
int newSn = ((WriteDat[0x61] << 8) & 0xc000) | (0x3fff & (int)(nudSerialNumber.Value));
WriteDat[0x60] = (byte)newSn;
WriteDat[0x61] = (byte)(newSn >> 8);
By the way, why is that byte array passed by ref?
|
|
|
|
|
Do you have any idea how to create IE plugin which will save to log file time of page load? This plugin should report start time (when user clicks go button) and end time (when page is completely loaded).
I prefer .net framework examples, but if you have other ideas, please fell free to post them
|
|
|
|
|
This has already been posted to Q&A; please do not post in multiple forums.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
So I've been reading along in a delightful book, Programming Microsoft SQL Server 2008, for months now, and decided to try out a few of the samples in the text. I fired up VS2010, then tried to add references to the two required assemblies - Microsoft.SqlServer.Smo and Microsoft.SqlServer.SmoExtended. They don't friggin' exist! The only thing visible in the Add References box is Microsoft.SqlServer.Server, so I figured they must have consolidated things a bit from .Net 3.5 to .Net 4.0. No such luck.
So then I tried changing the project from ver 4.0 to 3.5. I'm told I have to close the solution, then re-open it for the change to take effect. That makes sense, so I follow the instructions like a good sheep. When I reopen the solution, I'm presented with the error, "Warning 1 The referenced component 'Microsoft.CSharp' could not be found."
Where did it go? It's not even in the list to re-add it to the solution! All the other language references are there, but CSharp is now missing. Do I now have to re-install VS2010 to get C# functionality back again? Do I have to go back to VS2008 in order to talk to a database using SMO?
I really should be doing homework, but I needed a break and thought this would be a fun, relaxing evening of exploration. Instead, it's a nightmare...
Will Rogers never met me.
|
|
|
|
|
Microsoft.CSharp is a new reference in Framework 4.0.
If you are using something from this dll, then you will need to remove this code (or find a workaround) when you downgrade.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
