Here's the code. The code in method test and test2 are different because the parameter passed to Test constructor are different. Actually, if I change any parameter to null, intellij stops reporting the duplication. Is there any way to fix this?
---- Updated --------
I pass 2 functions doing totally different things but intellij still reports duplication
public class TestMain {
public void test(int a)
{
System.out.println("haha");
System.out.println("hahaa");
TestMain testMain = new TestMain();
new Test(testMain::test3);
System.out.println("hahaaa");
}
public void test2(int a)
{
System.out.println("haha");
System.out.println("hahaa");
TestMain testMain = new TestMain();
new Test(testMain::still_dup);
System.out.println("hahaaa");
}
public void test3(int a) {
System.out.println("abc");
}
public void still_dup(int a) {
String b = "edf";
b.toLowerCase();
}
public class Test {
Test(handler h) {
}
}
public interface handler<M> {
void entitySelector(int a);
}
public static void main(String[] args) {
TestMain test = new TestMain();
test.test(1);
System.out.println("-------");
test.test2(2);
}
}
I think the best way to fix this is to replace test and test2 by a single method. You don't have to distinguish what to pass the constructor because it's the current method. This might be the reason why code duplication is reported. The methods can be replaced by a single one without problems.
I have a base abstract class, which aggregates a bunch of items in a collection:
abstract class AMyAbstract
{
List<string> Items { get; private set; }
public AMyAbstract(IEnumerable<string> items)
{
this.Items = new List<string>(items);
}
}
There are a lot of subclasses, let's name them Foo, Bar, Baz, etc. They all are immutable. Now I need a merge() method, which will merge items of two objects like this:
abstract class AMyAbstract
{
// ...
public AMyAbstract merge(AMyAbstract other)
{
// how to implement???
}
}
Foo foo1 = new Foo(new string[] {"a", "b"});
Bar bar1 = new Bar(new string[] {"c", "d"});
Foo fooAndBar = foo1.merge(bar1);
// items in fooAndBar now contain: {"a", "b", "c", "d"}
Since the objects are immutable, the merge() method should not change the state of items field, but instead it should return a new object of the class uppon which it is called. My question is: how to judiciously implement the merge() method?
Problem 1: AMyAbstract is clearly not aware of specific constructors of the subclasses (dependency inversion principle), thus I cannot (or can I?) create instance of the sub class in a super class.
Problem 2: Implementing merge() method in each of the subclasses is a lot of code repetition (DRY rule).
Problem 3: Extracting the merge() logic to a entirely new class does not solve the DRY rule problem. Even using the visitor pattern it is a lot of copy/paste.
The problems presented above rule out any idea of implementation I might have had before I read about SOLID. (my life has been miserable since then ;)
Or is there an entirely different, out-of-the-box approch to achieve the merge of such objects?
I'd appreciate answer in C#, Java or even PHP.
EDIT: I think I left out a piece of valid information: event though there are a lot of different sub classes, they can (should) only be constructed in two, maybe three ways (as an implication of the single responsibility principle):
parameterless constructor
a constructor which accepts one IEnumerable<T> argument
a constructor which accepts array and some other modifier
This would put the visitor pattern back on the tablie if I could put a constraint on the constructors - for example by defining a constructor in an interface. But this is possible only in PHP. In Java or C# a constructor signature cannot be enforced, thus I cannot be certain of how I would instantiate a subclass. This is a good rule in general, because one could never predict of how author of the subclass would like the object be constructed, but in this particular case it might have been helpful. So a helper question would be: can I somehow enforce how a class is instantiated? Builder pattern sounds like way too much in this simple case, or does it?
You are right about dependency inversion rule and code duplication problems.
You can write the core implementation of the merge logic in your abstract class and give out the task of creating a new instance to the derived classes. Create an abstract method in your abstract class that will force all the children to implement it. The purpose is this method is to create a new instance of the class and return it. This method will be used by the super class to get a new instance and do the merging.
The resultant java code will look something like this
abstract class AMyAbstract {
// ...
public AMyAbstract merge(AMyAbstract other) {
AMyAbstract obj = getNewInstance();
// Do the merge
// Return the merged object.
}
protected abstract AMyAbstract getNewInstance();
}
class foo extends AMyAbstract {
protected foo getNewInstance() {
// Instantiate Foo and return it.
}
}
Hope this helps..
OBSOLETE, kept for reference (and shows how I arrived at the final solution), see code after EDIT below
I would say the builder pattern is the way to go. We just need a builder which keeps the instance but modifies the one field that needs to be changed.
If one wants to obtain (as shown in your code)
Foo fooAndBar = foo1.merge(bar1);
an additional generic type definition is needed (thus defining class AMyAbstract <T>) to be able to still produce the correct final type (instead of just seeing AMyAbstract as type for the fooAndBar) in the above call.
Note: merge method was renamed to MergeItems in the code below to make clear what is merged.
I specified different constructors for Foo and Bar, so that it is clear that they do not need to have the same number of parameters.
Actually to be truly immutable, the list should not be directly returned in the Items property as it could be modified by the caller (using new List(items).AsReadOnly() produced a ReadOnlyCollection, so I just used this one).
Code:
abstract class AMyAbstract<T> where T : AMyAbstract<T>
{
public ReadOnlyCollection<string> Items { get; private set; }
protected AMyAbstract(IEnumerable<string> items)
{
this.Items = new List<string>(items).AsReadOnly();
}
public T MergeItems<T2>(AMyAbstract<T2> other) where T2 : AMyAbstract<T2>
{
List<string> mergedItems = new List<string>(Items);
mergedItems.AddRange(other.Items);
ButWithItemsBuilder butWithItemsBuilder = GetButWithItemsBuilder();
return butWithItemsBuilder.ButWithItems(mergedItems);
}
public abstract class ButWithItemsBuilder
{
public abstract T ButWithItems(List<string> items);
}
public abstract ButWithItemsBuilder GetButWithItemsBuilder();
}
class Foo : AMyAbstract<Foo>
{
public string Param1 { get; private set; }
public Foo(IEnumerable<string> items, string param1)
: base(items)
{
this.Param1 = param1;
}
public class FooButWithItemsBuilder : ButWithItemsBuilder
{
private readonly Foo _foo;
internal FooButWithItemsBuilder(Foo foo)
{
this._foo = foo;
}
public override Foo ButWithItems(List<string> items)
{
return new Foo(items, _foo.Param1);
}
}
public override ButWithItemsBuilder GetButWithItemsBuilder()
{
return new FooButWithItemsBuilder(this);
}
}
class Bar : AMyAbstract<Bar>
{
public string Param2 { get; private set; }
public int Param3 { get; private set; }
public Bar(IEnumerable<string> items, string param2, int param3)
: base(items)
{
this.Param2 = param2;
this.Param3 = param3;
}
public class BarButWithItemsBuilder : ButWithItemsBuilder
{
private readonly Bar _bar;
internal BarButWithItemsBuilder(Bar bar)
{
this._bar = bar;
}
public override Bar ButWithItems(List<string> items)
{
return new Bar(items, _bar.Param2, _bar.Param3);
}
}
public override ButWithItemsBuilder GetButWithItemsBuilder()
{
return new BarButWithItemsBuilder(this);
}
}
class Program
{
static void Main()
{
Foo foo1 = new Foo(new[] { "a", "b" }, "param1");
Bar bar1 = new Bar(new[] { "c", "d" }, "param2", 3);
Foo fooAndBar = foo1.MergeItems(bar1);
// items in fooAndBar now contain: {"a", "b", "c", "d"}
Console.WriteLine(String.Join(", ", fooAndBar.Items));
Console.ReadKey();
}
}
EDIT
Perhaps a simpler solution would be to avoid the builder class, and instead have
abstract T ButWithItems(List<string> items);
directly in the base class, and implementing classes would just implement it as currently the builders do.
Code:
abstract class AMyAbstract<T> where T : AMyAbstract<T>
{
public ReadOnlyCollection<string> Items { get; private set; }
protected AMyAbstract(IEnumerable<string> items)
{
this.Items = new List<string>(items).AsReadOnly();
}
public T MergeItems<T2>(AMyAbstract<T2> other) where T2 : AMyAbstract<T2>
{
List<string> mergedItems = new List<string>(Items);
mergedItems.AddRange(other.Items);
return ButWithItems(mergedItems);
}
public abstract T ButWithItems(List<string> items);
}
class Foo : AMyAbstract<Foo>
{
public string Param1 { get; private set; }
public Foo(IEnumerable<string> items, string param1)
: base(items)
{
this.Param1 = param1;
}
public override Foo ButWithItems(List<string> items)
{
return new Foo(items, Param1);
}
}
class Bar : AMyAbstract<Bar>
{
public string Param2 { get; private set; }
public int Param3 { get; private set; }
public Bar(IEnumerable<string> items, string param2, int param3)
: base(items)
{
this.Param2 = param2;
this.Param3 = param3;
}
public override Bar ButWithItems(List<string> items)
{
return new Bar(items, Param2, Param3);
}
}
class Program
{
static void Main()
{
Foo foo1 = new Foo(new[] { "a", "b" }, "param1");
Bar bar1 = new Bar(new[] { "c", "d" }, "param2", 3);
Foo fooAndBar = foo1.MergeItems(bar1);
// items in fooAndBar now contain: {"a", "b", "c", "d"}
Console.WriteLine(String.Join(", ", fooAndBar.Items));
Console.ReadKey();
}
}
I'm a bit late to the party but as you have yet to accept an answer I thought I would add my own.
One of the key points is that the collection should be immutable. In my example I have exposed IEnumerable to facilitate this - the collection of items is immutable outside of the instance.
There are 2 ways I see this working:
a public default constructor
an internal Clone template method similar to #naveen's answer above
Option 1 is less code but really it depends whether an instance of AMyAbstract with no items and no way to change the items is something you want to allow.
private readonly List<string> items;
public IEnumerable<string> Items { get { return this.items; } }
public static T CreateMergedInstance<T>(T from, AMyAbstract other)
where T : AMyAbstract, new()
{
T result = new T();
result.items.AddRange(from.Items);
result.items.AddRange(other.Items);
return result;
}
Seems to satisfy all of your requirements
[Test]
public void MergeInstances()
{
Foo foo = new Foo(new string[] {"a", "b"});
Bar bar = new Bar(new string[] {"c", "d"});
Foo fooAndBar = Foo.CreateMergedInstance(foo, bar);
Assert.That(fooAndBar.Items.Count(), Is.EqualTo(4));
Assert.That(fooAndBar.Items.Contains("a"), Is.True);
Assert.That(fooAndBar.Items.Contains("b"), Is.True);
Assert.That(fooAndBar.Items.Contains("c"), Is.True);
Assert.That(fooAndBar.Items.Contains("d"), Is.True);
Assert.That(foo.Items.Count(), Is.EqualTo(2));
Assert.That(foo.Items.Contains("a"), Is.True);
Assert.That(foo.Items.Contains("b"), Is.True);
Assert.That(bar.Items.Count(), Is.EqualTo(2));
Assert.That(bar.Items.Contains("c"), Is.True);
Assert.That(bar.Items.Contains("d"), Is.True);
}
Whether you ultimately choose a default constructor or a template method the crux of this answer is that the Items only need to be immutable on the outside.
A neat solution based on #AK_'s comment:
tldr: The basic idea is to create a multiple merge methods for each aggregated filed instead of using a merge method for entire object.
1) we'd want a special list type for the purpose of aggregating the items inside AMyAbstract instances, so let's create one:
class MyList<T> extends ReadOnlyCollection<T> { ... }
abstract class AMyAbstract
{
MyList<string> Items { get; private set; }
//...
}
The advantage here is that we have a specialized list type for our purpose, which we can alter later.
2) instead of having a merge method for entire object of AMyAbstract we would want to use a method which merly merges the items of that object:
abstract class AMyAbstract
{
// ...
MyList<T> mergeList(AMyAbstract other)
{
return this.Items.Concat(other.Items);
}
}
Another advatage we gain: decomposition of the problem of merging entire object. So instead we break it into a small problems (merging just the aggregated list in this case).
3) and now we can create a merged object using any specialized constructor we might think of:
Foo fooAndBar = new Foo(foo1.mergeList(bar1));
Instead of returning the new instance of entire object we return only the merged list, which in turn can be used to create object of target class. Here we gain yet another advantage: deferred object instantiation, which is the main purpose of creational patterns.
SUMMARY:
So not only this solution solves the problems presended in the question, but provides additional advantages presented above.
I am currently applying AspectJ to our project, and I found a behavior which is a bit strange to me.
Q1:
I added a new constructor to my current class with inter-type declaration, and found that the class's member variable is not initialized if the new constructor is used to instantiate my class.
For example:
The class which I'll add a new constructor to:
public class Child {
public String name = "John";
public Child(String desc) {
// TODO Auto-generated constructor stub
}
}
The aspectJ code:
public aspect MyTest {
public Child.new(String desc, int num) {
System.out.println("Child Name:" + this.name);
}
}
If I instantiate the Child with the new constructor:
new Child("A child", 5)
the member variable this.name is not initialized as will be done with the original constructor.
But, if I call the original constructor:
new Child("A child")
the member variable this.name will be initialized to "John" as usual
The result:
Child Name:null
Is this a limitation of AspectJ? Is there anyway to resolve this issue?
I don't really want to add the code for member variable initialization to the new constructor.
Q2:
It seems in the newly added constructor, super.method() can not be correctly resolved.
The class which I'll add a new constructor to:
public class Child extends Parent{
public String name = "John";
public Child(String desc) {
}
}
Child extends Parent. Parent has a method init()
public class Parent {
public void init() {
//....
}
}
I add a new constructor for the Child in my aspect.
public aspect MyTest {
public Child.new(String desc, int num) {
super.init();
}
}
The above aspect code will trigger an exception.
Exception in thread "main" java.lang.NoSuchMethodError: com.test2.Child.ajc$superDispatch$com_test2_Child$init()V
at MyTest.ajc$postInterConstructor$MyTest$com_test2_Child(MyTest.aj:19)
at com.test2.Child.<init>(Child.java:1)
at MainProgram.main(MainProgram.java:11)
My workaround is to define another method for my class Child, and indirectly call the super.method() within that method
For example, add a new method that calls super.init() for Child
public void Child.initState()
{
super.init();
}
Now, I can call initState() in the newly added constructor like below:
public aspect MyTest {
public Child.new(String desc, int num) {
this.initState();
}
}
Is this a limitation of AspectJ? Is this the only way to resolve this issue?
Thank you all for your time :)
Foe the first questions, it seems that the lint warning will appear when compiling:
(unless you close the lint warning)
"inter-type constructor does not contain explicit constructor call: field initializers in the target type will not be executed [Xlint:noExplicitConstructorCall]"
Therefore I'd say it's an AspectJ's limitation.
The best way to do this might be call the other constructors of Child in the constructor added by AspectJ
For example:
public aspect MyTest {
public Child.new(String desc, int num) {
this("Hello"); // -> This will call the constructor of Child, and trigger fields initialization
System.out.println("Child Name:" + this.name);
}
}
For the second question, I think it's a bug of aspectJ.
That decompile the woven target byte code will find that the method “com.test2.Child.ajc$superDispatch$com_test2_Child$init()V” will be inserted. It implies this method should be generate by aspectJ, but there is no such method in the byte code.
The code for an ITD introduction is no different that the code that you would add to a class directly. So without member initialization code in your introduced constructor, members will , of course, remain uninitialized. So you need to change you code in Q1 as follows.
public Child.new(String name, int age) {
this.name = name;
this.age = age;
System.out.println("Child Name:" + this.name);
}
As for Q2, it works fine for me.
class Parent {
public void init() {
System.out.println("P.init");
}
}
class Child extends Parent {
}
aspect Intro {
public void Child.init(){
super.init();
System.out.println("C.init");
}
}
public class Main {
public static void main(String[] args) {
Child c = new Child();
c.init();
}
}
prints:
P.init
C.init
Changing the introduced method to something other than init works too (to match your code).
Regarding your comment: I fail to see what difference you have made in Q1. Sorry, I don't get it.
As for Q2 part of your comment, constructor arrangement works for me:
class Parent {
protected String name;
public Parent(String name) {
this.name = name;
}
}
class Child extends Parent {
int age;
public Child(String name) {
super(name);
}
}
aspect Intro {
public Child.new(String name, int age){
super(name);
this.age = age;
System.out.println("this.name: " + this.name + " this.age: " + this.age);
}
}
prints this.name: myname this.age: 2
I know this is not good practice.
Here is some code that sort of demonstrates the problem (but doesn't actually work):
public interface IBar {}
public interface Bar : IBar {}
public interface IFoo {}
public class Foo : IFoo
{
public Foo(IBar bar)
{
}
}
public class InjectionModule : NinjectModule
{
public override void Load()
{
Bind<IFoo>().To<Foo>();
}
}
public class MyApp
{
public void DoSomething()
{
// Get a foo with a particular bar
var foo1 = Kernel.Get<IFoo>(new Bar());
// Get another foo with a different bar
var foo2 = Kernel.Get<IFoo>(new Bar());
}
}
So what I am trying to do is to use NInject to bind IFoo to Foo, but have my app supply the Bar argument to the constructor at runtime, rather than the usual practice where NInject resolves the IBar dependency.
var foo1 = Kernel.Get<IFoo>(new ConstructorArgument("bar", new Bar()));
I have two entities Foo and Bar with a Many to Many relationship between them.
Let's say there is no semantic argument for why Foo might be "responsible" for the many to many relationship, but we arbitrarily decide that Foo is responsible for the relation (I.e., in NHibernate we would mark Bar as Inverse)
That's all well and good from a DB perspective, but my entity APIs reveal a problem.
// Responsible for the relation
public class Foo
{
List<Bar> Bars = new List<Bar>();
public void AddBar(Bar bar)
{
Bars.Add(bar);
bar.AddFoo(this);
}
}
public class Bar
{
List<Foo> Foos = new List<Foo>();
// This shouldn't exist.
public void AddFoo(Foo foo)
{
Foos.Add(foo);
foo.AddBar(this); // Inf Recursion
}
}
If we've decided that Foo is responsible for this relationship, how do I update the associated collection in Bar without creating a public Bar.AddFoo() method which shouldn't even exist?
I feel like I should be able to maintain the integrity of my domain model without resorting to having to reload these entities from the DB after an operation such as this.
UPDATE: Code tweak inspired by commenter.
You might be missing a domain concept there. Have you tried creating a third entity: FooBarRelationship?
See Working bi-directional links in the Hibernate documentation.
Many developers program defensively
and create link management methods to
correctly set both sides, e.g. in
Person:
protected Set getEvents() {
return events;
}
protected void setEvents(Set events) {
this.events = events;
}
public void addToEvent(Event event) {
this.getEvents().add(event);
event.getParticipants().add(this);
}
public void removeFromEvent(Event event) {
this.getEvents().remove(event);
event.getParticipants().remove(this);
}
I personally think Entity object holding the list of related object is being too smart, and you should let the DAL hit the database.
DALFactory.FooAdapter.getBars(foo);
You said that one side will "own" the relationship. Make this method public. The other associations (or add methods) can be made internal to avoid consumers from interacting with it directly.
public class Foo
{
private IList<Bar> Bars {get;set;}
public void AddBar(Bar bar)
{
Bars.Add(bar);
bar.Foos.Add(this);
}
}
public class Bar
{
internal IList<Foo> Foos {get;set;}
}
you could make it static
public class Foo
{
List<Bar> Bars = new List<Bar>();
public void AddBar(Bar bar)
{
Bars.Add(bar);
Bar.AddFoo(bar,this);
}
}
public class Bar
{
List<Foo> Foos = new List<Foo>();
// This shouldn't exist.
public static void AddFoo(Bar bar, Foo foo)
{
bar.Foos.Add(foo);
//foo.AddBar(this); inf recurtion
}
}
Not really ideal but it does get the function off the object its self