MEF Export derived classes ans new instances - mef

I have a base class and a derived class and I want to export for types derived from either.
So like this
public class ClassA { }
public class ClassB : ClassA { }
I need to load types derived from ClassA but also types derived from ClassB.
var registration = new RegistrationBuilder();
registration.ForTypesDerivedFrom<ClassA>()
.Export<ClassA>();
registration.ForTypesDerivedFrom<ClassB>()
.Export<ClassB>();
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new DirectoryCatalog(".", registration));
catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly(), registration));
container = new CompositionContainer(catalog);
container.SatisfyImportsOnce(this, registration);
I think the problem is that when exporting ClassA derived types it also exports ClassB types which is obvious and is the functionality that I am looking for. But it means that the ClassB imports aren't exported as independent objects, rather being the same ones as those imported as ClassA types. If I don't specifically export the ClassB then any imports using them fail.
I may be trying to do something stupid to try and solve my problem here that MEF isn't liking? I have looked at making the MEF imports non-singleton but that might break things in my imports.

In your given example only ClassB (with the export definition of classA) is exported as a MEF part. As Panos already mentioned, ForTypesDerivedFrom does not export the base class.
You can do something like this:
var registration = new RegistrationBuilder();
registration.ForTypesDerivedFrom<ClassA>().Export();
registration.ForType<ClassA>().Export();
This will export all derived classes of ClassA (also ClassB with ClassB contract and not with ClassA) and separately ClassA.
Additionally if you want to hide the base part but still want to use imports in this class you can add the [PartNotDiscoverable] attribute to your base class.

Related

RealmSwift: saving related objects during add()

In the header for add(_ object:, update:) it says, "When added, all child relationships referenced by this object will also be added to the Realm if they are not already in it." This is the behavior I was hoping for, but I'm not 100% clear on what "child relationships" includes/excludes. Which types of Realm relationships are not covered by this behavior?
For example, if I'm adding a ClassA object to the realm and I have another unsaved ClassB object, will the ClassB object be saved:
If the ClassB object points to the ClassA object and ClassA has a LinkingObjects property for ClassB?
If the ClassB object is added to a List property of ClassA?
If ClassA has a to-one relationship variable pointing to the ClassB object?
I know that I could set up some sample classes and play around with this to figure out the behavior, but I'd like to have some official clarification if possible.
I figured out this behavior with realm also in the last months. From my experience the child relationships will be saved in your realm database as well. Below you can find the code examples based on your bullet points:
If this is your data model:
import Foundation
import RealmSwift
class ClassA: Object {
dynamic var uniqueID:String?
dynamic var someVaraible?
dynamic var classB:ClassB?
var list = List<ClassB>()
}
If the ClassB object points to the ClassA object and ClassA has a
LinkingObjects property for ClassB?
If you have a classA variable aVar you can add your object with aVar.classB = <your classB variable> in this case nothing will stored in the realm database for now. If you then add a object to realm with
try! realm.write({
realm.add(aVar)
})
Realm is going to save both objects (aVar and also your classB variable).
If the ClassB object is added to a List property of ClassA?
It is exactly the same behavior like in your first question -> the list of classB's (also every single entry of the list will be created in your classB database column) will be added to realm, if you add classA to realm.
If ClassA has a to-one relationship variable pointing to the ClassB
object?
In this case classB variable is already present and you just created a classA variable, which is starting to point to an existing classB stored entry in realm. (Please correct me, if I misunderstood you).

Very confusing Abstract Class, need guidance

