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.
Related
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.
I want to prepare small static library for below classes in objective-c :
Class A, Class B, Class C. I want to include these classes in static library. Now Class A can access public members of methods of Class B or Class C.
Now When I integrate above library in other project,
I prepare Class D which can access only Class A and Class B
Not Class C. How can I do this ?
My other doubt is assume that
NSString *isValid is declared in Class B.
I want that above variable can be accessed from Class A and Class C
I mean included files of library can access above variable.
But from outside library above variable can't be accessed.
How can make it private so that it can be accessed within the library itself and not outside the library ?
Thanks for help !
You can make public methods only visible to your static library but invisible out side of it.
Here is how to do it.
1) Create a header file to be used outside of your library
#import <Foundation/Foundation.h>
#interface ClassA : NSObject
#property(nonatomic,readwrite)BOOL publicProperty;
-(void)publicMethod;
#end
2) Create a category to be only used internally by the static library
#import "ClassA.h"
#interface ClassA (Internal)
#property(nonatomic,readwrite)BOOL privateProperty;
-(void)privateMethod;
#end
Note Name this file: "ClassA+Internal.h"
3) Declare your private properties and methods again in the .m file
#import "ClassA.h"
#interface ClassA ()
#property(nonatomic,readwrite)BOOL privateProperty;
-(void)privateMethod;
#end
#implementation ClassA
#synthesize publicProperty;
#synthesize privateProperty;
//...
#end
Using private properties and methods inside the static library
In your ClassB.m file import header file of the ClassA category
#import "ClassB.h"
#import "ClassA.h"
#import "ClassA+Internal.h"
Now you have access to the private properties and methods of ClassA
Creating static library without private properties and methods
When you create you static library keep the "ClassA+Internal.h" category header file inside "private" or "project" headers section of "Build Phases","Copy Headers"
This way when you build your static library the ClassA+Internal.h category will be inaccessible to the outside.
As far as I know, there is no way in Obj-C to protect access to public members like you need it. A common approach is simply not to include the methods and ivars in the header file that you are shipping with the static library. For compiling the library yourself, you must of course use your complete private header.
Note that this does not work for Objective-C++ where the class structure must be known to the client of the library at compile time.
I have a class A with textField1, class B with textField2.
i want to use textField1 and textField2 in class C. What i have to import or what i have to do. I think i am straggling with importing files. i.e. #include or something
Thanks for reply in advance.
Objective does not support multiple inheritance.
You can only inherit from one class, you could use a protocol to make the class match class B.
Yes, you have to import both class A and class B in class C, and then access textField1 and textField2. Import syntax is #import "classA.h"
I have built a class which has a few methods in it, once of which returns an array, lets call this class A.
I have a second class, class B, which I would like to use to call the method from class A.
But, now how do I call that method from class A and store what is returned in a var in class B? Do I have to initiate the class? I have made sure to include the .h file from class A into class B.
Thanks for helping a newbie.
UPDATE:
Here is how I thought I could do this (DataStore is my class A and pushRideData is my method that returns an array):
DataStore *store = [[DataStore alloc] init];
trailsArray = [store pushRideData];
Assuming you have files A.h, A.m B.h and B.m to define your two classes, then you need to do the following:
Make sure A.h and B.h are #imported into your projects PCH file (this is the easiest/fastest way, but you could also choose to import the files into all the .m files, instead).
If you refer to a class -- say, B *something in A.h -- before that class's header file is imported, then use a forward class declaration to shut up the compiler. I.e. #class B; before the #interface A:NSObject in A.h
If you want to call an instance method of a class, you need to instantiate the class as you describe. Or, if the instance is created somewhere else, you'll need some mechanism to retrieve it. A class method, perhaps, or a global variable or a controller or something like it.
None of this is really that much different than straight C save for a formal notion of Objects (as opposed to malloc'ing a bunch of memory and passing around pointers).
That's a fairly abstract question. Yes, you need an instance to be able to store instance variables in it. You will need to allocate and init the instance, assinging it to an instance or local (pointer) variable in the calling class unless it is one of the several in the Cocoa Touch frameworks which use the singleton pattern, such as the application delegate. Such singletons have special case-specific class methods for obtaining the singleton instance.
We can import class declaration with #import:
#import "SomeClass.h"
or declare with #class:
#class SomeClass;
What's the difference and when we should use each of them?
"Import" links the header file it contains. Everything in the header, including property definitions, method declarations and any imports in the header are made available. Import provides the actual definitions to the linker.
#class by contrast just tells the linker not to complain it has no definition for a class. It is a "contract" that you will provide a definition for the class at another point.
Most often you use #class to prevent a circular import i.e. ClassA refers to ClassB so it imports ClassB.h in its own ClassA.h but ClassB also refers to ClassA so it imports ClassA.h in ClassB.h. Since the import statement imports the imports of a header, this causes the linker to enter an infinite loop.
Moving the import to the implementation file (ClassA.m) prevents this but then the linker won't recognize ClassB when it occurs in ClassA.h. The #class ClassB; directive tells the linker that you will provide the header for ClassB later before it is actually used in code.