I am refactoring my existing code. I've extracted interfaces from my existing classes. I have created a separate class library which holds all such interfaces.
My problem is I have some classes with structures and enums. These classes also have some methods returning these structures and enums.
I want to extract interface from these class. But I am now worried about the structures and enums. I can't have these structures and enums extracted in my interface and hence methods returning structure and enums do not reflect easily in extraction.
How can I overcome this situation wherein I want to have structure and enums in my extracted interface? Do I need to break the structure and have to use it as members of interface? How can I define methods returning structure in interface?
Structures and enums generally shouldn't be nested- unlike classes, they are often part of the 'public contract' of the type, and so you'd typically extract them into their own files and put them in the shared class library with the interfaces.
Related
It is an abstract API upon which more domain specific APIs are based for querying URLs. Should the abstract version (which contains the networking functions, and the data structure) be written as a Class, Struct, or Protocol?
Given your requirements, it should be either a class, or a combination of a class and a protocol.
You cannot use protocol by itself, because it is incapable of holding data
Structs are a poor fit for anything abstract, because Swift structs are good for small types that have value semantic.
One approach that is good for data hiding is to expose a protocol, along with a method to obtain an instance of that protocol, but make the class implementing the protocol private to your implementation. This way the users would have to program to interface, because they have no access to the class itself.
I have two private data structures and five functions in my class, How can I represent the relation between the functions and the data structures in class. Eg: Two of those functions uses the First data structure and three other functions uses the second data structure.
Also How can I represent relation between the functions in the class. eg : among the 5 functions two are public and three are private, one public function in the class calls the other three private functions.
If this is not relevant in class diagram then what is the best solution to represent this in UML.
the interaction of functions and fields is not displayed in a Class Diagram.
Therefore you should use a sequence diagramm. But normaly you do not show the interaction of fields within an Object. You display the interaction on the level of function calls between Objects.
Two things. First, there's a good reason UML doesn't provide notation for depicting relationships & structure within a class. Classes are supposed to be cohesive abstractions of data and function. So if you have any significant structure within a class, you should question whether it should be split into 2 (or more) cohesively abstracted classes.
OK. So that's the backdrop. From your description, how about:
Draw one class for each data structure with one attribute for each structure member
Add a method to each class for each function that operates on the data structure
Add an association between the classes that captures their relationship
Place all the bits above in a package to represent the module
The final point - as in all these things - is to use the tool to illustrate what you want. Don't be overly constrained by the rules of the modelling language. The important thing is that the diagram communicates effectively to you & your collaborators. Satisfying the 'language lawyers' should be much less of a consideration.
hth.
I have a bit confusion in choosing whether to use NSManagedObjet class objects directly as models or whether to create separate classess for models and create data mappers to map data from these model class to NSManagedObject class objects.
Is there any harm in using Core Data objects as models ? What are the pros and cons of both approches?
Thanks in advance,
Regards,
tek3
I read your question and I take it you are not asking whether to use NSManagedObject directly or whether to subclass NSManagedObject, but if you should have your model as separate classes which use Core Data by explicit methods written by yourself.
Core Data is designed to act as the model layer for your application. I do not see any real benefits in having your own model classes, writing an interface for them and implementing it in core data behind the scenes, unless you really need the freedom to give up core data entirely at some point.
I recommend you create your model classes as subclasses of NSManagedObject. You are free to extend those in any way you deem necessary beyond what core data provides you, but at the same time your model classes will have full benefits from the core data framework: faulting, caching, data integrity assurances, cascade deletes, etc...
If you just use NSManagedObject, you will not have the benefit of the convenient "dot.notation" when referring to attributes and relationships.
Also, you will have to retrieve all values with valueForKey and set them with setValueForKey followed by strings. This can be extremely error prone and cumbersome and the resulting code is not nearly as readably as with the dot notation.
Finally, in your object classes you can implement all kinds of additional functionality. Where would you put this code otherwise? Remember the principle of encapsulation that helps produce independent and reusable code.
Are interfaces a layer between objects(different objects) and actions(different object types trying to perform same action)? and Interface checks what kind of object is it and how it can perform a particular action?
I'd say that it's better to think of an interface as a promise. In Java there is the interface construct that allows for inheritance of an API, but doesn't specify behavior. In general though, an interface is comprised of the methods an object presents for interacting with the object.
In duck-typed languages, if an object presents a particular set of methods (the interface) specific to a particular class, then that object is like the specifying class.
Enforcement of interface is complicated, since you need to specify some set of criteria for behavior. An interesting example would the design-by-contract ideas in Eiffel.
Are you asking about the term "interface" as used in a specific language (such as Java or Objective-C), or the generic meaning of the term?
If the latter, then an "interface" can be almost anything. Pour oil on water -- the line between them is an "interface". An interface is any point where two separate things meet and interact.
The term does not have a rigorous definition in computing, but refers to any place where two relatively distinct domains interact.
To understand interfaces in .net or Java, one must first recognize that inheritance combines two concepts:
Implementations of the derived type will include all fields (including private ones) of the base type, and can access any and all public or protected members of the base type as if it were its own.
Objects of the derived type may be freely used in place of objects of the base type.
Allowing objects to use members of more than one base type as their own is complicated. Some languages provide ways of doing so, but there can often be confusion as to which portion of which base object is being referred to, especially if one is inheriting from two classes which independently inherit from a third. Consequently, many frameworks only allow objects to inherit from one base object.
On the other hand, allowing objects to be substitutable for more than one other type of object does not create these difficulties. An object representing a database table may, for example, allow itself to be passed to a routine that wants a "thing that can enumerate contents, which are of type T (IEnumerable<T> in .net)", or a routine that wants a "thing that can have things of type T added to it" (ICollection<T> in .net), or a thing that wants a "thing that wants to know when it's no longer needed (IDisposable in .net)". Note that there are some things that want notification when they're no longer needed that do not represent enumerable collections, and there are other things that represent enumerable collections that can be abandoned without notification. Thus, neither type of object could inherit from the other, but if one uses an interface to represent "things which can enumerate their contents, which are of type T", or "things that want to know when they are no longer needed", then there's no problem having classes implement both interfaces.
I'm building a (very) simple FTP app in Cocoa, and I need to store information on the different types of servers that are supported. So, I've created a ServerType class, which stores all of the relevant information about a single type of server. I then have a ServerTypes class which is designed to manage all of the ServerType classes that are created.
My question is, how to set up the relationship between the two objects. Is there a preferred method to do so?
Also, since Objective-C doesn't support non-instance classes, where should I create an instance of ServerTypes that will have to be used throughout the entire program? Or is there a better way to do that? I need it to be KVC compliant so That I can bind one of the ServerType properties to an NSPopupBox.
I'm fairly new to Cocoa and Objective-C.
To manage a relationship between 2 objects, you have 2 ways: composition or inheritance.
You can inherit from a class to create a subclass then you will have a is-a relationship.
If one object contains another as an instance variable then you will have a has-a relationship.
Here, I think it would be the best to use composition where the ServerTypes objects has an array of all server type objects. Objective-C supports non-instance variable (if that's what you mean), by creating static variable. Then you can use it accross the whole program