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.
Related
How would you prevent a client from directly instantiating your concrete classes?
For example, you have a Cache interface and two implementation classes MemoryCache and DiskCache, How do you ensure there is no object of these two classes is created by the client using the new() keyword.
Thanks
When designing software (think UML diagrams for example) and real world objects.
How does one identify a suitable case for an Abstract class?
For example if we had an [Employee] and [Fireman] and [paidFireman] and [unpaidFireman]...I am having trouble seeing whether a Fireman or Employee should be abstract and why?
Abstract classes are one of those more esoteric constructs in UML. Since classes are already an abstraction of real world things, an abstract class is even one level higher. Abstract classes can not be instantiated (since it is assumed they miss something for a real life). Whether you say that Fireman is abstract while the paid/unpaid are not, is a pure point of view and must be argued in the specific domain.
As a rule of thumb: leave abstract classes out of the door until you come to a point where you feel the urgent need for it. Introducing abstractness limits your model (and can help to avoid some malformed results of it). But without those limits the model is still valid as long as the architect sticks to common sense rules.
It mainly depends on your functional requirements.
If it makes sense in your application just to have simple employees (without designating them as firemen, policemen, or craftsmen), then the class may not be abstract, as the application will have to make instances just of the Employee class.
If that doesn't make sense, i.e. the occupation of each of your employees needs to be known at creation time, abstract classes come into consideration. But still they aren't necessary in every case. The easiest way to make sure the occupation is known is to model it as a mandatory attribute. Introducing a subclass only makes sense if there is specialized behavior for each of those subclasses. If, e.g., the salary of the firemen is calculated as 50$ * count of the fires he exstinguished, but the salary of the policemen is 1000$ + 50 * rank, then you model an abstract operation getSalary() in the Employee class, which will be concretely specified and implemented in each of the subclasses.
As the concept of interface also got mentioned in one of the answers, an interface describes the obligation to implement certain operations in all classes realizing that interface. That's much the same as an abstract operation in an abstract class. But the abstract class can contain much more than an interface: attributes and non-abstract operations.
So the rule of thumb is: For concepts of your domain for which interface and behavior can be fully described, use non-abstract classes. For concepts for which only interfaces and no behavior can be described, use interfaces. For concepts for which interfaces and part of the behavior can be described, use abstract classes.
There are many uses for an abstract class. An abstract class is one that cannot have any direct instances.
In software design, it is one way to describe an interface. Some of the declared operations can be implemented in the superclass. Any remaining implementations must be specified in sub-classes. Regardless of where the implementations exist, an abstract class means there can be no direct instances, only instances of some non-abstract subclass.
In a domain analysis, an abstract class is a way of modeling an abstraction. For example, think of the abstraction Role. It is useful to say that a Person plays a number of Roles. However, there is no instance of a Role that makes sense, without it also being a more specific kind of Role, such as Employee, Fireman, or Teacher. For this situation, you not only want Role to be abstract, you also want a covering axiom. For more on that, please read https://stackoverflow.com/a/35950236/2596664.
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 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.
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