There are lots of SO posts advising against embedding a reference to a parent class in a child class because it creates a bi-directional link (or circular dependency) between the two classes.
Bad:
class Parent
{
public List<Child> Children;
}
class Child
{
public Child(Parent parent)
{
this.parent = parent;
}
public Parent parent;
}
It seems that the general advice is to provide a delegate pattern instead - something like this:
Good:
class Parent
{
public Parent GiveSelf() => this;
public List<Child> Children;
}
class Child
{
public Child(Parent parent)
{
GetParent = parent.GiveSelf;
}
public func<Parent> GetParent;
}
I've been using the above pattern for a while but I don't really understand why it is better than direct references.
I guess my confusion is because I am assuming that a delegate must be keeping some kind of internal reference to the parent class instance behind the scenes? So it seems to me that the above delegate pattern is just substituting a direct reference with an indirect reference and surely this elaborate pattern suffers from the same issue i.e. that the parent and child classes are still bi-directionally linked albeit by the delegate ?
Can someone help me understand or point to good post clarifying this bit?
Related
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.
The following example shows a scenario where I'm trying to implement a DI container. In this case, I'm trying to use Simple Injector or Microsoft.Extensions.DependencyInjection DI Container. I've seen code examples that start hitting around the target, such as here, but no bullseye as of yet.
Below is a general code sample that I would like to modify to use one of the aforementioned DI containers (Used Simple Injector for example). I could move the view out of the presenter constructor and set it as a property. However, I was hoping for a more eloquent solution also it is a dependency that needs to be injected.
I know .NET 4.7.2 has increased DI support functionality but the biggest benefit seems to be allowing dependencies to be easily injected into pages/user controls. For MVP architecture I need the concrete class of the page tied to its view interface so the DI container can resolve and pass into the presenter, as the presenter depends on the view. I've not seen an example of this implemented well other than Unity using its DependencyOverride, which can pass the concrete class at runtime.
public partial class UserLoginView : IUserLoginView
{
private UserLoginPresenter _userLoginPresenter;
protected override void OnLoad(EventArgs e)
{
//This is my problem:
//An error will be thrown "...contains the parameter with name
//'view' and type IUserLoginView, but IUserLoginView is not
//registered..."
_userLoginPresenter = SimpleInjectorDependencyInjector
.GetInstance<IDeveloperTestStatusPresenter>();
}
}
public class UserLoginPresenter : IUserLoginPresenter
{
private readonly IUserLoginView view;
private readonly IUserService _userService;
public UserLoginPresenter(IUserLoginView userLoginView,
IUserService userService)
{
this.view = userLoginView;
this._userService = userService;
}
public static class SimpleInjectorDependencyInjector
{
private static readonly Container container = new Container();
public static T GetInstance<T>() where T : class
{
return container.GetInstance<T>();
}
//Assume this is called from App on start
public static void RegisterClasses()
{
container
.Register<IUserLoginPresenter, UserLoginPresenter>();
container
.Register<IUserService, UserService>();
}
}
I was able to accomplish what I was looking for using Microsoft.Extensions.DependencyInjection Container.
In my MSDependencyInjector wrapper class, I used the ActivatorUtilities extension.
public static T GetService<T, I>(I interfaceInstance)
{
return ActivatorUtilities.CreateInstance<T>(container, interfaceInstance);
}
Implemented in my page's partial class I wrote:
_userLoginPresenter = MSDependencyInjector.GetService<UserLoginPresenter,
IUserLoginView>(this);
A Caveat: The 'T' parameter of createInstance wants the concrete class type not the interface. This caused hours of frustration, prompting the creation of this question in the first place. MS documentation isn't the greatest but I definitely misread.
I'm not sure how to implement something as straightforward in Simple Injector and would be interested in knowing. Based on my reading I not sure if my solution isn't something like a service locator, which depending on which camp you are from should be avoided. However, if the implementation of this can be contained for just solving the need for this MVP paradigm then it is my hope all will be well.
Below is my parent class
public class Parent
{
//This method is intercept-able using **VirtualMethodInterceptor**
public virtual void Test()
{
//Do something
}
}
Below is my child class
public class Child:Parent
{
// This method directly not intercept-able but it calls base.Test() where Test is an intercept-able method
public void Demo(){
base.Test();
}
}
Now I want to resolve an instance of Child class using Unity where Demo method will be interceptable. Actually Demo method can't be interceptable as because it's not virtual but this method internally invoke base.Test() where Test is intercept-able. So how to resolve an interceptable instance of Child class?
It doesn't work If I register child class into an unity container like below
container.RegisterType<Child>(
new Interceptor<VirtualMethodInterceptor>(),
new InterceptionBehavior<Interceptor>()
)
Make sure you have done the following:
1) You added the Interception extension like this:
container.AddNewExtension<Interception>();
2) The WillExecute property of your interception behavior class returns true.
3) You obtain the Child instance from the container. This can be done directly like this:
Child chlid = container.Resolve<Child>();
Or by having Child as a dependency for some class, and then resolving the object graph that contains this class using the container.
I'm looking for a way in java to find all classes that belongs to a certain superclass, and within that class refer to a static string with a known name (using reflection?);
public class Bar
extends ObjectInstance
{
public final static String Name = "Foo";
// more
}
From the example; there are n-occurences of classes that extend from ObjectInstance, and from all, i need the value of Name. The classes i am refering to are generated so i know for sure that there is a Name element that i can refer to, but i have no access to the generation sourcedata.
Perhaps the same question as How do you find all subclasses of a given class in Java?
This backs up my initial feeling that this can only be done like IDEs do it: by scanning everything down the tree, building your relationships as you go.
No Way.
One failing solution:
publc abstract class ObjectInstance {
public abstring String name();
private static Map<String, Class<? extends ObjectInstance> klasses =
new HashMap<>();
protected ObjectInstance() {
classes.put(name(), getClass());
}
Only collects instantiated classes! So fails.
With the idea to have the name provided by a function with return "foo";.
Collecting the class.
There are two unsatisfactory solutions:
The other way around: use the name as a factory pattern:
enum Name {
FOO(Bar.class),
BAZ(Baz.class),
QUX(Qux.class),
BAR(Foo.class);
public final Class<ObjectInstance> klass;
private Name(Class<ObjectInstance> klass) {
this.klass = klass;
}
}
Maybe as factory to create instances too.
Using a class annotation, and have a compile time scanning:
#ObjectInstanceName("foo")
public class Bar extends ObjectInstance {
}
How to apply this to your case: experiment.
There would be a more fitting solution of using your own ClassLoader, but that is far too over-engineered.
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.