I have a core data abstract entity which is backed by a class that's subclassed for many concrete [sub]entities that I create and manipulate instances of. No attributes or relationships or properties are different in the subclasses. I'm just overriding method implementations. So other then setting the subclass and parent entity, the xcdatamodeld is empty for each subentity.
If there are no unique properties or relationships in the subentities in xcdatamodeld, and I'm creating quite a number of them, is there some code that I could create in the abstract superentity class to handle the core data subentity registration?
What I'm looking for is some reasonable code that lets me just create a .h/.m for each new subentity (which subclasses the abstract entity, which subclasses NSManagedObject), and skip seemingly duplicate and cluttering work in xcdatamodeld of +entity, edit name, add class, declare parent entity. Is this feasible and reasonable? Or do I go down a rabbit hole of arcane programmatic managedObjectModel editing outside of my class implementations?
[edit] To add background about why subclasses. One-- each subclass creates a different tree of child entities. Two-- each subclass assembles its data differently for passing to views. ie they all have the same string properties, but each subclass might present an attributedStringForTitle differently than the next.
Probably the closest you will get is by using mogenerator. You may be able to script changes to the data model, but unless you're going to create lots of classes then it likely won't save you time.
Related
Suppose I have one table view controller (controlling a static table view) and another regular view controller.
I want to add a common property to both of them. The first thing came in my mind is subclassing, meaning let these two controllers derive from a common abstract super class. After pondering a bit, I recall protocol can also achieve this.
My questions is, which approach will be the correct practice, or there are better practices?
Subclassing is likely the correct approach. Protocols don't add properties automatically, they only dictate that if your class conforms to a specific one that the class implements them. If your coming from the Java world then an interface would be the equivalent.
A category might be appropriate if you want to add common functionality (methods) to all instance of a class, such as a UITableview controller. The downside is that you can't declare additional instance variables (or properties) via a category (well technically you can via associated objects, but that's another rabbit hole).
I am working on a project with class hierarchy as in the image. It has many classes but i am showing some of them. The problem is that there are some attributes that repeat in many classes but not in all classes. I want to reduce the occurance by creating a new class with common attributes, and use the class as Instance variable in all the classes. This way i can maintain my class instead of maintaining all the occurances all over the code. These attributes has no operation, and class also have methods so it does to fulfill the definition of class. The class has many levels of inheritance and if create subclasses, it has yo-yo problem then, so i do not want them to be further subclassed. I want to know is there any other way? or any better way to do it.
You have yo-yo problem when you have all concrete classes. I would suggest to make an abstract class and put all common attributes there. I also see that you have Unit value attributes repeating for same attribute. For this, you can use hash map to have only one attribute with two values for unit and for value.
Suppose I have such requirement:
The objects in the system all derive from a base class named IObject, and it may have objects with color, objects with transformations, and both.
Now there are 2 approach to design the class hierarchy.
The first one is:
just let concrete class derived from
IObject, and also select "capability"
interfaces as its base class to
indicate it support such behavior,
like interface: IHasColor,
IHasTransformation
The second one is:
Organize the base classes, and let
concrete classes derived from one of
them: IObject, IColorObject,
ITransfromationObject ,
IColorAndTransformationObject
I prefer the first one (Does it have a formal name? ) as it is more flexible, and as you can see the second one may have class combination explosion problem when there are many attributes like color, transformation...
I would like to know your ideas and suggestions.
Thanks.
Classes abstract the real concept of types of objects.
Interfaces abstract the real concept of behaviors or abilities for an object.
So the questions becomes, is the "color" a property of the object or is it a capability of the object?
When you design a hierarchy you are constraining the world into a narrower space. If you take the color as a property of the object then you will have two kind of objects, the ones that have colors and the ones that do not. Does that fit your "world"?
If you model it as a capability (Interface) then you'll have objects that are able to provide, lets say cast, colors to the world.
For the transformation the same logic applies. You can either split the world into two kind of objects, the ones who can transform and the ones who can not, or you can view it as a capability, an object may have the ability to transform itself into another thing.
For me, from that point of view, what would make sense would be:
Color is a property of the object. In fact every object should have a color, even if its transparent, even if is reflection, even if its "none" (good luck figuring out what an object with color = none means in the real world, still it might make sense in your program logic).
Transformation is a capability, that is, an interface, something the object is capable of doing, among other things the object may or may not be able of doing.
I'm working on classes hierarchy in my project and basically I have similar situation like you described in your question.
Let's say I have base type Object which is absolute root of all other classes in my toolkit. So naturally everything derives from it directly or through it's subclasses. There is a common functionality that every Object-derived class has to provide but in some leaf classes effects are little different than in others. For example every object have size and position which can be changed with properties or methods like Position = new Point(10, 10), Width = 15, etc. But there are classes that should ignore setting of a property or modify it according to self inner state. Think about control docked to left side of parent window. You can set Height property all you like but it will be generally ignored because this property really depend on Height of parent container control (or it's ClientArea height or sth like that).
So having Object abstract class implementing basic common functionality is ok until you reach a point of where you need "customize" behavior. If Object provides protected virtual SetHeight method that is called in setter of Height property you can override it in you DockedControl class and allow change of height only if docking is None, in other cases you limit it or ignore completely.
So we are happy but now we have requirement for object that react on mouse events like Click or Hover. So we derive MouseAwareObject from abstract Object class and implement events and stuff.
And now client want dockable, mouse aware objects. So we derive from DockableObject and... hmm, what now? If we can do multiple inheritance we can do it but we hit diamond problem with ambiguity of duplicated interface and we need to deal with it. We can have two memeber of Dockable and MouseAware types in new class and proxy external calls to them to provide functionality.
And last thing that comes to mind is to make IDockable and IMouseAware interfaces and let them define functionality and add them freely only to objects that need to deliver concrete behaviors/implementations.
I think I will split my base class into parts and leave my Object with very limited "core" set of properties and methods and rest of functionality that is in fact optional to Objects as a type but needed in concrete cases move to interfaces like IResizable, IDockable, IMakeAWorldABetterPlaceAble, etc. With this solution it is possible to "attach" behaviors to Object-derived classes without need for draggin virtual or pure virtual (abstract) methods from root base class all the way down to leaf class.
There is of course inconvenience of implementing interfaces in all affected classes but you can always implement some "adapters" and just forward calls to them. That way you don't have duplicated implementation (to some extend of course) and have decoupling between realization of task (Resize can mean different things for different classes) and expectation of client code.
Probably this is not ideal answer for your question but maybe it will hint you to your own solution.
I think you jump directly into interfaces, skipping classes. Is it required for you app. to have a "IObject" interface ? Maybe a "CObject" root class for your class hierarchy, may help you.
It think the winner is No. 1 solution, you may have a "MyObject", whether is an implementation of an interface, or direct class. Later you can add additional classes or interfaces in your class hierarchy, as you need.
After seeing several applications (some mine, some others), I think there should be a "My Custom Application Class Hierarchy Root Object" or "My Custom Application Class Hierarchy Root Interface" Design Pattern.
I’m fairly new to OO. If I have two classes A and B that need to exchange data, or call each other’s methods, I need to be able to access an instance of class B from class A. Should I maintain the address of the instance object in a global variable? Should I appoint a (singleton) master class, and make (pointers to) instances of A and B properties of the master class? (AppDelegate comes to mind.)
Is there a straightforward by-the-book way to implement this? Somehow I‘m missing some "best practice" here. I’ve looked through Apple's examples, but didn't find an answer.
EDIT: Since I'm fairly new to MVC design patterns, my question is essentially "Who creates who"?
We're talking about an Audio Player here. 1. When the user selects a song, the UI displays its waveform by creating a viewController which creates the appropriate view. 2. When the user hits play, the UI displays a timeline while the song is playing by overlaying a new view over the waveform. Now, the latter view needs some info from the waveform display viewController. Right now, I'm storing a pointer to the viewController in an instance variable of my appDelegate. This works, but feels extremely strange.
Should I outsource the info that is needed by both classes to some third entity that every class can access easily?
Classes aren't simply departments of code. They are templates for the creation of objects, which you should think of as actors in your program, doing things within their areas of responsibility (which you define—you decide what each object does) and interacting with each other.
While you can handle a class as you would an object, classes generally do not talk to each other. Most of the time, you will create and use instances of the classes—which is what we normally mean by “objects”—and have those talking to each other. One object sends another a message, telling the receiver to do something or changing one of the receiver's properties. These messages are the interactions between your program's objects.
Those weird expressions in the square brackets are message expressions. Nearly everything you'll do with a class or object will involve one or more messages. You can send messages to classes the same as to objects, and classes can send messages just as objects can.
In Cocoa and Cocoa Touch, you typically have model objects, view objects, controller objects, data objects (such as NSString, NS/UIImage, and NSURL), and helper objects (such as NSFileManager). The classes you'll write for your application will mainly be model, view, and controller objects (MVC). The model represents (models) what the user will see themselves manipulating; the view displays the model to the user; the controller implements logic and makes sure the model gets saved to and loaded from persistent storage.
For more information, see Object-Oriented Programming in Objective-C and the Cocoa Fundamentals Guide.
Since I'm fairly new to MVC design patterns, my question is essentially "Who creates who"?
Controllers create and load the model, and load the views, and pass the model to the view for display. Certain controllers may also create other controllers.
It's good to keep a straightforward tree-like graph of ownership from a single root of your program—typically the application object—down through controllers to leaf objects in the models and views. If two objects own each other, that's a problem. If an object is not owned by anything outside of its own class (a singleton), that's usually a problem as well—a sign you need to think some more about where that code belongs. (Helper objects are the main exception; most of those are singletons. Again, see NSFileManager for an example. But they are few and far between.)
Further situation analysis require more information. At first place you should more specify the relation between classes and what exactly do you mean by exchanging data.
Singletons should be generally avoided. If you want to exchange information it is usually sufficient to provide for example instance of the class A to the instance of the class B by some method or constructor. The instance of B is then capable of calling public methods (and accessing public properties) of the instance of A.
A little bit of "best practices" can be learn by searching up "Design Patterns".
You should decide if one class can be an object of another class (encapsulation), or if one class can inherit from the other class (inheritance). If neither of these is an option, then maybe you could make one class (or some of its members) static?
Thanks for your contributions. Additionally, I found information on this page very useful. It lays out MCV considerations for cocoa in a hands-on way and practical language.
In my model all the derived classes have the same ** persistent** attributes and methods as the base abstract class. There are some class specific attributes which aren't persisted and methods have different implementation.
Right now I have about 4 inheriting classes, and I will add more in the future. The nature of the application is that such classes may be added for different uses, so its impossible to know them in advance. The only given is that they will all share the same methods and persistent attributes. The is one column which will be used as discriminator.
I am struggling with strategy. Obviously I don't want to write a ClassMap for each derived class. In fact I's like the persistence layer to be completely ignorant of these derived classes. I am thinking of having the derived classes be able to be created off the base class and to return a base class.
I don't suppose I have any better option?
Your approach is flawed in that the persistence layer can not be ignorant about the subclasses, because it needs to know what the class is when loading/storing.
What you can do is use a convention-based mapping instead of an explicit one (Fluent has Automapping, and ConfORM is convention/override based only), so you don't have to write every classmap.
In ConfORM, it's as easy as saying, for example, orm.TablePerClass<TheBaseClass>(), then mapper.CompileMappingFor(TheBaseClassAndAllItsSubclasses), and you'll get the mappings without any additional effort.