I missed a few CS classes, namely the ones going over topics such as polymorphism, inheritence, and abstract classes. I'm not asking you to do my homework but I have no idea where to even start to get further guidance, so giving me a skeleton or something would help me greatly, I'm so confused.
So the problem is to create an employee abstract class with two subclasses, permanentEmployee and TempEmployee.I must store information such as name,department,and salary in these subclasses and then order them according to how the user wants them ordered. I know I start out like this
public abstract class Employee
{
}
public class TempEmployee extends Employee
{
\\variables such as name, salary, etc, here?
}
public class PermEmployee extends Employee
{
\\here too?
}
but I have no idea how to store variables in there much less access them later for ordering and displaying,. Please guidance.
If all you're looking for is an example of class-level data members in Java, this should help:
public class SomeClass {
private int someInt;
public int getSomeInt() {
return this.someInt;
}
public void setSomeInt(int someInt) {
this.someInt = someInt;
}
}
Regarding polymorphism, be aware that methods are polymorphic, but values are not. As you place values and methods (getters and setters) in your base class and derived classes, I encourage you to experiment with these concepts thoroughly. Try moving the entire value/getter/setter to the base class, try moving just the value but not the getter/setter, try putting the value in both and the getter/setter in both, etc. See how it behaves.
Make sure that any value/method/etc. that you put in your base class is applicable to all derived classes. If there's ever an exception to that rule, then you would need to move that member out of the base class and into only derived classes where it applies. Note that you can have a complex hierarchy of base classes to accommodate this if needed.
When it comes time to access these members for sorting/display/etc., consuming code would use the getters/setters. For example:
SomeClass myInstance = new SomeClass();
myInstance.setSomeInt(2);
System.out.println(myInstance.getSomeInt());
I am not sure which language you working with, but as it has "extends" I am sure you are not working with c# or CSharp, it can be Java. So I would recommend you to go for TutorialsPoint. This particular article has abstraction described here.
Just to make it easy for you, in Interface and abstraction we always create a structure or the base, it has all the common things defined or declared (Obviously interface has only methods and no variables can be declared inside it).
So as said, in above example, EmployeeId, EmployeeName, EmployeeAddress ...etc should be defined in the base class that is Abstract Base class Employee, But in TempEmployee you can have a criteria such as EmpTermPeriod, EmpContractRenewalDate, EmpExternalPayrollCompanyName (Have made names long and self descriptive) and PermEmployee to have fields like EmpJoiningDate, EmpConfirmationDate, EmpGraduityDate...etc.
I hope it helps.

base class pointing to inherited class

I have an inherited class which i would like to point to from the base class. Example below
class Base
{
inherited* test;
};
class inherited: Base
{
};
the purpose of this is so that the base class (a character) contains a linked list of the inherited class (items)
ps apologies for any mistakes, i'm new to this site
It might be possible to trick the compiler into accomplishing this, but it's most certainly bad OOP design. If all you want to do is be able to store an instance of the inherited class but can treat it like the base class, then you can simply make inherited* test a base* test and it will accept pointers to either inherited or base (or any other subclass of base).
If you actually want base to treat that instance as inherited, you need to rethink your class hierarchy because you don't actually have an inheritance tree here.

Show Different Classes in Tree View Structure for Documentation

I want to know if there is such tool that can show my classes hierarchy in a tree, e.g.
public Class ClassA
{
ClassB variableb;
ClassC variableC;
}
so, it shows me something like
ClassA
ClassB
ClassC
I have shown in bullted format, I just want that this kind of things be shown in tree view, is there any tool which can help me create this tree of classes ??
I got the solution in the form of class Diagram, don't why I didnt think of them at first place. :)

Importing a class imports the classes it has imported automatically

If I have three classes:
ClassA
ClassB
ClassC
They all have import statements to import each other i.e. ClassC imports ClassB and ClassB imports ClassA only.
Given this design, does ClassC have access to ClassA automatically?
First: in any case import/include doesn't make one class to have access to another class, it just makes class A to know about class B.
Second: visibility is determined by where you imported headers.
If you did import ClassA header in the ClassB header and then imported ClassB header in ClassC header than yes, ClassC knows about ClassA. But if imported it in an implementation file then the answer is no.
Edit: should notice that it's better to make class forward declarations in header and then include appropriate one in an implementation file.