Skip to main content
Software Engineering

Return to Answer

added 12 characters in body
Source Link
Robert Harvey
Robert Harvey
  • 200.1k
  • 55
  • 468
  • 679

There's nothing inherently wrong with mutable subclasses provided you don't make assumptions about mutability in other parts of your code. 

As an example, the Foundation framework that's part of Cocoa and Cocoa Touch frameworks (MacOS X and iOS respectively) has a number of immutable data containers that have mutable subclasses. NSMutableArray is a mutable subclass of the immutable NSArray, NSMutableDictionary is a mutable subclass of the immutable NSDictionary, etc. 

This works fine if you think of mutability as an added feature rather than something that needs to be removed from the superclass. Most importantly, client code should never try to make changes to an object that's advertised as immutable, even if the object happens to be an instance of a mutable subclass. 

So, if a method returns a NSArray, you might actually get back an instance of NSMutableArray, but you should always treat it as immutable anyway.

There's nothing inherently wrong with mutable subclasses provided you don't make assumptions about mutability in other parts of your code. As an example, the Foundation framework that's part of Cocoa and Cocoa Touch frameworks (MacOS X and iOS respectively) has a number of immutable data containers that have mutable subclasses. NSMutableArray is a mutable subclass of the immutable NSArray, NSMutableDictionary is a mutable subclass of the immutable NSDictionary, etc. This works fine if you think of mutability as an added feature rather than something that needs to be removed from the superclass. Most importantly, client code should never try to make changes to an object that's advertised as immutable, even if the object happens to be an instance of a mutable subclass. So, if a method returns a NSArray, you might actually get back an instance of NSMutableArray, but you should always treat it as immutable anyway.

There's nothing inherently wrong with mutable subclasses provided you don't make assumptions about mutability in other parts of your code. 

As an example, the Foundation framework that's part of Cocoa and Cocoa Touch frameworks (MacOS X and iOS respectively) has a number of immutable data containers that have mutable subclasses. NSMutableArray is a mutable subclass of the immutable NSArray, NSMutableDictionary is a mutable subclass of the immutable NSDictionary, etc. 

This works fine if you think of mutability as an added feature rather than something that needs to be removed from the superclass. Most importantly, client code should never try to make changes to an object that's advertised as immutable, even if the object happens to be an instance of a mutable subclass. 

So, if a method returns a NSArray, you might actually get back an instance of NSMutableArray, but you should always treat it as immutable anyway.

Source Link
Caleb
Caleb
  • 39.2k
  • 8
  • 95
  • 152

There's nothing inherently wrong with mutable subclasses provided you don't make assumptions about mutability in other parts of your code. As an example, the Foundation framework that's part of Cocoa and Cocoa Touch frameworks (MacOS X and iOS respectively) has a number of immutable data containers that have mutable subclasses. NSMutableArray is a mutable subclass of the immutable NSArray, NSMutableDictionary is a mutable subclass of the immutable NSDictionary, etc. This works fine if you think of mutability as an added feature rather than something that needs to be removed from the superclass. Most importantly, client code should never try to make changes to an object that's advertised as immutable, even if the object happens to be an instance of a mutable subclass. So, if a method returns a NSArray, you might actually get back an instance of NSMutableArray, but you should always treat it as immutable anyway.