This might be a simple/basic OOP question, but I still cannot figure out how to solve it.
I had the following problem during an interview : make an UML class diagram and write the basic code for a "smart"phone which contains the functionalities of a telephone and of an mp3 player. We've got with the following (accepted) solution :
class Telephone
{
public string name { get; set; }
public Telephone()
{
name = "name telephone";
}
}
class MP3
{
public string name { get; set; }
public MP3()
{
name = "name mp3";
}
}
And the "smart"phone class :
class TelephoneMP3
{
public Telephone tel;
public MP3 mp3;
public TelephoneMP3()
{
tel = new Telephone();
mp3 = new MP3();
}
}
As you can see, we have a composition relation between the TelephoneMP3 and the Telephone/MP3 classes.
But, using this code, the TelephoneMP3 is not a Telephone and the TelephoneMP3 is not an MP3 either, which is not logical. So, what changes should I make in order to make this valid ? For example, this kind of test :
if (telMp3 is Telephone)
{
Console.WriteLine("TelephoneMP3 is telephone");
}
if (telMp3 is MP3)
{
Console.WriteLine("TelephoneMP3 is mp3");
}
The modifications could be made using the following remarks :
Telephone / MP3 / TelephoneMP3 must remain classes (all 3 of them)
I could add interfaces / other classes if necessary
TelephoneMP3 must not duplicate all the functionalities from a Telephone / MP3 (for example during an inheritance from an interface where the TelephoneMP3 will be obliged to write the code from all the interface's members)
Thank you in advance
Since C# doesn't support multiple inheritance, consider using interfaces instead:
public interface Phone{ ... }
public interface Mp3{ ... }
public class Telephone : Phone{ ... }
public class Mp3Player : Mp3{ ... }
public class Smartphone : Phone, Mp3{ ... }
This way Smartphone is both Phone and Mp3. If you are in need to write a method which operates on a Telephone, use the Phone interface instead. This way you'll be able to pass either Telephone or Smartphone as an argument.
There are some good answers here. The answers which say to use interfaces are good, and that's what the interviewer is likely looking for. However, I would consider simply denying the premise that the "is-a-kind-of" relationship being satisified is a good idea. Rather, I would consider using a service provider organization:
public interface ITelephone { ... }
internal class MyTelephone : ITelephone { ... }
public interface IMusicPlayer { ... }
internal class MyPlayer : IMusicPlayer { ... }
public interface IServiceProvider
{
T QueryService<T>() where T : class;
}
internal class MyDevice : IServiceProvider
{
MyTelephone phone = new MyTelephone();
MyPlayer player = new MyPlayer();
public T QueryService<T>() where T : class
{
if (typeof(T) == typeof(ITelephone)) return (T)(object)phone;
if (typeof(T) == typeof(IPlayer)) return (T)(object)player;
return null;
}
}
Now a caller has a MyDevice in hand via its IServiceProvider interface. You ask it
ITelephone phone = myDevice.QueryService<ITelephone>();
and if phone is non-null, then the device can act like a phone. But
myDevice is ITelephone
is false. The device is not a phone, it knows how to find you something that acts like a phone.
For more in this vein, study plug-in architectures such as MAF.
It is almost similar to the other answers, but..
I think it has the best accuracy regarding the inheritance hierarchy.
internal class Program
{
private static void Main(string[] args)
{
var telephone = new Telephone();
Console.WriteLine(telephone.Name);
telephone.OutboundCall("+1 234 567");
Console.WriteLine("Am I a Telephone? {0}", telephone is Telephone);
Console.WriteLine("Am I a MP3? {0}", telephone is MediaPlayer3);
Console.WriteLine("Am I a Smartphone? {0}", telephone is Smartphone);
Console.WriteLine("Do I Have Telephone Capabilities? {0}", telephone is ITelephone);
Console.WriteLine("Do I Have MP3 Capabilities? {0}", telephone is IMediaPlayer3);
Console.WriteLine();
var mp3 = new MediaPlayer3();
Console.WriteLine(mp3.Name);
mp3.PlaySong("Lalala");
Console.WriteLine("Am I a Telephone? {0}", mp3 is Telephone);
Console.WriteLine("Am I a MP3? {0}", mp3 is MediaPlayer3);
Console.WriteLine("Am I a Smartphone? {0}", mp3 is Smartphone);
Console.WriteLine("Do I Have Telephone Capabilities? {0}", mp3 is ITelephone);
Console.WriteLine("Do I Have MP3 Capabilities? {0}", mp3 is IMediaPlayer3);
Console.WriteLine();
var smartphone = new Smartphone();
Console.WriteLine(smartphone.Name);
smartphone.OutboundCall("+1 234 567");
smartphone.PlaySong("Lalala");
Console.WriteLine("Am I a Telephone? {0}", smartphone is Telephone);
Console.WriteLine("Am I a MP3? {0}", smartphone is MediaPlayer3);
Console.WriteLine("Am I a Smartphone? {0}", smartphone is Smartphone);
Console.WriteLine("Do I Have Telephone Capabilities? {0}", smartphone is ITelephone);
Console.WriteLine("Do I Have MP3 Capabilities? {0}", smartphone is IMediaPlayer3);
Console.ReadKey();
}
public interface IDevice
{
string Name { get; }
}
public interface ITelephone : IDevice
{
void OutboundCall(string number);
}
public interface IMediaPlayer3 : IDevice
{
void PlaySong(string filename);
}
public class Telephone : ITelephone
{
public string Name { get { return "Telephone"; } }
public void OutboundCall(string number)
{
Console.WriteLine("Calling {0}", number);
}
}
public class MediaPlayer3 : IMediaPlayer3
{
public string Name { get { return "MP3"; } }
public void PlaySong(string filename)
{
Console.WriteLine("Playing Song {0}", filename);
}
}
public class Smartphone : ITelephone, IMediaPlayer3
{
private readonly Telephone telephone;
private readonly MediaPlayer3 mp3;
public Smartphone()
{
telephone = new Telephone();
mp3 = new MediaPlayer3();
}
public string Name { get { return "Smartphone"; } }
public void OutboundCall(string number)
{
telephone.OutboundCall(number);
}
public void PlaySong(string filename)
{
mp3.PlaySong(filename);
}
}
}
Program Output:
Telephone
Calling +1 234 567
Am I a Telephone? True
Am I a MP3? False
AM I a Smartphone? False
Do I Have Telephone Capabilities? True
Do I Have MP3 Capabilities? False
MP3
Playing Song Lalala
Am I a Telephone? False
Am I a MP3? True
AM I a Smartphone? False
Do I Have Telephone Capabilities? False
Do I Have MP3 Capabilities? True
Smartphone
Calling +1 234 567
Playing Song Lalala
Am I a Telephone? False
Am I a MP3? False
AM I a Smartphone? True
Do I Have Telephone Capabilities? True
Do I Have MP3 Capabilities? True
I think this interview question is not (as should be all interview questions) about the challenge itself. The coding exercise of merging two classes via composition could be answered with a textbook. This challenge is a subtle trick question, and I propose that the point is to get you to discuss why. At least that's what I would want from my interviewees.
This test:
if(telMp3 is Telephone && telMp3 is MP3) {
...is the real problem. Why must you meet this criteria? This test completely voids the purpose of building objects out of composition. It demands that the objects are implemented in a specific way. It shows that the existing class implementations are already tightly coupled to the codebase (if they cannot be done away with). These requirements mean that SOLID principles were not followed, because you can't just fulfill the methods of a base type, you have to actually be the base type. That's no good.
As other answers have said, the solution would be to use interfaces. Then you can pass your object to any method that requires the interface. This kind of usage would require a test like so:
if (telMp3 is IPhone && telMp3 is IMp3) {
...but you can't do that, because of the limitation of your challenge. That means that out there in the rest of your code, people have been writing methods that explicitly depend on the specific types Telephone and MP3. That is the real problem.
In my opinion, the correct answer to this challenge is to say that the codebase fails the test. The specific fallout in your challenge is irrelvant; you need to change the requirements of the challenge before you can solve it properly. An interviewee would who recognize this fact would pass the test with flying colors.
You can use explicit interface implemenations as well to limit usage of the shared variable Name. That way you would have to cast to the interface to access it. You can still have public properties / methods from the interface.
Composition is still used, but the SmartPhone has control over the implementations of their properties / methods.
To me, this would be the easiest implementation to work with, because I rarely want to use both the implementation from the mp3player and the phone, but rather one of them. Also, I still have full control over what happens when the interfaces methods are called on the SmartPhone.
class User
{
void UseSmartPhone(SmartPhone smartPhone)
{
// Cannot access private property 'Name' here
Console.WriteLine(smartPhone.Name);
// Cannot access explicit implementation of 'IMp3Player.Play'
smartPhone.Play();
// You can send the phone to the method that accepts an IMp3Player though
PlaySong(smartPhone);
// This works fine. You are sure to get the Phone name here.
Console.WriteLine(((IPhone)smartPhone).Name);
// This works fine, since the Call is public in SmartPhone.
smartPhone.Call();
}
void CallSomeone(IPhone phone)
{
phone.Call();
}
void PlaySong(IMp3Player player)
{
player.Play();
}
}
class SmartPhone : IPhone, IMp3Player
{
private Phone mPhone;
private Mp3Player mMp3Player;
public SmartPhone()
{
mPhone = new Phone();
mMp3Player = new Mp3Player();
}
public void Call()
{
mPhone.Call();
}
string IPhone.Name
{
get { return mPhone.Name; }
}
string IMp3Player.Name
{
get { return mMp3Player.Name; }
}
void IMp3Player.Play()
{
mMp3Player.Play();
}
}
class Mp3Player
{
public string Name { get; set; }
public void Play()
{
}
}
class Phone
{
public string Name { get; set; }
public void Call()
{
}
}
interface IPhone
{
string Name { get; }
void Call();
}
interface IMp3Player
{
string Name { get; }
void Play();
}
How about this solution:
public interface ITelephone
{
string Name{get;}
void MakeCall();
}
public interface IMp3
{
string Name { get; }
void Play(string filename);
}
public abstract class BaseTelephone : ITelephone
{
public virtual string Name { get { return "Telephone"; } }
void MakeCall()
{
// code to make a call.
}
}
public class MyMp3Player : IMp3
{
public string Name { get { return "Mp3 Player"; } }
public void Play(string filename)
{
// code to play an mp3 file.
}
}
public class SmartPhone : BaseTelephone, IMp3
{
public override string Name { get { return "SmartPhone"; } }
private IMp3 Player { get { return _Player; } set { _Player = value; } }
private IMp3 _Player = new MyMp3Player();
public void Play(string filename) { Player.Play(filename); }
}
This way the smart phone can also be an Mp3 player, but internally it has an Mp3 player that it uses to play the music. The internal player can be swapped for a new one (eg. upgrade) by using the SmartPhone Player property.
The code for the phone is only written once, in the base phone class. The code for the Mp3 player is only written once also - in the MyMp3Player class.
Use the strategy pattern (used some shortcuts below, you'll get the gist).
public class Device {
private List<App> apps;
public Device() {
this.apps = new List<App>();
this.apps.Add(new Mp3Player());
this.apps.Add(new Telephone());
}
}
public class Mp3Player implements App {...}
public class Telephone implements App {...}
public interface App {...}
Disclaimer: my native tongue is PHP, forgive me any non C# coding standards etc etc.
You could use implicit casting
class TelephoneMP3
{
public Telephone tel;
public MP3 mp3;
public TelephoneMP3()
{
tel = new Telephone();
mp3 = new MP3();
}
public static implicit operator Telephone(TelephoneMP3 telemp3) {
return telemp3.tel;
}
public static implicit operator MP3(TelephoneMP3 telemp3) {
return telemp3.mp3;
}
}
It won't pass the exact test that you proposed, but you can do
var teleMp3 = new TelephoneMP3();
Telephone t = teleMp3;
You are trying to model a product hierarchy, in which a given product may have its own specific properties, as well as being composed of standard sub-products. This is indeed an example of the composition pattern. I suggest introducing a base interface for any product component, then creating specific interfaces for telephone, MP3 player and smartphone products.
In the traditional composition pattern each node may contain an arbitrary list of components to which subcomponents can be added or removed, however in your data model it appears more useful for each specific type of product to specify its precise children, then provide a generic method to iterate over them. This allows for specific (sub)components of a specified type/interface to be easily queryable throughout the product hierarchy.
I've also introduced an interface for a GPS product since all new phones contain built-in GPS receivers -- just to illustrate how to work with recursive hierarchies of components.
public interface IProductComponent
{
string Name { get; set; }
IEnumerable<IProductComponent> ChildComponents { get; }
IEnumerable<IProductComponent> WalkAllComponents { get; }
TProductComponent UniqueProductComponent<TProductComponent>() where TProductComponent : class, IProductComponent;
}
public interface ITelephone : IProductComponent
{
IGps Gps { get; }
}
public interface IMp3Player : IProductComponent
{
}
public interface IGps : IProductComponent
{
double AltitudeAccuracy { get; }
}
public interface ISmartPhone : IProductComponent
{
ITelephone Telephone { get; }
IMp3Player Mp3Player { get; }
}
These interfaces could then be implemented by a parallel set of classes:
public abstract class ProductComponentBase : IProductComponent
{
string name;
protected ProductComponentBase(string name)
{
this.name = name;
}
#region IProductComponent Members
public string Name
{
get
{
return name;
}
set
{
name = value;
}
}
public virtual IEnumerable<IProductComponent> ChildComponents
{
get
{
return Enumerable.Empty<IProductComponent>();
}
}
public IEnumerable<IProductComponent> WalkAllComponents
{
get
{
yield return this;
foreach (var child in ChildComponents)
{
foreach (var subChild in child.WalkAllComponents)
yield return subChild;
}
}
}
public TProductComponent UniqueProductComponent<TProductComponent>() where TProductComponent : class, IProductComponent
{
TProductComponent foundComponent = null;
foreach (var child in WalkAllComponents.OfType<TProductComponent>())
{
if (foundComponent == null)
foundComponent = child;
else
throw new Exception("Duplicate products found of type " + typeof(TProductComponent).Name);
}
return foundComponent;
}
#endregion
}
public class Telephone : ProductComponentBase, ITelephone
{
IGps gps = new Gps();
public Telephone()
: base("telephone")
{
}
#region ITelephone Members
public IGps Gps
{
get
{
return gps;
}
}
#endregion
IEnumerable<IProductComponent> BaseChildComponents
{
get
{
return base.ChildComponents;
}
}
public override IEnumerable<IProductComponent> ChildComponents
{
get
{
if (Gps != null)
yield return Gps;
foreach (var child in BaseChildComponents)
yield return child;
}
}
}
public class Gps : ProductComponentBase, IGps
{
public Gps()
: base("gps")
{
}
#region IGps Members
public double AltitudeAccuracy
{
get { return 100.0; }
}
#endregion
}
public class TelephoneMP3 : ProductComponentBase, ISmartPhone
{
ITelephone telephone;
IMp3Player mp3Player;
public TelephoneMP3()
: base("TelephoneMP3")
{
this.telephone = new Telephone();
this.mp3Player = new MP3();
}
IEnumerable<IProductComponent> BaseChildComponents
{
get
{
return base.ChildComponents;
}
}
public override IEnumerable<IProductComponent> ChildComponents
{
get
{
if (Telephone != null)
yield return Telephone;
if (Mp3Player != null)
yield return Mp3Player;
foreach (var child in BaseChildComponents)
yield return child;
}
}
#region ISmartPhone Members
public ITelephone Telephone
{
get { return telephone; }
}
public IMp3Player Mp3Player
{
get { return mp3Player; }
}
#endregion
}
public class MP3 : ProductComponentBase, IMp3Player
{
public MP3()
: base("mp3Player")
{
}
}
As new product component types are added (or subclassed), they override the "ChildComponents" of their parent and return their domain specific children.
Having done this, you can (recursively) query the product hierarchy for components of a given type for your use. For instance:
var accuracy = smartPhone.UniqueProductComponent<IGps>().AltitudeAccuracy
or
bool hasPhone = (component.UniqueProductComponent<ITelephone>() != null)
This combination of generalization and composition avoids duplicating code while making explicit the type of sub-components that should be found in any given product. It also avoids the burden of making all higher-level products proxy the interfaces of their standard children, passing all calls on to them.
Contrary to all the other answers I am quite confident the way this question is asked makes it impossible. The reason is the following :
You explicitly state
But, using this code, the TelephoneMP3 is not a Telephone and the TelephoneMP3 is not an MP3 either, which is not logical. So, what changes should I make in order to make this valid ?
Seeing the word "is" makes me immediately think of the "is" operator. I immediately assume that this is what you really want.
You then go on later to say the following:
Telephone / MP3 / TelephoneMP3 must remain classes (all 3 of them)
Well sure we can do the following:
interface ITelephone { }
class Telephone
{
public string name { get; set; }
public Telephone()
{
name = "name telephone";
}
}
interface IMP3 { }
class MP3 : IMP3
{
public string name { get; set; }
public MP3()
{
name = "name mp3";
}
}
class TelephoneMP3 : ITelephone, IMP3
{
public Telephone tel;
public MP3 mp3;
public TelephoneMP3()
{
tel = new Telephone();
mp3 = new MP3();
}
}
But we still have one problem. The word "is". Since we must keep the classes TelephoneMP3, Telephone and MP3 and C# does not support multiply inheritance it simply is not possible.
To Illustrate my point:
public class Program
{
static void Main(string[] args)
{
TelephoneMP3 t = new TelephoneMP3();
Console.WriteLine((t is TelephoneMP3)? true:false);
Console.WriteLine((t is ITelephone) ? true : false);
Console.WriteLine((t is IMP3) ? true : false);
Console.WriteLine((t is Telephone) ? true : false);
Console.WriteLine((t is MP3) ? true : false);
Console.ReadLine();
}
}
This will give you
True
True
True
False
False
In other words TelephoneMP3 "is" an ITelephone. TelephoneMP3 "is" an IMP3; however, it is not possible for a TelephoneMP3 to be both a MP3 and a Telephone.
C# does not support multiple inheritance, you need to use interfaces and abstract class for common implementations , You can do the follwing :
Edit : I have add more details to my answer
abstract class BaseDevice
{
public string name { get; set; }
public void Print()
{
Console.WriteLine("{0}", name );
}
}
public interface IPhone
{
void DoPhone();
}
public interface IMP3
{
void DoMP3();
}
class Telephone :BaseDevice , IPhone
{
public Telephone()
{
name = "name telephone";
}
}
class MP3 : BaseDevice , IMP3
{
public MP3()
{
name = "name mp3";
}
}
class telMp3 : BaseDevice , IMP3, IPhone
{
private Telephone _tel;
private MP3 _mp3;
public telMp3()
{
name = "name telMp3";
}
public void DoPhone()
{
_tel.DoPhone();
}
public void DoMP3()
{
_mp3.DoMP3();
}
}
Related
I am new to programming and learning through online stuff and you guys, nowadays! I am reading about Factory Design Pattern and tried to implement in the very basic project, I have a solution that has two projects one projects contain interfaces, and the other contains implementation, I have read about factories but unfortunately, I have no idea how to implement in my project, In one project, I have 2 interfaces IBasicCars and ILuxuryCars, IluxuryCars implementing IBasicCars and then in the second project I have a class that inherits from ILuxuryCars and implement all of its methods and IBasicCars methods and properties, here is my code for that class.
public class LuxuryCars : ILuxuryCar
{
private string _color { get; set; }
public string Color
{
get
{
return _color;
}
set
{
_color = value;
}
}
private int _model { get; set; }
public int Model
{
get
{
return _model;
}
set
{
_model = value;
}
}
private string _make { get; set; }
public string Make
{
get
{
return _make;
}
set
{
_make = value;
}
}
public void Break()
{
Console.WriteLine("This is the basic function of all cars !!!");
}
public void CruiseControl()
{
Console.WriteLine("This is the luxury feature for luxury cars !!!");
}
public void Drive()
{
Console.WriteLine("This is the basic function of all cars !!!");
}
public void Navigation()
{
Console.WriteLine("This is the luxury feature for luxury cars !!!");
}
public void Park()
{
Console.WriteLine("This is the basic function of all cars !!!");
}
}
now I have another class "FactoryObject" in that project that has nothing in it right now, can someone please tell me to do I implement the factory design pattern?
that is how I am calling these methods in main method
static void Main(string[] args)
{
ILuxuryCar lc = new LuxuryCars();
lc.Color = "Black";
lc.Make = "Honda";
lc.Model = 2007;
Console.WriteLine("Car color is: {0} Made by: {1} Model is: {2}", lc.Color, lc.Make, lc.Model);
lc.Navigation();
lc.CruiseControl();
lc.Break();
lc.Drive();
lc.Park();
Console.WriteLine();
IBasicCar b = new LuxuryCars();
b.Color = "Red";
b.Make = "Alto";
b.Model = 2019;
Console.WriteLine("Car color is: {0} Made by: {1} Model is: {2}", lc.Color, lc.Make, lc.Model);
lc.Break();
lc.Drive();
lc.Park();
Console.ReadLine();
}
A very simple factory could be
public interface ICarFactory{
ICar Create();
}
public class BasicCarFactory : ICarFactory{
public ICar Create() => new BasicCar();
}
public class LuxuryCarFactory : ICarFactory{
public ICar Create() => new LuxuryCar();
}
This makes it more complicated to create a car, but the important bit is that components that need to create new car objects can do so without knowing what kind of car is created.
You might for example check the license at startup, and depending on the license create different factories that you hand of to all the other components. This way you have the license check at one single place, instead of spread out over different components.
In simple cases you might not need a separate inteface, a Func<ICar> might be sufficient.
I am not sure that this title is correct..Anyways I have a class that has a number of methods that control a stereo. Each method will send a command to a serial port. There are many models of stereos supported and each stereo may have a different command that needs to be sent.
For example model_A may need to send the command "VOLUP" to the serial port and "model_B" may need to send the command "GAINUP" to increase the volume. I want to have one method called IncreaseVolume like this:
public void IncreaseVolume()
{
serialPort.WriteLine(volumeCommand);
}
This method will be called from another class after setting the model of the radio. Now for two radios I could do this:
public class StereoControl
{
string volumeCommand;
string model_A_Volume_Command = "VOLUP";
string model_B_VOlume_Command = "GAINUP";
public void Set_Radio_Model(string model)
{
if (model == "modelA")
{
volumeCommand = model_A_Volume_Command;
}
else if (model == "modelB")
{
volumeCommand = model_B_Volume_Command;
}
}
public void IncreaseVolume(volumeCommand)
{
serialPort.WriteLine(volumeCommand);
}
}
So the main program will first set the model and then anytime the volume needs increasing it will just call the IncreaseVolume method.
The things is that there are potentially dozens of stereos and dozens of commands and I don't necessarily want all these in if then or case statements.
I thought of creating structures for each model containing the commands but then how do you select which structure to use in the methods?
I am sure there is a more elegant way to do this and am open to suggestions.
The first answer while usable, when we get 100+ commands and 200+ stereo's it will be a bit too difficult to handle. So here is another possibility but I do not know how to get the class reference available throughout the application.
public Class Model_A
{
string volumeCommand = "VOLUP";
}
public Class Model_B
{
string volumeCommand = "GAINUP";
}
public Class StereoControl
{
public void Set_Radio_Model(String model)
{
if (model == "model_a")
{
var _radio = new Model_A();
}
else if (model == "model_b")
{
var _radio = new Model_B();
}
}
public void IncreaseVolume()
{
serialPort.WriteLine(_radio.volumeCommand);
}
}
Of course the issue here is that the scope of _radio is only within the Set_Radio_Model. Is there a way to _radio usable everywhere?
Tom
The very basic way is to have Enum of stereos names and then implement it in OOP
(I hope people help to improve it) this is just depends on my opinion.
1- Define enum like:
public enum StereoBrand
{
Stero1 = 0,
Stereo2 = 1
}
2- Define an interface to enforce all stereos implement IncreaseVolume() like:
public interface IStereo
{
string VolumeCommand { get; }
string SteroeName { get; }
void IncreaseVolume();
}
by above interface each stereo should have a name as StereoName.
3- And then implement StereoController like :
public class SteroController : IStereo
{
public virtual string SteroeName
{
get
{
return string.Empty;
}
}
public virtual string VolumeCommand
{
get
{
return string.Empty;
}
}
public virtual void IncreaseVolume()
{
throw new NotImplementedException();
}
public static SteroController GenerateStereo(StereoBrand brand)
{
SteroController stereo = null;
switch (brand)
{
case StereoBrand.Stero1:
stereo = new Stereo1();
break;
case StereoBrand.Stereo2:
stereo = new Stereo2();
break;
}
return stereo;
}
}
Notes of Step3:
3.1- StereoController implement IStereo and change that prop and Increase method to Virtual that all Stereo can override them.
3.2- GenerateStereo which create related stereo by its StereoName
4- Suppose we have to implement Stereo classes here Stereo1 and Stereo2 like:
public class Stereo1 : SteroController
{
public override string SteroeName
{
get
{
return "Streo1";
}
}
public override string VolumeCommand
{
get
{
return "Command1";
}
}
public override void IncreaseVolume()
{
//Do anything with VolumCommand
}
public Stereo1()
{
}
}
public class Stereo2 : SteroController
{
public override string SteroeName
{
get
{
return "Streo2";
}
}
public override string VolumeCommand
{
get
{
return "Command2";
}
}
public override void IncreaseVolume()
{
//Do anything with VolumCommand2
}
public Stereo2()
{
}
}
5- The last step is using them like:
var stero = SteroController.GenerateStereo((StereoBrand)Enum.Parse(typeof(StereoBrand), "brandName"));
stero.IncreaseVolume();
Notes:
N1: This is better to implement GenerateStereo by reflection which means find all IStereo and make an instance by reflection.
N2: The another solution to avoid switch-case is using reflection to find related Stereo like:
public static SteroController GenerateStereo(StereoBrand brand)
{
SteroController stereo = null;
var type = typeof(IStereo);
var types = AppDomain.CurrentDomain.GetAssemblies()//Find all classes which implemented ISereo
.SelectMany(s => s.GetTypes())
.Where(p => type.IsAssignableFrom(p)).ToList();
foreach(Type t in types)
{
var stereoNameProp = t.GetProperties().SingleOrDefault(p => p.Name == "StereoName");//Get stereo name prop
if (stereoNameProp != null && stereoNameProp.GetValue(t).ToString() == brand.ToString())//Check it with brand name
stereo =(SteroController)Activator.CreateInstance(type);//Make an instance
}
return stereo;
}
Hope it help and give you the clue.
My application consist of server and client, which are independant. They communicate through objects created and modified by server. Client is provided with read-only interfaces of this objects. As far as I know, that's the correct way to keep encapsulation in OOP. See example:
// Client-side
interface IBox<T> where T : ITool
{
IEnumerable<T> Tools { get; }
}
interface ITool
{
void Use();
}
// Server-side
class Box : IBox<Tool>
{
public List<Tool> ToolList = new List<Tool>();
public IEnumerable<ITool> Tools
{
get { return ToolList; }
}
}
class Tool : ITool
{
string _msg = "default msg";
public string Msg
{
get { return _msg; }
set { _msg = value; }
}
public void Use()
{
Console.WriteLine("Tool used! Msg: {0}", _msg);
}
}
As you see, I have to use generics, because my objects form a hierarchy.
That looked nice, until I've decided to add a Room class with interface IRoom, which have to generalize not only IBox, but ITool too:
interface IRoom<B, T>
where B : IBox<T>
where T : ITool
{
IEnumerable<B> Boxes { get; }
}
class Room : IRoom<Box, Tool>
{
public List<Box> BoxList = new List<Box>();
public IEnumerable<Box> Boxes
{
get { return BoxList; }
}
}
Now, imagine that we have a Room consist of not only boxes. I need at least 3 collections of absolutely different things there, which are collections of several types too. So, there must be a huge tree, and my root class become something like: Room : IRoom<Box, Tool1, Tool2, Tool3, Wardrobe, Coat, Jeans, Hat, Table, Computer, Book, Pen>
I'm not sure, that is right. So, I'm asking, what is true OOP-way of implementing my task? (with no reflection, breaking encapsulation, type casting or other bad tricks)
Starting with the .NET Framework 4 and C# 4 you can use IEnumerable's covariance and just avoid using generics.
// Client-side
interface IBox
{
IEnumerable<ITool> Tools { get; }
}
interface ITool
{
void Use();
}
// Server-side
class Box : IBox
{
public List<Tool> ToolList = new List<Tool>();
public IEnumerable<ITool> Tools
{
get { return ToolList; } // With .NET 3.5 and earlier cast here is neccessary to compile
// Cast to interfaces shouldn't be so much of a performance penalty, I believe.
}
}
class Tool : ITool
{
string _msg = "default msg";
public string Msg
{
get { return _msg; }
set { _msg = value; }
}
public void Use()
{
Console.WriteLine("Tool used! Msg: {0}", _msg);
}
}
interface IRoom
{
IEnumerable<IBox> Boxes { get; }
}
class Room : IRoom
{
public List<Box> BoxList = new List<Box>();
public IEnumerable<IBox> Boxes
{
get { return BoxList; } // and here...
}
}
Covariance and contravariance in generics described here: http://msdn.microsoft.com/en-us/library/dd799517.aspx
Want to check if this a good example for representing the abstract factory pattern.
Here is the theme
Dell (Factory) makes xps (Product)
Dell (Factory) makes inspiron (Product)
hp (Factory) makes envoy (Product)
hp (Factory) makes presario (Product)
BestBuy sells computers.
//Abstract factory
abstract class ComputerFactory
{
public abstract Computer BuildComputer(Computer.ComputerType compType);
}
//Concrete factory
class Dell : ComputerFactory
{
public override Computer BuildComputer(Computer.ComputerType compType)
{
if (compType == Computer.ComputerType.xps)
return (new xps());
else if (compType == Computer.ComputerType.inspiron)
return new inspiron();
else
return null;
}
}
//Concrete factory
class Hp : ComputerFactory
{
public override Computer BuildComputer(Computer.ComputerType compType)
{
if (compType == Computer.ComputerType.envoy)
return (new envoy());
else if (compType == Computer.ComputerType.presario)
return new presario();
else
return null;
}
}
//Abstract product
public abstract class Computer
{
public abstract string Mhz { get; set; }
public enum ComputerType
{
xps,
inspiron,
envoy,
presario
}
}
//Concrete product for DELL
public class xps : Computer
{
string _mhz = string.Empty;
public override string Mhz
{
get
{
return _mhz;
}
set
{
_mhz = value;
}
}
}
//Concrete product for DELL
public class inspiron : Computer
{
string _mhz = string.Empty;
public override string Mhz
{
get
{
return _mhz;
}
set
{
_mhz = value;
}
}
}
//Concrete product for HP
public class envoy : Computer
{
string _mhz = string.Empty;
public override string Mhz
{
get
{
return _mhz;
}
set
{
_mhz = value;
}
}
}
//Concrete product for HP
public class presario : Computer
{
string _mhz = string.Empty;
public override string Mhz
{
get
{
return _mhz;
}
set
{
_mhz = value;
}
}
}
public class BestBuy
{
ComputerFactory compFactory;
Computer comp;
public BestBuy(Computer.ComputerType compType)
{
if (compType == Computer.ComputerType.xps || compType == Computer.ComputerType.inspiron)
compFactory = new Dell();
else
compFactory = new Hp();
comp = compFactory.BuildComputer(compType);
}
public Computer Sell()
{
return comp;
}
}
Thanks in advance.
It is a good example of portions of the pattern. The basic construction of objects is a decent example, however, the logic relies upon a single Computer.ComputerType enum. This enum needs to know, in advance, every type of computer exposed by every factory.
Often, the motivation for using an abstract factory is to abstract that type of hard coded requirement out of the picture. Instead of having a single enum, it might be better to add a ComputerType class, and allow the factory to return a collection of available types. You could then use the ComputerType returned to construct the new systems.
This allows you to add other factories without changing your API, which is one of the major advantages of the abstract factory pattern. Read up on the Abstract Factory Pattern - one of the main points is:
The client does not know (or care) which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products.
In this case, you're "hard coding" the known types into the enum, which violates this portion of the pattern.
I'm not Factory pattern expert but here are couple of things I would do differently:
Instead of an abstract class, I would use an Interface. So if "Dell" needed to inherit from another class it could and still be able to be a ComputerFactory by implementing IComputerFactory for example.
The other small thing is use a "switch" instead of an "if/else if" in your BuildComputer function. Who knows how many computers you might end up with in the end.
How would you know which concrete Factory to use between Hp and Dell? You might use something like "Autofac" to "resolve" which factory to use.
I think, in the scenario and code you have provided, there is only one type of product, i.e 'Computer'. There is no family of products involved. So, the abstract factory pattern will not apply here. Instead factory pattern can be used here. I have modified the code below for understanding.
//Abstract factory
abstract class ComputerFactory
{
public abstract Computer BuildComputer(Computer.ComputerType compType);
}
public class ConcreteFactory : ComputerFactory
{
public override Computer BuildComputer(Computer.ComputerType compType)
{
if (compType == Computer.ComputerType.xps)
return (new xps());
else if (compType == Computer.ComputerType.inspiron)
return new inspiron();
else if (compType == Computer.ComputerType.envoy)
return (new envoy());
else if (compType == Computer.ComputerType.presario)
return new presario();
else
return null;
}
}
//Abstract product
public abstract class Computer
{
public abstract string Mhz { get; set; }
public enum ComputerType
{
xps,
inspiron,
envoy,
presario
}
}
//Concrete product for DELL
public class xps : Computer
{
string _mhz = string.Empty;
public override string Mhz
{
get
{
return _mhz;
}
set
{
_mhz = value;
}
}
}
//Concrete product for DELL
public class inspiron : Computer
{
string _mhz = string.Empty;
public override string Mhz
{
get
{
return _mhz;
}
set
{
_mhz = value;
}
}
}
//Concrete product for HP
public class envoy : Computer
{
string _mhz = string.Empty;
public override string Mhz
{
get
{
return _mhz;
}
set
{
_mhz = value;
}
}
}
//Concrete product for HP
public class presario : Computer
{
string _mhz = string.Empty;
public override string Mhz
{
get
{
return _mhz;
}
set
{
_mhz = value;
}
}
}
public class BestBuy
{
ConcreteFactory compFactory;
Computer comp;
public BestBuy(Computer.ComputerType compType)
{
comp = compFactory.BuildComputer(compType);
}
public Computer Sell()
{
return comp;
}
}
Is there any issues in using version 2,to get the same results as version 1.
Or is this just bad coding.
Any Ideas
public class Customer
{
public int CustomerID { get; set; }
public string EmailAddress { get; set; }
int Age { get; set; }
}
public interface ICustomer
{
void AddNewCustomer(Customer Customer);
void AddNewCustomer(string EmailAddress, int Age);
void RemoveCustomer(Customer Customer);
}
public class BALCustomer
{
private readonly ICustomer dalCustomer;
public BALCustomer(ICustomer dalCustomer)
{
this.dalCustomer = dalCustomer;
}
public void Add_A_New_Customer(Customer Customer)
{
dalCustomer.AddNewCustomer(Customer);
}
public void Remove_A_Existing_Customer(Customer Customer)
{
dalCustomer.RemoveCustomer(Customer);
}
}
public class CustomerDataAccess : ICustomer
{
public void AddNewCustomer(Customer Customer)
{
// MAKE DB CONNECTION AND EXECUTE
throw new NotImplementedException();
}
public void AddNewCustomer(string EmailAddress, int Age)
{
// MAKE DB CONNECTION AND EXECUTE
throw new NotImplementedException();
}
public void RemoveCustomer(Customer Customer)
{
// MAKE DB CONNECTION AND EXECUTE
throw new NotImplementedException();
}
}
// VERSION 2
public class Customer_New : DataRespository<CustomerDataAccess>
{
public int CustomerID { get; set; }
public string EmailAddress { get; set; }
public int Age { get; set; }
}
public class DataRespository<T>
where T:class,new()
{
private T item = new T();
public T Execute { get { return item; } set { item = value; } }
public void Update()
{
//TO BE CODED
}
public void Save()
{
//TO BE CODED
}
public void Remove()
{
//TO BE CODED
}
}
class Program
{
static void Main(string[] args)
{
Customer_New cus = new Customer_New()
{
Age = 10,
EmailAddress = "this#demo.com"
};
cus.Save();
cus.Execute.RemoveCustomer(new Customer());
// Repository Version
Customer customer = new Customer()
{
EmailAddress = "new#demo.com",
CustomerID = 10
};
BALCustomer bal = new BALCustomer(new CustomerDataAccess());
bal.Add_A_New_Customer(customer);
}
}
You have a lot of things going on that aren't making a lot of sense.
First of all, the names of properties should always be a noun (singular or plural) or a "being" verb like Is* or Has*. These are properties of an object, and should be similar to what you would say in response to a question like "Would you please describe your desk?" Execute is an operation, and should therefore be a method. Likewise, your naming conventions in Version 1 should be PascalCased which means no underscores and the first letter of all words should be capitalized. These aren't die-hard truths, but they are considered OOP common C# coding standards.
Secondly, the code in your main method isn't actually implementing anything in your generic class. The only thing your class is actually doing is creating an instance of CustomerDataAccess. The Save() method won't do anything, unless you specifically are able to call item.Save() In order to use your Save, Update, Delete functionality on your generic class, your CustomerDataAccess class will have to implement an interface expected by your generic class. For instance:
public interface IDataAccess<T> : where T : YourBaseObject {
public void Update(T item);
public void Save(T item);
public void Remove(T item);
}
public class Customer : YourBaseObject {
public int CustomerID { get; set; }
public string EmailAddress { get; set; }
public int Age { get; set; }
}
public class CustomerDataAccess :
DataRespository<IDataAccess<Customer>> {
public void PerformCustomerOnlyAction(Customer customer) {
/* do stuff */
}
}
Now, you can create a generic class that handles basic CRUD functionality, and all other functionality is accessible through the BaseRepository property.
/* e.g. T = IDataAccess<Customer>, K = Customer */
public class DataRespository<T>
where T : IDataAccess<K>, new()
where K : YourBaseObject, new()
{
private T _base;
public T BaseRepository {
get {
if(_base == null)
_base = Activator.CreateInstance<T>();
return _base;
}
}
public void Update(K item) { /* functionality for YourBaseObject */ }
public void Save(K item) { /* functionality for YourBaseObject */ }
public void Remove(K item) { /* functionality for YourBaseObject */ }
}
class Program
{
static void Main(string[] args)
{
var repository = new CustomerDataAccess();
Customer c = new Customer {
Age = 10,
EmailAddress = "this#demo.com"
};
repository.Save(c);
// This pass-through is no longer needed, but shown as example
// repository.BaseRepository.PerformCustomerOnlyAction(c);
repository.PerformCustomerOnlyAction(c);
}
}
NOTE I did the above code from scratch/memory. The generic type constraints may not work exactly as I have them.
ASP.NET 3.5 Unleashed by Stephen Walther has a couple of chapters on creating a repository pattern which is setup similarly to what you're trying to accomplish in Version 2. He also splits processing up between a business logic layer and a data access layer. Although the book is huge (nearly 2000 pages) and many of the code examples are redundant or better left as part of the CD, he goes pretty in-depth for beginner-to-intermediate range. It's available used on Amazon for around $25.
I think while implementing object model of your application you just have to ask yourself a number of questions as though you are make object design review of your collegue code.
Why CustomerAccessLayer implements interface? Is there will be a number of layers implementing this Interface. Or maybe you are expecting any polymorph behaviour from classes implements this interface? Or maybe you will separate interface to standalone module and will provide its functionality though any kind of service?
Why do you need BALCustomer class? Why you could not make calls directly to CustomerAccesLayer? And, have i already spoke about codesyle? :)
If DataRepository have a generic behaviour and will provide a number of AccessLayers throw Execute property why it is have its own methods?
I think could be continued... I hope you've catch my point?