Related
I'm learning PostgreSQL and I'm currently learning types and how to create them. However, I can't understand when it's better to create a table and make a relation with another table than just create a type.
For example, in this class diagram "Team" has got "equiment" of type "Equipment". I don't even know if this diagram is correct, but if so, why is it better to make "Equipment" a type instead of a table?
The model
This diagram is incorrect. It says that a Team is composed of Equipments that will be deleted if the Team gets deleted. Remove the black diamond and it'll be fine.
By the way, the arrow is not wrong, but it is not necessary if your UML class diagram is meant for a relational model: the implementation of an association with an RDBMS will always make it bidirectional.
The database
A user defined data type is an SQL features that allows to create a composite type made of several elements. The goal is that you can use the newly created types like the build-in types.
If you create two user defined types in postgresql for your model, you will therefore have anyway to create two tables each with a column of the given type (more explanations here). So there is no decisive advantage to opt for SQL types for implementing UML classes.
The creation of types is mostly advisable in SQL if you are working with value objects. Value objects have no identity and are solely defined by the values they carry. They are generally as type of several attributes in the same or in different classes/tables.
By the way, in an UML model, you should in principle represent value types with «datatype» classifiers. But some people model such value types with normal classes and it's a topic of discussion.
A typical example of value object in a business application is a CurrencyAmount that would be composed of a monetary value and a currency code.
I was going through the Software Foundations book (http://www.cis.upenn.edu/~bcpierce/sf/Basics.html). In the second paragraph of Introduction, it is mentioned that as functions are treated as first class values, they can be stored in a data structure. A quick Google search for the applications of this turned up acid-state (http://acid-state.seize.it/) which probably uses this for storing functions (please correct me if I am wrong). Are there any other applications in which storing functions as data in data structures is/can be used? Is storing functions as data a common pattern in Haskell? Thanks in advance.
Edit: I am aware of the higher order functions.
A simple and easily-used functions-in-data-structure example is that of having a record containing functions (and possibly data).
A good example is in Luke Palmer's blog post Haskell Antipattern: Existential Typeclass where he explains that rather than try to reproduce an OO-like class for widgets, with many instances and then store your UI widgets in an existentially quantified list, you're better off making a record of the actual functions you'll use and returning that instead of retaining your original datatype - once you're existentially quantified, you can't get at the original datatype anyway, so you don't lose anything in expressiveness, but gain a lot in manipulatability. He concludes
Functions are the masters of reuse: when you use an advanced feature, you need a yet more advanced feature to abstract over it (think: classes < existential types < universally quantified constraints < unknown). But all you need to abstract over a function is another function.
This means that we can write higher-order functions to deal with those functions, and pass them around and manipulate them easily, since they're data.
First class functions are extremely useful -- I would contend that their main use case is in higher order functions, which simplify many problems that require more complex patterns in other languages, like Java.
Two of the questions that often come up in the Uni exam, where I study, are:
Define data types. Classify and explain datatypes
Define data structures. Classify and explain data structures
Somehow, aren't they the same thing ?
Consider that you are making a Tree<E> in Java. You'd declare your class for Tree<E>, add methods to it and somewhere you would do Tree<String> myTree = new Tree<>(); to make a tree object.
Your data 'structure' is now a data 'type'.
Say if you were asked a question: Of what type is the variable myTree? The answer would be, Tree<E>. Your data 'structure' is now a data 'type'.
Now since they are the same, they will be classified in the same way depending on what basis you want to classify them on. Primitive or non primitive. Homogeneous or heterogeneous. Linear or hierarchical.
That is my understanding. Is the understanding wrong ?
I would like to correct the following to start - you created a class called "Tree" and an object called "myTree", not a variable called "myTree" of datatype "Tree". These are different things.
The following is the definition of a data type:
A data type or simply type is a classification identifying one of various types of data,
such as real-valued, integer or Boolean, that determines the possible values for that type;
the operations that can be done on values of that type; the meaning of the data;
and the way values of that type can be stored.
Now, as per Wikipedia, there are various definitions for "type" in data type.
The question you have asked is a good one. There are data types in today's modern languages, that are referred to as Abstract Data Types or ADT in short. The definition of an ADT is:
An abstract data type (ADT) is a mathematical model for a certain class of data structures that have similar behavior; or for certain data types of one or more programming languages that have similar semantics. An abstract data type is defined indirectly, only by the operations that may be performed on it and by mathematical constraints on the effects (and possibly cost) of those operations.
It is also written that:
Abstract data types are purely theoretical entities, used (among other things) to simplify the description of abstract algorithms, to classify and evaluate data structures, and to formally describe the type systems of programming languages. However, an ADT may be implemented by specific data types or data structures, in many ways and in many programming languages; or described in a formal specification language.
Meaning that ADT's can be implemented using either data types or data structures.
As for data structures:
A data structure is a particular way of storing and organizing data in a computer so that it can be used efficiently.
Many textbooks, use these words interchangeably. With more complex types, that can lead to confusion.
Take a small example: it's something of a standard to use b-tree for implementation of databases. Meaning, we know that this type of ADT is well suited for such type of a problem and can handle it more effectively. But in order to inject this effectiveness in an ADT you will need to create a data structure that will give you the desired output.
Another example: there are so many trees like b-tree, binary-search tree, AA tree, etc. All these are essentially of the type of a tree, but each one is in it's own a data structure.
Refer: List of data structures for a huge list of available structures.
The distinction is between abstract and concrete data structures. Some CS textbooks refer to abstract data structures as "data types", which is confusing because not all data types are data structures. They use "data structure" to specifically mean a concrete data structure.
An abstract data structure, also called an abstract data type, is the interface of the data structure. Java often represents them using interfaces; examples are List, Queue, Map, Deque, Set. (But there are others not represented in Java, such as bags/multisets, multimaps, graphs, stacks, and priority queues.) They are distinguished by their behavior and how you use the data structure. For instance, a set is characterized by forbidding duplicates and not recording order, whereas a list allows duplicates and remembers the order. A queue has a restricted interface that only lets you add to one end and remove from the other.
A concrete data structure is an implementation of an abstract data structure. Examples are ArrayList and LinkedList. These are both implementations of lists; while their list interface is the same, the programmer might still care about their different performance characteristics. Note that LinkedList also implements Queue.
Also, there exist data structures in programming languages that have no type system. For example, you can modell a Map in LISP, or have a dictionary in Python. It would be misleading to speak of a type here, as type does IMHO only make sense with respect to some type system, or as an abstract concept like "the set of all values that inhabit t".
So, it seems that data structure has a connotation of an concrete implementation of some abstract type. If we speak of some object in a programming language with type system, OTOH, we would probably say that "it has type XY".
I am struggling to find a way to make POCOs work with Linq-to-Sql when my domain model is not table-driven - meaning that my domain objects do not match-up with the database schema.
For example, in my domain layer I have an Appointment object which has a Recurrence property of type Recurrence. This is a base class with several subclasses each based on a specific recurrence pattern.
In my database, it makes no sense to have a separate AppointmentRecurrences table when there is always a one-to-one relationship between the Appointment record and its recurrence. So, the Appointments table has RecurrenceType and RecurrenceValue columns. RecurrenceType has a foreign key relationship to the RecurrenceTypes table because there is a one-to-many relationship between the recurrence type (pattern) and the Appointments table.
Unless there is a way to create the proper mapping between these two models in Linq-to-Sql, I am left with manually resolving the impedence mismatch in code.
This becomes even more difficult when it comes to querying the database using the Specification pattern. For example, if I want to return a list of current appointments, I can easily create a Specification object that uses the following Expression: appt => appt.Recurrence.IsDue. However, this does not translate into the Linq-to-SQL space because the source type of the Expression is not one that L2S recognizes (e.g. it's not the L2S entity).
So how can I create the complex mapping in Linq-to-SQL to support my domain model?
Or, is there a better way to implement the Specification pattern in this case? I'd thought about using interfaces that would be implemented by both my domain object and the L2S entity (through partials) but that's not possible with the impedence mismatch of the two object graphs.
Suggestions?
Unfortunately, Linq to SQL pretty much forces you into a class-per-table model, it does not support mapping a single entity class to several database tables.
Even more unfortunately, there are very few ORM's that will support more complicated mappings, and vanishingly few that do and offer decent LINQ support. The only I'm even remotely sure of is NHibernate (our experiences with Entity Framework rate it really no better than L2S in this regard).
Also, trying to use the specification pattern in LINQ expressions is going to be quite the challenge.
Even with ORM's, and even with a really strong abstracting ORM like NHibernate, there is still a large impedence mismatch to overcome.
This post explains how to use the specification pattern with linq-to-sql. The specifications can be chained together which builds up an expression tree that can be used by your repository and therefore linq-to-sql.
I haven't tried implementing it yet, but the linq-to-entities version is on my to-do list for a project I am currently working on.
A rough definition of a data structure is that it allows you to store data and apply a set of operations on that data while preserving consistency of data before and after the operation.
However some people insist that a primitive variable like 'int' can also be considered as a data structure. I get that part where it allows you to store data but I guess the operation part is missing. Primitive variables don't have operations attached to them. So I feel that unless you have a set of operations defined and attached to it you cannot call it a data structure. 'int' doesn't have any operation attached to it, it can be operated upon with a set of generic operators.
Please advise if I got something wrong here.
To say that something is structured implies that there is a form or formatting that defines HOW the data is structured. Note this has nothing to do with how the data is actually stored. You could for example create a data structure that exists entirely within a single Integer, yet represents a number of different values.
A data structure is an arbitrary construct used to describe how to store data in a system. It may be as simple as a single primitive, or as complex as a class. So the answer is largely subjective. It's "yes" if you decide to use a primitive as such, that a simple primitive may be considered a primitive data structure, because it describes HOW you wish to store an element of data. The answer is also "no", because it describes an element of a structure and not necessarily the whole structure in itself.
As for how this relates to operations, strictly speaking a data structure has nothing to do with behaviour, it is simply a storage mechanism. Preserving consistency of data is really a behavioural thing. Yes, your compiler probably spits out errors if you try to shoe-horn a 32-bit value into a Byte, but that's symptomatic of the behaviour of the system (Ie: compilation) acting on the data structure of your application, of which your primitives are an element.
I don't think your definition of data structure is correct.
It seems to me that a struct (with no methods) is a valid data structure, but it has no real 'operations'. And that's not important. It's holding data.
To that end, and int holds data, an Object holds data. They are data structures (technically).
That said, I don't ever find myself saying "What datastructure shall I use? I know! an int!".
I would say you need to re-evaluate the meaning of "data structure".
Your definition of a data structure isn't quite correct. A data structure doesn't necessarily have any attached behaviors or operations. An ADT or Abstract Data Type is what you are describing as a data structure. An ADT includes the data and the behaviors or operations that work on that data. An int by itself is not an ADT, but I suppose you could call it a data structure. If you encapsulate an int and its operations then you have an ADT which is what I think you are trying to describe as a data structure. Classes provide a mechanism for implementation of ADTs in modern languages.
wikipedia has a good description of abstract data types.
I would argue that "int" is a data structure - it has a defined representation and meaning. That is, depending on your system, it has a specific length, a specific set of operators available to it, and a specified representation (be it twos-compliment). It is designed to hold "integer numbers".
Practically, the distinction isn't particularly relevant.
Primitives do have operations attached to them; however, they may not be in the format of methods as you would expect in an object-oriented paradigm.
Assignment =, addition +, subtraction -, comparison ==, etc are all operations. Especially if you consider that you can explicitly define, override, or overload these operations for arbitrary classes (i.e.: data structures) in some languages (e.g. C++), then the primitive int, char, or what have you, are not very different.
Primitive variables don't have operations attached to them. So I feel that unless you have a set of operations defined and attached to it you cannot call it a data structure.
'int' doesn't have any operation attached to it, it can be operated upon with a set of generic operators.
Generic? Then how come 2+2 works, but "ninja" + List<float> doesn't? If the operator was generic, it'd work on anything. It doesn't. It only works on a few predefined types, such as integers.
Ints certainly have a set of operations defined on them. Arithmetic operations such as addition, subtraction, multiplication or division, for example. Most languages also have some kind of ToString()-like functionality defined on integers. But you can't do just anything with an int. For example, you can't pass an int to a function expecting a string. ints have a very specific set of operations defined on them. Those operations just aren't member methods. They come in the form of operators and non-member functions or member methods of other classes. But they are still operations that work on integers.
I don't think, (ref: Wikipedia entry) that Data Structure includes the definition of permissible operations (on operators). Of course, we could cite the C++ class as a counter-example in which we can define overloaded operators. At the same time, we define a structure as just a composite/user defined datatype and do not declare any permissible operations on them. We allow the compiler to figure that out.
'int' doesn't have any operation attached to it, it can be operated upon with a set of generic operators.
Operations are intrinsically linked with the things that they operate on; there's no such thing as generic operations.
This is true in the mathematical sense (< works for in set of integers, but has no meaning for complex numbers), and also in the computer scientific sense (evaluating a + b requires that a and b are or can be converted to compatible types on which the + operation is defined).
Of course, it depends what you mean by "data structure." Others have focused on whether your definition is correct and raise good questions. But what if we say, "Let's ignore the term for now, and focus on what you described?" In other words, what if look at
A piece of data that has a designated interpretation of its value
A set of operations on that data
Then certainly, int qualifies. (If there were no operations on int, we'd all be stuck!)
For a more mathematical approach to programming that begins with these questions, and takes them to what some have called "an algebra of computation," see Elements of Programming by Alex Stepanov and Paul McJones.