i'am not sure about special case of LSP.
Actually child should extend implementation of parent and not change it.
For me means extension, that i add new lines in child implementation to parent
implementation within child class.
But what about, when i completely override parent-implementation and it provides
result too?
Parent is:
public class Calculator {
public void computeProfit(){
int profit = 2+2;
}
}
Child is:
public class SpecialCalculator extends Calculator {
#Override
public void computeProfit(){
//overriding completely parent-implementation
int profit = Math.pow(2) * 5;
}
}
has LSP still been preserved?
TL;DR; In you example LSP is preserved.
IMO the thing with SOLID principles it that it is a mnemonic for dynamic polymorphism so the end goal for your code is to enable something like this
public void SomeBusinessLogic(Calculator calc) {
calc.computeProfit() // SpecialCalculator might go here as well
}
Your code is perfectly fit for this.
This however would violate LSP
public class SpecialCalculator extends Calculator {
public void computeProfitClevrly(){
//overriding completely parent-implementation
int profit = Math.pow(2) * 5;
}
}
because now you'll have to do something like
public void SomeBusinessLogic(Calculator calc) {
if (calc is SpecialCalculator)
calc.computeProfitCleverly() // SpecialCalculator might go here as well
}
P.S. There are some more subtle cases of LSP violation. I.e. when base class is ImmutablePoint and a child class is a point that might be mutated.
Related
This question already has answers here:
How to make a Java class that implements one interface with two generic types?
(9 answers)
Closed 8 years ago.
I have the following interface, which I want to implement multiple times in my classes:
public interface EventListener<T extends Event>
{
public void onEvent(T event);
}
Now, I want to be able to implement this interface in the following way:
class Foo implements EventListener<LoginEvent>, EventListener<LogoutEvent>
{
#Override
public void onEvent(LoginEvent event)
{
}
#Override
public void onEvent(LogoutEvent event)
{
}
}
However, this gives me the error: Duplicate class com.foo.EventListener on the line:
class Foo implements EventListener<LoginEvent>, EventListener<LogoutEvent>
Is it possible to implement the interface twice with different generics? If not, what's the next closest thing I can do to achieve what I'm trying to do here?
Is it possible to implement the interface twice with different generics
Unfortunately no. The reason you can't implement the same interface twice is because of type erasure. The compiler will handle type parameters, and a runtime EventListener<X> is just a EventListener
If not, what's the next closest thing I can do to achieve what I'm trying to do here?
Type erasure can work in our favor. Once you know that EventListener<X> and EventListener<Y> are just raw EventListener at run-time, it is easier than you think to write an EventListener that can deal with different kinds of Events. Bellow is a solution that passes the IS-A test for EventListener and correctly handles both Login and Logout events by means of simple delegation:
#SuppressWarnings("rawtypes")
public class Foo implements EventListener {
// Map delegation, but could be anything really
private final Map<Class<? extends Event>, EventListener> listeners;
// Concrete Listener for Login - could be anonymous
private class LoginListener implements EventListener<LoginEvent> {
public void onEvent(LoginEvent event) {
System.out.println("Login");
}
}
// Concrete Listener for Logout - could be anonymous
private class LogoutListener implements EventListener<LogoutEvent> {
public void onEvent(LogoutEvent event) {
System.out.println("Logout");
}
}
public Foo() {
#SuppressWarnings("rawtypes")
Map<Class<? extends Event>, EventListener> temp = new HashMap<>();
// LoginEvents will be routed to LoginListener
temp.put(LoginEvent.class, new LoginListener());
// LogoutEvents will be routed to LoginListener
temp.put(LogoutEvent.class, new LogoutListener());
listeners = Collections.unmodifiableMap(temp);
}
#SuppressWarnings("unchecked")
#Override
public void onEvent(Event event) {
// Maps make it easy to delegate, but again, this could be anything
if (listeners.containsKey(event.getClass())) {
listeners.get(event.getClass()).onEvent(event);
} else {
/* Screams if a unsupported event gets passed
* Comment this line if you want to ignore
* unsupported events
*/
throw new IllegalArgumentException("Event not supported");
}
}
public static void main(String[] args) {
Foo foo = new Foo();
System.out.println(foo instanceof EventListener); // true
foo.onEvent(new LoginEvent()); // Login
foo.onEvent(new LogoutEvent()); // Logout
}
}
The suppress warnings are there because we are "abusing" type erasure and delegating to two different event listeners based on the event concrete type. I have chosen to do it using a HashMap and the run-time Event class, but there are a lot of other possible implementations. You could use anonymous inner classes like #user949300 suggested, you could include a getEventType discriminator on the Event class to know what do to with each event and so on.
By using this code for all effects you are creating a single EventListener able to handle two kinds of events. The workaround is 100% self-contained (no need to expose the internal EventListeners).
Finally, there is one last issue that may bother you. At compile time Foo type is actually EventListener. Now, API methods out of your control may be expecting parametrized EventListeners:
public void addLoginListener(EventListener<LoginEvent> event) { // ...
// OR
public void addLogoutListener(EventListener<LogoutEvent> event) { // ...
Again, at run-time both of those methods deal with raw EventListeners. So by having Foo implement a raw interface the compiler will be happy to let you get away with just a type safety warning (which you can disregard with #SuppressWarnings("unchecked")):
eventSource.addLoginListener(foo); // works
While all of this may seem daunting, just repeat to yourself "The compiler is trying to trick me (or save me); there is no spoon <T>. Once you scratch your head for a couple of months trying to make legacy code written before Java 1.5 work with modern code full of type parameters, type erasure becomes second nature to you.
You need to use inner or anonymous classes. For instance:
class Foo {
public EventListener<X> asXListener() {
return new EventListener<X>() {
// code here can refer to Foo
};
}
public EventListener<Y> asYListener() {
return new EventListener<Y>() {
// code here can refer to Foo
};
}
}
This is not possible.
But for that you could create two different classes that implement EventListener interface with two different arguments.
public class Login implements EventListener<LoginEvent> {
public void onEvent(LoginEvent event) {
// TODO Auto-generated method stub
}
}
public class Logout implements EventListener<LogoutEvent> {
public void onEvent(LogoutEvent event) {
// TODO Auto-generated method stub
}
}
As a part of trying to tackle a memory leak in our application, we discovered that for every SkinnableComponent, the skinDestructionPolicy is set to "never" by default.
This means that when using static skin parts, the skin is forever detained in memory.
Furthermore, the override of a partRemoved() in the host component will never be triggered.
Hence, event listeners we add in the partAdded() override are not removed, which effectively causes views and skins to be kept in memory.
When doing a lot of view switches this is just not acceptable.
Here is an example of of how we are working around this now:
public class ViewA extends SkinnableComponent
{
[SkinPart(required = "true")]
public var labelA:Label;
[SkinPart(required = "true")]
public var buttonA:Button;
public function ViewA()
{
super();
mx_internal::skinDestructionPolicy = 'auto';
}
override protected function getCurrentSkinState():String
{
return super.getCurrentSkinState();
}
override protected function partAdded(partName:String, instance:Object):void
{
super.partAdded(partName, instance);
trace("ViewA::partAdded " + partName);
if (instance == buttonA)
{
buttonA.addEventListener(MouseEvent.CLICK, buttonClickedHandler);
}
}
override protected function partRemoved(partName:String, instance:Object):void
{
trace("ViewA::partRemoved " + partName);
if (instance == buttonA)
{
buttonA.removeEventListener(MouseEvent.CLICK, buttonClickedHandler);
}
super.partRemoved(partName, instance);
}
override public function stylesInitialized():void
{
setStyle("skinClass", ViewASkin);
}
}
However, using the mx::internal way to circumvent this behavior seems rather odd to me.
Documentation about this is scarce as well, so any ideas will be very welcome.
Cheers
In my experience the usage of the mx::internal namespace in the Flex SDK usually means something along the lines of: "you can use this functionality, if you know what you're doing, and also we (Adobe, or the Apache community in the future) don't guarantee that this API will never change in future versions of Flex".
So there's no real issue with its usage, unless you're very concerned with backwards compatibility. If you really want to avoid using it, you can always just implement the behavior of skinDestructionPolicy="auto" in your subclass. There's not that much code to write:
override public function initialize():void {
addEventListener(Event.ADDED_TO_STAGE, addedToStageHandler);
addEventListener(Event.REMOVED_FROM_STAGE, removedFromStageHandler);
super.initialize();
}
private function addedToStageHandler(event:Event):void {
if (skin == null) attachSkin();
}
private function removedFromStageHandler(event:Event):void {
detachSkin();
}
Note that in the SkinnableComponent class these two event listeners are attached (or not, depending on the policy) in the commitProperties() method. I moved that to the initialize() method because we don't need to check for changes in the skinDestructionPolicy property anymore.
Also note that this solution might cause an error if one did set mx::internal skinDestructionPolicy to "auto" alongside.
I sell products throgh my website. Recently we've been given a list of rules that need to be checked against each order, to make sure it's not fraudulent. So this list of rules/fraud indicators will change and grow so I want to make sure it's easily maintainable and really solid.
I'm thinking I have an abstract class rule that each of the rules implements.
abstract class Rule
{
public string Message;
public bool Success;
public void CheckOrder(OrderItem currentOrder);
}
class FakeCreditCardNumberRule : Rule
{
public string Message = "Fake CC Number Rule";
public void CheckOrder(OrderItem currentOrder)
{
currentOrder.CreditCardNumber = "1234-5678-9012-3456";
Success = false;
}
}
class ReallyLargeOrderRule : Rule
{
public string Message = "Really Large Order Rule";
public void CheckOrder(OrderItem currentOrder)
{
currentOrder.ItemsOrder.Count > 100;
Success = false;
}
}
Then I'm thinking of having a class that accepts an Order object in it's costructor and checks though the list of rules. Something like:
class FraudChecker
{
List<Rule> rules;
public FraudChecker(OrderItem currentOrder)
{
foreach(var rule in rules)
{
rule.CheckOrder(currentOrder);
}
}
}
So I was trying to think of the best place/best way to populate the FraudChecker
.Rules list and started thinking there might be some nice design pattern that does something like what I'm doing.
Has anyone seen a design pattern I should use here? Or can anyone think of a good place to populate this list?
-Evan
Specification Pattern
I've been dealing with a very similar issue.
I've found the Specification Pattern to be particularly useful.
For me the main benefits of the pattern is the way it incorporates chaining.
The link above provides a basic overview, and the related links in the article are useful too. After, if you do some more searching you'll find more detailed examples.
You have already used the Startegy pattern... I believe a factory pattern can solve your problem.
Link
I would probably go with my own implementation of enum. I would create a class like this:
public sealed class Rules
{
public static readonly Rule FakeCreditCardNumberRule = new FakeCreditCardNumberRule ();
public static readonly Rule ReallyLargeOrderRule = new ReallyLargeOrderRule ();
//here I would write more
private static readonly List<Rule> _all = List<Rule> { FakeCreditCardNumberRule, ReallyLargeOrderRule };
//every time you add new rule to the class you have to add it to the _all list also
public static IEnumerable<Rule> All
{
get
{
return _all;
}
}
public static FraudChecker(OrderItem currentOrder)
{
foreach(var rule in All)
{
rule.CheckOrder(currentOrder);
}
}
}
and then you can use it like this:
Rules.FraudChecker(currentOrder);
or
Rules.FakeCreditCardNumberRule.CheckOrder(currentOrder);
You can add every new rule to the Rules class. You can also create new methods in it that will process only part of the Rules and so on.
I'm coding a business layer for an ASP.NET application. I've created database methods in my BLL as static. I've created public static Func variables to be compiled and used in several different methods, like this:
namespace BLL
public class User
{
public static Func<Context, variable, result> selectUser;
private static void CompileQuery()
{
if(selectUser == null)
{
selectUser = CompiledQuery.Compile......
}
}
public static UserClass Select(int id)
{
CompileQuery();
//uses selectUser
}
public static SomethingElse DoSomethingElse()
{
CompileQuery();
//also uses selectUser
}
}
It'll be used in ASP.NET layer like this:
using BLL;
private void AddUser()
{
UserClass user = User.Select(id);
}
My question is, since static variables are not thread-safe, is this a bad design decision? I'm thinking of either implementing a locking mechanism, which makes me think if it'd slow down the application, or using instantiated class approach which makes me wonder if query compiling would be beneficial. I'd appreciate any advice on this.
It should at least be read-only - and initialized on type load, like this:
public static readonly Func<Context, variable, result> selectUser =
CompileQuery(); // Or inline this...
private static Func<Context, variable, result> CompileQuery()
{
return CompiledQuery.Compile(...);
}
I'd probably make it a property myself, but otherwise it should be okay. Delegates themselves are immutable and threadsafe, so that shouldn't be a problem.
Doing it on type initialization means you don't need to worry about locking: the CLR guarantees that a type initializer is executed once and only once.
I'm wondering (based on scoping rules) how I might do the following:
I want to draw to a sprite that exists on the main stage in which I have a class instantiated.
So something like
public function MyClass(reference:String){
this.reference = reference;
}
public function drawToOutsideSprite(){
this.parent.getChildByName(this.reference).addChild(someLoaderName);
}
Would I use super() in this case, or what's the usual methodology?
Thanks,
jml
There are a few ways to do this. I'm assuming your MyClass extends Sprite.
package
{
import flash.display.DisplayObject;
import flash.display.DisplayObjectContainer;
import flash.display.Sprite;
/**
* MyClass
*/
public class MyClass extends Sprite
{
public var referenceA:String;
public var referenceB:Sprite;
public function get referenceA_way2():Sprite
{
return this.parent.getChildByName(referenceA);
}
/**
* MyClass Constructor
*/
public function MyClass(referenceA:String = null, referenceB:Sprite = null)
{
super();
this.referenceA = referenceA;
this.referenceB = referenceB;
}
public function drawToOutsideSpriteA(child:DisplayObject):void
{
// referenceA
this.parent.getChildByName(this.referenceA).addChild(child);
// or
referenceA_way2.addChild(child);
}
public function drawToOutsideSpriteB(child:DisplayObject):void
{
// referenceB
referenceB.addChild(child);
}
public function drawToOutsideSpriteC(referenceC:String, child:DisplayObject):void
{
this.parent.getChildByName(referenceC).addChild(child);
}
// Do this:
// it allows you to abstract out the logic of getting the main sprite
// into some util class, so you could reuse that functionality elsewhere,
// and so your code is cleaner.
public function drawToOutsideSpriteD(child:DisplayObject):void
{
StageUtil.getMainSprite().addChild(child);
}
}
}
package
{
import flash.display.DisplayObject;
import flash.display.DisplayObjectContainer;
import flash.display.Sprite;
/**
* MyClass
*/
public class StageUtil
{
private static var root:Stage;
/**
* Called when app first starts
*/
public static function initialize(stage:Stage):void
{
root = stage;
}
public static function getMainSprite():DisplayObjectContainer
{
return root; // or something more complex,
// like a recursive function to getSpriteByName
}
public static function addToStage(child:DisplayObject):DisplayObject
{
return getMainSprite().addChild(child);
}
}
}
In general I would abstract out the logic for getting the "main" sprite into some util/manager class, because you don't want to hardcode that into your MyClass, as you might need it in other places, and you might want to customize it later on. It sounds like your just asking what's the best way to reference sprites outside of the scope of the MyClass, so I say just put it into the Util, assuming it has good reason for being their (like FlexGlobals.topLevelApplication in Flex, so you can easily access the application).
I don't recommend passing in id's or name's into the constructor and doing it that way, I don't really recommend constructor arguments at all. I would just pass those into a method if you needed to, or have it built into the class itself, or the Util.
To clear up the scoping question a little... You normally don't want to draw to sprites outside the scope of the class you are in, unless they have some special functionality that will be referenced by multiple classes with totally different scopes. This is because things would start not making sense, who's being added to who. But some good examples on when to do thatinclude:
Buttons with ToolTips: Tooltips are added to the root because they appear on top of everything, but a Button could be 20 children deep, so you'd have in the Button subclass, perhaps, addToolTip(child).
PopUps: You might want to add a popup from within MyClass, but it's really being added to the stage. In flex this is like PopUpManager.addPopUp(child), just like the sample StageUtil.getMainSprite().addChild(child). You could even wrap that method so it's like the one in the class above, addToStage.
Transform/Drawing Stage: If you have some global painting stage, or place where you scale/resize things, you might want to be able to add/remove graphics from that from any class.
The super() method isn't useful in this scenario. The only time you really use super() is if you have overridden a method, and want to access the super-classes implementation. Something like this (assuming you're extending Sprite):
override public function addChild(child:DisplayObject):DisplayObject
{
if (child is MyDrawingSprite)
return StageUtil.addToStage(child); // add to main stage
else
return super.addChild(child); // add directly to this class
}
Otherwise, try to stick to just adding children directly to the "MyClass".
Hope that helps.