I have the following code snippet
class Vehicle{
public String brand;
public double price;
public int productionYear;
public String toString(String formatType) {
switch(formatType) {
case "JSON": // JSON formatting here
return jsonFormattedString;
break;
case "XML": // XML formatting here
return xmlFormattedString;
break;
default: // default formatting
return defaultFormattedString;
}
}
I believe that the problem with this approach is the need of changing
the source code if the behaviour changes (another formatting type);
and maybe other SOLID violations that I missed.
How can this be better implemented?
What I would do is introduce another class for "Exporting" your vehicle.
Something like this.
public class VehicleExporter
{
public string ExportAsJson(Vehicle vehicle)
{
// Do the JSON thing
}
public string ExportAsXML(Vehicle vehicle)
{
// Do the XML thing
}
}
The big thing with your design is not as much breaking the open closed principle, but the responsibility of the vehicle class.
When your class is doing the toString(), it is essentially trying to do something outside of it's responsibility.
Please let me know if I can clarify further.
Related
I would like to ask if the decorator pattern suits my needs and is another way to make my software design much better?
Previously I have a device which is always on all the time. On the code below, that is the Device class. Now, to conserve some battery life, I need to turn it off then On again. I created a DeviceWithOnOffDecorator class. I used decorator pattern which I think helped a lot in avoiding modifications on the Device class. But having On and Off on every operation, I feel that the code doesn't conform to DRY principle.
namespace Decorator
{
interface IDevice
{
byte[] GetData();
void SendData();
}
class Device : IDevice
{
public byte[] GetData() {return new byte[] {1,2,3 }; }
public void SendData() {Console.WriteLine("Sending Data"); }
}
// new requirement, the device needs to be turned on and turned off
// after each operation to save some Battery Power
class DeviceWithOnOffDecorator:IDevice
{
IDevice mIdevice;
public DeviceWithOnOffDecorator(IDevice d)
{
this.mIdevice = d;
Off();
}
void Off() { Console.WriteLine("Off");}
void On() { Console.WriteLine("On"); }
public byte[] GetData()
{
On();
var b = mIdevice.GetData();
Off();
return b;
}
public void SendData()
{
On();
mIdevice.SendData();
Off();
}
}
class Program
{
static void Main(string[] args)
{
Device device = new Device();
DeviceWithOnOffDecorator devicewithOnOff = new DeviceWithOnOffDecorator(device);
IDevice iDevice = devicewithOnOff;
var data = iDevice.GetData();
iDevice.SendData();
}
}
}
On this example: I just have two operations only GetData and SendData, but on the actual software there are lots of operations involved and I need to do enclose each operations with On and Off,
void AnotherOperation1()
{
On();
// do all stuffs here
Off();
}
byte AnotherOperation2()
{
On();
byte b;
// do all stuffs here
Off();
return b;
}
I feel that enclosing each function with On and Off is repetitive and is there a way to improve this?
Edit: Also, the original code is in C++. I just wrote it in C# here to be able to show the problem clearer.
Decorator won't suite this purpose, since you are not adding the responsibility dynamically. To me what you need to do is intercept the request and execute on() and off() methods before and after the actual invocation. For that purpose write a Proxy that wraps the underlying instance and do the interception there while leaving your original type as it is.
Hi when you have a method with same signature let's say.
void getErrorMessage(int errorCode){
}
void getErrorMessage(int domain){
}
I know I have to change the name or differentiate the parameter but what would be the best way to approach?
---------------------------Edited.
How about for constructor?
For example
public ErrorMessage(int errorCode){
}
public ErrorMessage(int domain){
}
You could make the method name explicit:
getErrorByErrorCode(int errorCode)
And
getErrorByDomain(int domain)
You can add a "ByFoo" to the end of the method, like: getErrorMessageByCode or getErrorMessageByDomain
The least dangerous and easiest-to-understand way to do this is:
public class ErrorCode {
private int intCode;
ErrorCode(int intCode) {
this.intCode = intCode;
}
int getIntegerCode() {
return intCode;
}
}
public class Domain {
private int domain;
Domain(int domain) {
this.domain = domain;
}
int getIntegerCode() {
return domain;
}
}
Message getErrorMessage(ErrorCode errorCode)
Message getErrorMessage(Domain domain)
Note the classes are immutable. You should probably also override equals. Use these classes everywhere you would have used the integer values.
Now it is impossible to mistake an error code for a domain anywhere in your code. If you mistake one for the other you will get a compiler error, and the compiler will choose the correct implementation of getErrorMessage. You extract the integer value from the object only when you need to perform integer operations on it.
I have a question to OOP in general. I'd like to demonstrate a snippet of code:
public class Test
{
private int someInt = 0;
public Test()
{
this.method1(this);
this.method2(this.getSomeInt());
}
public void method1(Test test)
{
System.out.print(test.getSomeInt());
}
public void method2(int someInt)
{
System.out.print(someInt);
}
public int getSomeInt()
{
return this.someInt;
}
}
My question here: Which of those two function calls is more efficient? Does it matter if I use the getter as a parameter or should I give the object as the parameter from the beginning? Could you explain which one I should prefer because I don't really know what to stick to. The object seems to be too big as a parameter, the parameters look too cascaded. I apologize in advance if any related question has been asked already, I didn't know what to look for. ,_,
I want to implement a magic token for my ServiceStack-based API. Whenever any value matches this special token, I'd like to signal special actions in my application. The ideal place for this assignment to occur would be after SS had processed the wire format (JSV, JSON, SOAP, etc.) and before it mapped the value onto the a .NET type. At the moment, I'm wondering about the best way to start on something like this. Is it something I could wire up in Configure()? Is it something I'll have to override and inject? Any assistance or direction in this matter would be appreciated, ASAP.
I don't see this as a ServiceStack implementation question, but rather a matter of how you define your DTOs. Given this requirement, as I understand it, I'd go with something like this:
interface IOverridableDTO
{
Object overrideValue(Object value);
}
class BaseOverridableDTO : IOverridableDTO
{
bool doOverride {get(){return(//results of magic token check)};}
public Object overrideValue(Object value)
{ if {doOverride}
return(null); // or whatever the override needs to be
return(value);
}
}
class MyDTO : BaseOverridableDTO
{
// override the overrideValue() method, if necessary
private int myDTOProperty;
public int? MyDTOProperty {
get() {return overrideValue((Object)myDTOProperty)};
set(int value) {myDTOProperty = value;}
}
}
// use as follows:
void DoSomethingWithAnOverridableDTO(BaseOverridableDTO dtoObject)
{ ... }
I have a GiftCouponPayment class. It has a business strategy logic which can change frequently - GetCouponValue(). At present the logic is “The coupon value should be considered as zero when the Coupon Number is less than 2000”. In a future business strategy it may change as “The coupon value should be considered as zero when the Coupon Issued Date is less than 1/1/2000”. It can change to any such strategies based on the managing department of the company.
How can we refactor the GiftCouponPayment class using Strategy pattern so that the class need not be changed when the strategy for GetCouponValue method?
UPDATE: After analyzing the responsibilities, I feel, "GiftCoupon" will be a better name for "GiftCouponPayment" class.
C# CODE
public int GetCouponValue()
{
int effectiveValue = -1;
if (CouponNumber < 2000)
{
effectiveValue = 0;
}
else
{
effectiveValue = CouponValue;
}
return effectiveValue;
}
READING
Strategy Pattern - multiple return types/values
GiftCouponPayment class should pass GiftCoupon to different strategy classes. So your strategy interface (CouponValueStrategy) should contain a method:
int getCouponValue(GiftCoupon giftCoupon)
Since each Concrete strategy implementing CouponValueStrategy has access to GiftCoupon, each can implement an algorithm based on Coupon number or Coupon date etc.
You can inject a "coupon value policy" into the coupon object itself and call upon it to compute the coupon value. In such cases, it is acceptable to pass this into the policy so that the policy can ask the coupon for its required attributes (such as coupon number):
public interface ICouponValuePolicy
{
int ComputeCouponValue(GiftCouponPayment couponPayment);
}
public class GiftCouponPayment
{
public ICouponValuePolicy CouponValuePolicy {
get;
set;
}
public int GetCouponValue()
{
return CouponValuePolicy.ComputeCouponValue(this);
}
}
Also, it seems like your GiftCouponPayment is really responsible for two things (the payment and the gift coupon). It might make sense to extract a GiftCoupon class that contains CouponNumber, CouponValue and GetCouponValue(), and refer to this from the GiftCouponPayment.
When your business - logic changes, it's quite natural that your code will have to change as well.
You could perhaps opt to move the expiration-detection logic into a specification class:
public class CouponIsExpiredBasedOnNumber : ICouponIsExpiredSpecification
{
public bool IsExpired( Coupon c )
{
if( c.CouponNumber < 2000 )
return true;
else
return false;
}
}
public class CouponIsExpiredBasedOnDate : ICouponIsExpiredSpecification
{
public readonly DateTime expirationDate = new DateTime (2000, 1, 1);
public bool IsExpired( Coupon c )
{
if( c.Date < expirationDate )
return true;
else
return false;
}
}
public class Coupon
{
public int GetCouponValue()
{
ICouponIsExpiredSpecification expirationRule = GetExpirationRule();
if( expirationRule.IsExpired(this) )
return 0;
else
return this.Value;
}
}
The question you should ask yourself: is it necessary to make it this complex right now ? Can't you make it as simple as possible to satisfy current needs, and refactor it later, when the expiration-rule indeed changes ?
The behavior that you wish to be dynamic is the coupon calculation - which can dependent on any number of things: coupon date, coupon number, etc. I think that a provider pattern would be more appropriate, to inject a service class which calculates the coupon value.
The essence of this is moving the business logic outside of the GiftCouponPayment class, and using a class I'll call "CouponCalculator" to encapsulate the business logic. This class uses an interface.
interface ICouponCalculator
{
int Calculate (GiftCouponPayment payment);
}
public class CouponCalculator : ICouponCalculator
{
public int Calculate (GiftCouponPayment payment)
{
if (payment.CouponNumber < 2000)
{
return 0;
}
else
{
return payment.CouponValue;
}
}
}
Now that you have this interface and class, add a property to the GiftCouponPayment class, then modify your original GetCouponValue() method:
public class GiftCouponPayment
{
public int CouponNumber;
public int CouponValue;
public ICouponCalculator Calculator { get; set; }
public int GetCouponValue()
{
return Calculator.Calculate(this);
}
}
When you construct the GiftCouponPayment class, you will assign the Calculator property:
var payment = new GiftCouponPayment() { Calculator = new CouponCalculator(); }
var val = payment.GetCouponValue(); // uses CouponCalculator class to get value
If this seems like a lot of work just to move the calculation logic outside of the GiftCouponPayment class, well, it is! But if this is your requirement, it does provide several things:
1. You won't need to change the GiftCouponPayment class to adjust the calculation logic.
2. You could create additional classes that implement ICalculator, and a factory pattern to decide which class to inject into GiftCouponPayment when it is constructed. This speaks more to your original desire for a "strategy" pattern - as this would be useful if the logic becomes very complex.