I have several classes which implement some interface, and instead of modifying it, I want to extend it with another interface.
When I'm thinking about designing the extending interface I'm not sure what is the best practice of how to include a reference to the original interface?
Id reference or include it as a property of the extending interface?
I've created an example below to show the need:
public interface IMovie
{
string UniqueId { get; set; }
string Name { get; set; }
string Ratnig { get; set; }
}
//Option #1
public interface IMovieWithSubTitles
{
string UniqueId { get; set; }
string SubTitles { get; set; }
}
//Option #2
public interface IMovieWithSubTitles
{
IMovie Movie { get; set; }
string SubTitles { get; set; }
}
Third option (inheritance):
interface IMovieWithSubTitles : IMovie
{
string SubTitles { get; set; }
}
Your first one just declares a separate interface. The second one aggregates IMovie. Both cases do not extend IMovie.
I would have inherited IMovie with the new interface, such as
public interface IMovieWithSubTitles : IMovie
{
string SubTitles { get; set; }
}
Related
My program is starting to get pretty big. and i have found that its starting to do the same thing in multiple area's.
Im trying to figure out how i can make it more efficient.
So i have an object that looks like this
public class TreeViewNode
{
public TreeViewNode()
{
Children = new ObservableCollection<TreeViewNode>();
}
public String Name { get; set; }
public string Description { get; set; }
public ObservableCollection<TreeViewNode> Children { get; set; }
}
i also have another object that looks like this;
public class ComputerObject
{
public String Name { get; set; }
public Int32 UUID { get; set; }
public DateTime Created { get; set; }
public ObservableCollection<Object> Children { get; set; }
}
Both these items need to have some of the same properties..
at the moment they both have the Children Property and the Name Property. but they both need to have some other common properties added to them.
so i have tried something like this.
public class BaseObject
{
public String Name { get; set; }
public ObservableCollection<Object> Children { get; set; }
public string Description { get; set; }
public BaseObject()
{
Children = new ObservableCollection<object>();
}
}
public class ComputerObject: BaseObject
{
public Int32 UUID { get; set; }
public DateTime Created { get; set; }
}
public class TreeViewNode: BaseObject
{
public String IconPath { get; set; }
}
Now this is just a cut down version of what i am implementing, i have alot of objects that share the same properties. and some that dont and mix and match. and i cannot figure out the best implimentation for this.
My Objects are becoming very cluttered, and when i rename a property i find that i have to rename it in several area's and this isnt the way its ment to be.
can someone please advise how i would implement multiple objects that share the same property names?
In my opinion you should not let classes inherit from one baseclass when these childclasses are not related to each other (like #Sriram Sakthivel asked Animal < Dog,Cat) just to share the same properties.
You should determine which classes are related (cat, dog are animals; car, motorcycle are vehicles) and then create baseclasses based on these "groupings".
I would look into decorator pattern. In short, you dont share common properties via inheritance. You make classes that contain common properties, and use these classes as properties in your end classes.
EDIT: Example is actually just a standard composition, it should work nevertheless
E.G.
public class Decorator1
{
public String Name { get; set; }
public ObservableCollection<Object> Children { get; set; }
public string Description { get; set; }
}
public class Decorator2
{
public long Id { get; set; }
}
public class ClassA
{
public Decorator1 TreeNodeImpl;
}
public class ClassB
{
public Decorator1 TreeNodeImpl;
public Decorator2 LongIdImpl;
}
Rather new to OOP..
I am gonna build a number of small applications that will support our main business.
These apps:
-Will need some common data classes
-The above classes may change in the future as far as properties are concerned (will add properties when ERP versions advance).
For example i have a class:
public class Lot
{
public string SSCC { get; set; }
public InventoryItem Item { get; set; }
public string DescriptionLocalLot { get; set; }
public string DescriptionEnglishLot { get; set; }
public DateTime ProductionDate { get; set; }
public string Shift { get; set; }
public string WorkOrder { get; set; }
public string ProductionLine { get; set; }
public string BarcodeEAN14 { get; set; }
public decimal Boxes { get; set; }
public decimal Units { get; set; }
public decimal Pieces { get; set; }
public DateTime LastUpdated { get; set; }
public string LastUser { get; set; }
public Warehouse LastWarehouse { get; set; }
public string ProductionLot { get; set; }
public string PalletSequence { get; set; }
}
The above class will be used by almost all applications (Windows forms or ASP pages). Ihave put this definition in a separate file called CommonClasses.
Should i define these classes as Abstract or Interfaces better? In most cases these classes will not include methods.
A class should describe all of an object's properties as well as methods that can act upon it. Not all are going to be used at once; but they are provided so that all the behavior is understood and state of an object can be tracked.
The class described in your code seems like a candidate for a concrete class. It provides a set of properties that are stored in memory and act in relation to one object. If you require additional functionality at a later point, you can extend the class to provide this.
If however, each instance of the class requires different implementation; then you should consider abstract class, or perhaps interface.
You should use concrete classes in your case if the change is common for all applications which are using these classes.
We currently have several underlying database tables such as Events, Shop Products, Content Pages etc. each with have shared properties such as having a Name, a details page on the front end of the site, a thumbnail url, an active flag etc.
I'm trying to figure out the most efficient way of creating a class of shared properties that can be used to pass around these objects generically. An example might be the search results page. The search can be done against the name of the collection of data which is actually across multiple tables originally.
I am struggling using inheritance due to all these classes originating from LINQ classes and I don't want to start editing the datacontext designer to suit my needs.
Currently each partial class on my LINQ classes contains a SharedObject method:
public partial class Event
{
public SharedObject SharedObject
{
get
{
return new SharedObject(this);
}
}
...
This is repeated for Events, Shop Products etc. The Shared Object class contains the following:
public class SharedObject
{
public string Reference { get; set; }
public string Name { get; set; }
public string ImageURL { get; set; }
public bool IsVisible { get; set; }
public bool IsAdminVisible { get; set; }
public string FrontEndDetailsURL { get; set; }
public string AdminDetailsURL { get; set; }
public object OriginalObject { get; set; }
public string ObjectDescription { get; set; }
public SharedObject(object originalObject)
{
if (originalObject.GetType() == typeof(Event))
{
Event eventx = (Event)originalObject;
Reference = eventx.Reference;
Name = eventx.Name;
ImageURL = eventx.ImageURL;
IsVisible = eventx.IsActive && !Event.IsArchived;
IsAdminVisible = !eventx.IsArchived;
FrontEndDetailsURL = eventx.DetailsURL;
AdminDetailsURL = eventx.AdminDetailsURL;
OriginalObject = originalObject;
ObjectDescription = "Event";
}
....
Does this sound like a suitable solution?
Consider using an interface. This is much more flexible.
public interface ISharedObject
{
string Reference { get; set; }
string Name { get; set; }
string ImageURL { get; set; }
bool IsVisible { get; set; }
bool IsAdminVisible { get; set; }
string FrontEndDetailsURL { get; set; }
string AdminDetailsURL { get; set; }
object OriginalObject { get; set; }
string ObjectDescription { get; set; }
}
public partial class Event : ISharedObject
{}
I think the most efficient way to pass around your shared objects is to use the "Chain of responsibility pattern" Chain of responsibility
For the inheritance LINQ you think of the use of IQueryable <T>. I hope that it can help you
I have a base DLL which defines some basic structure and operation for a key concept within our business. This dll is then included in specific web services for each vendor that implement the specific business rules for interacting with that vendor. (While the basic concepts are the same the implementations are very different and can change independently.)
In the base dll I have a series of interfaces set up as such
public interface IVendor
{
string Name { get; set; }
}
public interface IVendor<TC> : IVendor where TC : IAccount
{
IEnumerable<TC> Accounts { get; set; }
}
public interface IAccount
{
string Name { get; set; }
}
public interface IAccount<TP, TC> : IAccount where TP : IVendor
where TC : IExecutionPeriod
{
TP Vendor{ get; set; }
IEnumerable<TC> ExecutionPeriods { get; set; }
}
This continues down several more tiers, and everything compiles fine.
The problem comes when I try to implement this down in the service.
public class FirstVendor : IVendor<FirstVendorAccount>
{
public string Name { get; set; }
public IEnumerable<FirstVendorAccount> Accounts { get; set;}
}
public class FirstVendorAccount : IAccount<FirstVendor, FirstVendorExecutionPeriod>
{
public FirstVendor Vendor { get; set; }
public string Name { get; set; }
public IEnumerable<FirstVendorExecutionPeriod> ExecutionPeriods { get; set; }
}
I get a compiler error that IVendor, IAccount, etc. do not have type parameters. Which is particularly odd because when I asked it to implement the interface it included all of the members from both relevant interfaces.
It looks like you have a circular reference - FirstVendorAccount needs to know about FirstVendor before it can compile and vice versa.
Make one of these the 'dominant' class with the generic type, then the other can just return the base interface.
For instance:
public interface IVendor
{
string Name { get; set; }
}
public interface IVendor<TC> : IVendor where TC : IAccount
{
IEnumerable<TC> Accounts { get; set; }
}
public interface IAccount
{
string Name { get; set; }
}
// no longer needs IVendor<TC> before it can be compiled
public interface IAccount<TC> : IAccount where TC : IExecutionPeriod
{
IVendor Vendor{ get; set; }
IEnumerable<TC> ExecutionPeriods { get; set; }
}
It's worth looking at whether you really need all the generic typing - you may be better off with the non-generic underlying interfaces as these will be much easier to code with.
How can i make the following class as general as possible (for maximum reuse) without creating too many classes of the same type, albeit with one extra property.
I want to avoid writing 3 slightly different versions of the same class
1# Class with No SubContent
public class Content
{
public string PageName { get; set; }
}
2# Class with Subcontent
public class Content
{
public string PageName { get; set; }
public IList<Content> SubContent {get; set;} //same as class
}
3# Class with sub content of another type
public class Content
{
public string PageName { get; set; }
public IList<DetailContent> SubContent {get; set;} //Note the different def
}
Of course i can create a generic class, but i find this confusing for consumers. It is inferring that the class is of Type T, when in fact its the Property that requires the type
public class Content<T>
{
public string PageName { get; set; }
public IList<T> SubContent {get; set;} //Note the different def
}
Generic Properties are not supported. So are there any patterns or suggestion on how i can handle this problem?
Perhaps you can have a look at the Composite Design Pattern
whats wrong with:
public class Content<T>
{
public string PageName { get; set; }
public IList<T> SubContent { get; set; } //Note the different def
}
?
it works you know...
What about
public class Content
{
public string PageName { get; set; }
}
public class ContentWithSubContent<T> : Content
{
public IList<T> SubContent { get; set; }
}
and if you want to be able to access SubContent not knowing the actual type, you could use
public class Content
{
public string PageName { get; set; }
}
public interface IContentWithSubContent
{
IEnumerable SubContent { get; }
}
public class ContentWithSubContent<T> : Content, IContentWithSubContent
{
public IList<T> SubContent { get; set; }
IEnumerable IContentWithSubContent SubContent
{
get { return this.SubContent; }
}
}
that way you can access the SubContent property bypassing generics if you need to, by using IContentsWithSubContent rather than Content.
Why not make an interface for the content classes:
public interface IContent {
public function GetContent()
}
and then you can use
List<IContent> in your content class?
you could even make the interface generic