What is the difference between data abstract and data encapsulation.
I have knowledge about abstract but I do not know data encapsulation.
Related
I'm drawing a class UML for a JAVA software design. I don't really understand what is a stereotype. The formal definition:
The stereotype is a profile class which defines how an existing metaclass may be extended as part of a profile. It enables the use of a platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass
Is that mean the stereotype should be the name of the parent class? But why there are some superclasses also has a stereotype?
So for example, I have a superclass Animal and a class dog which extends the Animal class, what could be the stereotype of both classes? Also, why there are some classes without stereotype.
What is a stereotype and what are its purpose?
A stereotype extends UML by allowing to categorize some elements in a more detailed way than foreseen natively by UML. It helps to make the model more expressive.
A typical example are the Entity, Control, and Boundary stereotypes. They are used in a use-case driven design: in a class diagram, you can immediately find-out which classes represents the use-case logic (marked as «control» stereotype), which classes represents user-interface with actors («boundary» stereotype), and which classes represents business/domain objects (marked as «entity»).
Another use of stereotypes is to indicate the way a class is supposed to be implemented, for example to mark as «table» classes that correspond to database tables that are related to in-memory objects, or to indicate among the objects which ones are «persistent». An even more common use is to show some concepts that are language specific and have no equivalent in UML. I think in particular to C# «struct» which have a value semantic wheres C# classes have a reference semantic, or C# «property» (which is a stereotype at attribute level).
How are stereotypes defined?
Sterotypes are defined in a profile. You can see a stereotype as a class in a profile diagram.
But it's not an ordinary class that you could relate to other classes in your model. So there is no inheritance at play here. You would never indicate a superclass as stereotype.
A stereotype is a class related to the "metamodel", which means the UML standard elements defined in the UML standard. So it's a class of classes (or a class of associations, or of any other UML element).
To elaborate on your example, with an abstract superclass Animal and concrete sub-classes Cat and Dog:
you could affect them all an «entity» profile, because they all belong to the domain model.
if you would want to store the objects in an RDBMS using the concrete table inheritance, you may use a stereotype «persistent» for Cat and Dog (since concrete table inheritance pattern does not implement persistence for the abstract classes)
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.
In almost all EF methods that use inheritance, I see that the parent class is marked as abstract. Is there any reason why this is done? Or is it just so the abstract class cannot be instantiated?
No, that is not mandatory, your base class could not be abstract, but as you already said it's the most common. It's like a inheritance by generalization, which is extracting shared characteristics from two or more classes, and combining them into a generalized superclass, that's why is common see the base class as abstract.
In EF there are three different approaches to representing an inheritance hierarchy:
Table per Hierarchy (TPH): Enable polymorphism by denormalizing the
SQL schema, and utilize a type discriminator column that holds type
information.
Table per Type (TPT): Represent "is a" (inheritance) relationships as
"has a" (foreign key) relationships.
Table per Concrete class (TPC): Discard polymorphism and inheritance
relationships completely from the SQL schema.
In the last approach if the base class was concrete, then an additional table would be needed to hold instances of that class.
In summary, if the base class is abstract or not depends more on your side if that make sense or not in the model you are trying to represent.
I'd assume because the methods you override are also abstract? Can't have an abstract method on a non-abstract class.
So, for example, it never makes sense to instantiate a plain old DbContext -- you always need collection properties and such. The base DbContext provides functionality which all DbContext derivatives would need (connecting to a database, etc), but isn't useful as a stand-alone object.
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.
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.