0

So here's my dilemma. I'm dealing with legacy code and trying to simplify and reduce a huge amount of redundancy in the code base. Here's the crux of the matter. I'm trying to consolidate two very similar classes into a superclass/subclass relationship. One is a subclass of NSObject the other a subclass of NSManagedObject.

I have a class that contains only variables called InventoryItems.h. It is a subclass of NSObject.

@property (nonatomic, retain) NSString * desc;
@property (nonatomic, retain) NSString * locationInventoryId;
...

InventoryItems.m

@synthesize desc;
@synthesize locationInventoryId;
...

There is another class that is called FavoriteInventoryItems.h that is a subclass of NSManagedObject. It contains exactly the same variables as InventoryItems with one additional variable.

FavoriteInventoryItems.h

@property (nonatomic, strong) NSString * desc;
@property (nonatomic, strong) NSString * locationInventoryId;
@property (nonatomic, strong) NSString * dateAddedAsFav;
....

FavoriteInventoryItems.m

@dynamic desc;
@dynamic locationInventoryId;
@dynamic dateAddedAsFav;
...

I can successfully make things work by making InventoryItems a subclass of NSManagedObject and then making FavoriteInventoryItems a subclass of InventoryItems. It does work but I get a message indicating the following:

CoreData: error: Failed to call designated initializer on NSManagedObject class 'InventoryItems'

My solution assuredly is a hack that may have negative consequences.

There are multiple places where the code resembles something like the following:

if (InventoryItem)
    ...many lines of code here
else if(FavoriteInventoryItem)
    ...exact same code as above based on favorites

I'm not sure how else to consolidate both of these class into superclass/subclass relationship. Or is there a better way to handle this problem that doesn't involve inheritance? Any ideas?

Rymnel
  • 4,515
  • 3
  • 27
  • 28
  • Are you just trying to consolidate these properties, or there is some functionality (methods) that go with them? If it's just these parameters, you're just making life difficult for yourself. The classes may look similar but the inheritance they have shows that they are quite different. What benefit is merging the inheritance of these classes actually going to provide you? – Wain Jun 10 '13 at 15:58
  • @Wain I've updated the question to better define what I'm trying to do. These objects are used throughout the code base and there is a huge amount of repeated code because of this situation. There are no methods connected with either class. – Rymnel Jun 10 '13 at 16:05
  • So, the duplicate code isn't in these classes, but in classes that use them? Can you use a protocol to specify what is common between the classes and allow the using code to be generic to the protocol? – Wain Jun 10 '13 at 16:07
  • @Wain Please forgive my ignorance. I'm not sure I understand how the implementation of a protocol could help my particular problem. Would you be so kind as to post some kind of example in an answer? – Rymnel Jun 10 '13 at 16:14

1 Answers1

3

Try to use a protocol to specify what is common between the classes and allow the 'using' code to be generic to the protocol.

The specification of a protocol is the important part, the implementation already exists in the 2 classes you have. The specification would list the common methods (or properties) between the 2 classes. Then, in the duplicated code, instead of saying:

InventoryItem *item = ...

or

FavoriteInventoryItem *item = ...

You would say:

id < InventoryItem > item = ...

I'm duplicating names because I can't know what a better name is, but the protocol is defined as:

@protocol InventoryItem < NSObject >

@property (nonatomic, strong) NSString * desc;
@property (nonatomic, strong) NSString * locationInventoryId;

@end

Then the code using the protocol doesn't care about what the underlying class is, it just cares what the protocol offers:

item.desc = @"Teddies";
item.locationInventoryId = ...
Wain
  • 118,658
  • 15
  • 128
  • 151
  • Thanks a ton. That seems to be the best way to handle the situation. Now time to implement the refactor. :) – Rymnel Jun 10 '13 at 16:42