I'm not sure whether I'm violating OOP conepts insanely.
Say there is a Carclass which "has" an Engine and a Tank.
When the Engine is operating , it will take oil from the Tank (say unit by unit per a cycle though oil is uncountable)
How should the Engine get Oil from the Tank ? (When both are fields of Car?)
Actually an Engine should be continually " Supplied" oil rather
than "gets" oil. There should be "OilCirculatingSystem" which gets Oil from the Tank
and supplies to Engine.How can I model this system in classes ?
Is there a suitable Design Pattern?
** * Edit : Simply ,how to have an "Flow of Oil" from Tank to Engine ? (Is it Oil's responsibility to flow from the Tank to Engine when a valve is opened ?
I'm sorry if it fries the brain. Implementation of methods is missing but you get the idea I hope.
class Tank
{
Oil oil;
public Tank(OilPipe pipe)
{
pipe.OilNeeded += new EventHandler<OilNeededEventArgs>(pipe_OilNeeded);
}
public void FillOil(Oil oil) { }
void pipe_OilNeeded(object sender, OilNeededEventArgs e)
{
e.Oil = oil.SubtractLiters(5);
}
}
class OilPipe
{
public event EventHandler<OilNeededEventArgs> OilNeeded;
public Oil SuckOil();
}
class Piston
{
public void Move() { }
}
class Oil
{
public Energy Burn() { }
}
class Energy
{
public void Push(Piston piston) { }
}
class Engine
{
OilPipe oilPipe;
public Engine(OilPipe oilPipe, Piston piston)
{
this.oilPipe = oilPipe;
}
public void MovePiston()
{
Oil oil = oilPipe.SuckOil();
Energy energy = Burn(oil);
energy.Push(piston);
}
}
class Car
{
Engine engine;
public Car(Engine engine, Tank tank)
{
}
public void Accelerate()
{
engine.MovePiston();
}
}
Car analogies are never perfect, because cars and engines are actually very complex systems. You have to ignore a lot of things to model them simply. Your problem is that you don't seem to understand how an engine works in the first place.
The oil pan is part of the engine, not the car. The gas tank is part of the car, but not the engine. You have an oil pump (also part of the engine) that pumps oil into the cylinders of the engine. Most cars (maybe all) don't "check the oil level" and refuse to start. The engine will simply seize if it doesn't get enough oil. Likewise, if it doesn't get enough gas, it doesn't check the gas tank level.. it just runs out of fuel.
It would be more like this:
class Car
{
Engine engine;
GasTank gasTank;
StartEngine() { engine.Start(); }
}
class Engine
{
Timer timer;
OilPan oilPan;
OilPump oilPump;
public Engine() { oilPump = new OilPump(oilPan, this); }
Start() { timer.Start(oilPump); }
InjectOil() {}
}
class Timer
{
OilPump op; // This is a reference
public Timer(OilPump op) { _op = op; }
Revolve() { op.Pump(); }
}
class OilPump {
OilPan _oilPan; // Reference
Engine _engine; // Reference
OilPump(OilPan oilPan, Engine engine) { _oilPan = oilPan; _engine = engine; }
Pump() { _engine.InjectOil(_oilPan.GetOil); }
}
The timer reprsents the revolution of the engine, as it revolves, it actuates the oil pump which pumps oil into the cylinders. Oil is not typically "consumed", like fuel. It is recycled. It can break down over time, and in some engines that are in bad shape, it can burn.
The Oil Pump reference represents a mechanical linkage between the engine and the oil pump (typically gears turn it). The Timer does not have an oil pump, it has a reference to an oil pump.
The gas tank would work in a similar fashion.
Again, this is all imperfect (very imperfect), because there is so much missing.
I would say that the Car itself is the OilCirculatingSystem.
class Car
{
Tank tank;
Engine engine;
start()
{
//whatever
}
feedEngine()
{
while ( tank.hasOil() )
{
tank.getOil();
engine.giveOil();
}
}
}
The Car itself is already the the class connecting all your components together, why would you need another one?
The fact that the supply is continuous means that it will have to be checked after a specified time interval. If this is not what you are looking for, you may have to clarify your question.
The most logical approach to this problem (assuming you dont have event-based or signal/slot programming) would to have the car check the state of the engine, every time interval of your choice, and if the engine needs more oil, the car should read some data from the tank and pass it to the engine.
Here is a simple pseudocode example to demonstrate what I mean:
class Engine
{
void start()
{
while(true)
{
// do engine stuff here
}
}
void getOil(int amount)
{
// do stuff with oil
}
}
class Tank
{
int oilAmount
boolean hasOil
int giveOil()
{
return oilAmount
}
}
class Car
{
Tank tank
Engine engine
void start()
{
engine.start()
while(true)
{
engine.getOil(tank.giveOil())
sleep(100)
}
}
}
Related
I am new to Reactive programming and Spring WebFlux. I want to make my App 1 publish Server Sent event through Flux and my App 2 listen on it continuously.
I want Flux publish on-demand (e.g. when something happens). All the example I found is to use Flux.interval to periodically publish event, and there seems no way to append/modify the content in Flux once it is created.
How can I achieve my goal? Or I am totally wrong conceptually.
Publish "dynamically" using FluxProcessor and FluxSink
One of the techniques to supply data manually to the Flux is using FluxProcessor#sink method as in the following example
#SpringBootApplication
#RestController
public class DemoApplication {
final FluxProcessor processor;
final FluxSink sink;
final AtomicLong counter;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
public DemoApplication() {
this.processor = DirectProcessor.create().serialize();
this.sink = processor.sink();
this.counter = new AtomicLong();
}
#GetMapping("/send")
public void test() {
sink.next("Hello World #" + counter.getAndIncrement());
}
#RequestMapping(produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<ServerSentEvent> sse() {
return processor.map(e -> ServerSentEvent.builder(e).build());
}
}
Here, I created DirectProcessor in order to support multiple subscribers, that will listen to the data stream. Also, I provided additional FluxProcessor#serialize which provide safe support for multiproducer (invocation from different threads without violation of Reactive Streams spec rules, especially rule 1.3). Finally, by calling "http://localhost:8080/send" we will see the message Hello World #1 (of course, only in case if you connected to the "http://localhost:8080" previously)
Update For Reactor 3.4
With Reactor 3.4 you have a new API called reactor.core.publisher.Sinks. Sinks API offers a fluent builder for manual data-sending which lets you specify things like the number of elements in the stream and backpressure behavior, number of supported subscribers, and replay capabilities:
#SpringBootApplication
#RestController
public class DemoApplication {
final Sinks.Many sink;
final AtomicLong counter;
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
public DemoApplication() {
this.sink = Sinks.many().multicast().onBackpressureBuffer();
this.counter = new AtomicLong();
}
#GetMapping("/send")
public void test() {
EmitResult result = sink.tryEmitNext("Hello World #" + counter.getAndIncrement());
if (result.isFailure()) {
// do something here, since emission failed
}
}
#RequestMapping(produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<ServerSentEvent> sse() {
return sink.asFlux().map(e -> ServerSentEvent.builder(e).build());
}
}
Note, message sending via Sinks API introduces a new concept of emission and its result. The reason for such API is the fact that the Reactor extends Reactive-Streams and has to follow the backpressure control. That said if you emit more signals than was requested, and the underlying implementation does not support buffering, your message will not be delivered. Therefore, the result of tryEmitNext returns the EmitResult which indicates if the message was sent or not.
Also, note, that by default Sinsk API gives a serialized version of Sink, which means you don't have to care about concurrency. However, if you know in advance that the emission of the message is serial, you may build a Sinks.unsafe() version which does not serialize given messages
Just another idea, using EmitterProcessor as a gateway to flux
import reactor.core.publisher.EmitterProcessor;
import reactor.core.publisher.Flux;
public class MyEmitterProcessor {
EmitterProcessor<String> emitterProcessor;
public static void main(String args[]) {
MyEmitterProcessor myEmitterProcessor = new MyEmitterProcessor();
Flux<String> publisher = myEmitterProcessor.getPublisher();
myEmitterProcessor.onNext("A");
myEmitterProcessor.onNext("B");
myEmitterProcessor.onNext("C");
myEmitterProcessor.complete();
publisher.subscribe(x -> System.out.println(x));
}
public Flux<String> getPublisher() {
emitterProcessor = EmitterProcessor.create();
return emitterProcessor.map(x -> "consume: " + x);
}
public void onNext(String nextString) {
emitterProcessor.onNext(nextString);
}
public void complete() {
emitterProcessor.onComplete();
}
}
More info, see here from Reactor doc. There is a recommendation from the document itself that "Most of the time, you should try to avoid using a Processor. They are harder to use correctly and prone to some corner cases." BUT I don't know which kind of corner case.
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.
Is it possible to morph an object at runtime depending on its current state and keep all past information?
Say I have the following (in pseudo-code):
class Vehicle {
int state, lat, long;
void run();
}
class Plane : Vehicle {
void run() {fly();}
}
class Car : Vehicle {
void run() {drive();}
}
class Boat : Vehicle {
void run() {navigate();}
}
void main() {
// Setup code goes here
Vehicle vehicle = new Vehicle();
while(true) {
switch(vehicle->state){
case(1): vehicle = new Plane();
case(2): vehicle = new Car();
case(3): vehicle = new Boat();
}
}
}
It is not possible in the sense you've wrote it, but it is possible to design system with behavior you want:
You have one object, it is the same object during runtime
Object has different behaviors
Current behavior is based on current state
Its small, but very important difference with what you wrote in question, in this approach we're not morphing object, but it's behavior only
There are could be multiple different implementations, depending on full set of requirements, here is simplest one, assuming that behavior changes position only:
class Position {
int lat, long;
}
interface PositionCalculator {
Position calc(Position old);
}
class Vehicle {
private Position pos;
void modify(PositionCalculator calc) {pos = calc.calc(pos);}
}
class CarCalculator : PositionCalculator {
Position calc(Position old) {return navigate(old);}
}
class PlaneCalculator : PositionCalculator {
Position calc(Position old) {return fly(old);}
}
void main() {
Vehicle vehicle = new Vehicle();
PositionCalculator plane = new PlaneCalculator()
PositionCalculator car = new CarCalculator();
while(true) {
if (vehicle is in air)
vehicle.modify(plane);
else if (vehicle is on road)
vehicle.modify(car);
}
}
I've been dabbling in Dlang recently as C++ just wasn't quite sitting right with me after having used Python for so long. While dabbling, I came across what I thought would be a very simple exercise in polymorphism. I suppose how you would expect something to work and what it actually does are two entirely different things for reasons an end user probably can't comprehend. That being said, here is the source code of my "sandbox.D":
import std.stdio;
class Animal {
string voice = "--silence--";
void speak() {
writeln(this.voice);
}
}
class Dog : Animal {
string voice = "Whoof!";
}
int main() {
auto a = new Animal();
auto d = new Dog();
writeln(a.voice); // Prints "--silence--"
writeln(d.voice); // Prints "Whoof!"
a.speak(); // Prints "--silence--"
d.speak(); // Prints "--silence--" NOT "Whoof!"
return 0;
}
I guess my issue is why the "this" keyword just doesn't seem to be functioning how you would expect it to in the C++ successor language.
Methods are polymorphic, variables aren't. So instead of making the voice a variable, you want to override speak in the child.
Also, the auto return type doesn't work with polymorphism, you need to actually specify the types. (The reason is that auto return makes a function template in the compiler, which in theory could have multiple overridable slots in the function table, so it just doesn't try to put it in.)
So try this out:
import std.stdio;
class Animal {
void speak() { // changed to void instead of auto
writeln("--silence--");
}
}
class Dog : Animal {
override void speak() { // the override tells it to override the base method
writeln("woof");
}
}
int main() {
auto d = new Dog();
d.speak();
return 0;
}
If you have a lot of shared functionality and want to reuse one function with slight changes in child classes, you might make a method instead of a variable that just returns something.
Like string voice() { return "woof"; }, then it can be overridden in children.
Another way is to use template this parameter:
import std.stdio;
class Animal {
string voice;
void speak(this C)() {
writeln((cast(C)this).voice);
}
}
class Dog : Animal {
string voice = "Whoof!";
}
int main() {
auto a = new Animal();
auto d = new Dog();
a.speak(); // Prints ""
d.speak(); // Prints "Whoof!"
return 0;
}
Or when you do not need to have voice as a member:
import std.stdio;
class Animal {
static immutable voice = "";
void speak(this C)() {
writeln(C.voice);
}
}
class Dog : Animal {
static immutable voice = "Whoof!";
}
int main() {
auto a = new Animal();
auto d = new Dog();
a.speak(); // Prints ""
d.speak(); // Prints "Whoof!"
return 0;
}
so I am trying to write a discounts method that will apply discount(s) on a product.
The current vanilla code goes like so:
void ApplyDiscount(List<DiscountRule> discountRules, Product objProduct)
{
foreach (var discountRule in discountRules)
{
// this is a very simple way of deciding on the available discounts
if (discountRule.Type==DiscountType.Percent)
{
// Process for percentage discount
}
if (discountRule.Type==DiscountType.Free)
{
// Process for flat discount
}
// and so on , there are like 5 more types,
// not mentioned here for the case of brevity.
}
}
What this method does is take a list of discount rules and apply on the product.
The discount rules are fetched by executing a SP # the server and that returns the
available discounts for that product.
The code review for this resulted in the following comment:
Please use an interface based approach and try to get rid of the IFs!
I can get rid of the IFs but they will be replaced by SWITCH.
How do I go about using an interface?
May be this question is not constructive, but I would want to know if some OOPs gurus here can guide me in writing this better.
Regards.
An interface / virtual-dispatch approach might look something like this:
// First we loosely define how a "discount" can be used.
// This could also be an abstract class, if common base-class
// functionality is desired.
public interface IDiscount
{
// This is called to apply this discount to a particular product
void ApplyDiscount(Product product);
}
// Here's one implementation that applies a percentage discount
public class PercentDiscount : IDiscount
{
private decimal m_percent;
public PercentDiscount(decimal percent) {
m_percent = percent;
}
#region IDiscount implementation
public void ApplyDiscount(Product product) {
product.Price -= product.Price * m_discount;
}
#endregion
}
// Here's another implementation that makes a product free
public class FreeDiscount : IDiscount
{
public FreeDiscount() {
}
#region IDiscount implementation
public void ApplyDiscount(Product product) {
product.Price = 0;
}
#endregion
}
public class SomeClass {
// Now applying the discounts becomes much simpler! Note that this function
// takes a collection of IDiscounts, and applies them in a consistent way,
// by just calling IDiscount.ApplyDiscount()
void ApplyDiscounts(IEnumerable<IDiscount> discounts, Product product) {
foreach (var discount in discounts) {
discount.ApplyDiscount(product);
}
}
}
Note that I also changed ApplyDiscounts to take an IEnumerable<T> instead of List<T>. This allows any arbitrary collection type to be passed, and also doesn't allow the function to inadvertently modify the collection.