Abstract Concepts in C# – using Delegates
0
Citation
0
Reference
20
Related Paper
Abstract:
Many developers, especially beginners, often find it difficult to realize and understand the benefits and advantages of using abstract concepts specific to the C# language, like delegates. C# doesn't help matters by allowing us to declare field-like events which are automatically backed by a delegate variable at the same name. Another source of confusion is due to the overloading of the term “delegate”. Sometimes it is used to mean a delegate type, in other cases it can be used to mean an instance of a delegate type. We shall use “delegate type” and “delegate instance” to distinguish between them, and “delegate” when we are talking about the whole topic in a general sense. In this context, the present paper aims to clarify all these aspects related to the use of delegate in the specific context, providing concrete examples in this respect. Moreover, this paper presents the main benefits of using delegates in C# language.Keywords:
Delegate
Confusion
Cite
The interface between a user and a software system should match the needs and background of the user. Many query languages are built to aid clerks and managers in the performance of their jobs. Therefore, a good query language would require no low level programming skills of its users. Usually very high level nonprocedural languages are used because they eliminate low level artifacts such as loops. An appealing high level language would be the user's natural language. Natural language should require no training or refresher courses for successful use.
Interface (matter)
Data control language
Cite
Citations (0)
We present an effective way to teach recursion which we believe nearly anyone can understand. Most people are familiar with the concept of someone delegating a task to another person. Our method is based on this idea and presents recursion as a particular form of task delegation. This simple form of delegation is similar to the Little People metaphor. We then extend this form to a more general description of task delegation. We believe that this extension improves understanding of how to program recursive procedures (especially by end-users and novice programmers). Finally we discuss the initial design of a recursion visualization based on task delegation for the Greenfoot programming environment.
Delegation
Cite
Citations (18)
Despite a lot of talk about “user-friendly” systems, little is seen when it comes down to the implementation, mainly because most programming languages and time-sharing systems make it relatively difficult to give life to the theoretical concepts.To demonstrate the various features of APLSV truly facilitating the implementation of user-friendly systems, we use a very simple application: mailing lists. This comprises of:- creation and maintenance of a moderate-sized data base (ca. 60 K characters).- selection of addresses by descriptors combined with boolean logic operators.The following topics will be discussed:1. System Description What does the system do (as far as understanding the following general conclusions is concerned)?2. HELP-Feature What is a simple yet powerful mechanism of aiding the inexperienced user?3. User Reaction How behaves the “average” user? What problems does he have and how are they solved?4. Design Stability Since the only constant thing in (programming) life is change, where are the major features requiring frequent adaption?5. End-User and Programmer Productivity Why and to what end was this effort undertaken, and how much work did go into it?6. Program Structure Where did a top-down design show its benefits and what (if any) are the drawbacks?7. Programming Tricks and Tips Where are the features of APLSV exploited, like the “call by name” provided by the “execute” operator?8. General Observations What are the DOs and DON'Ts in designing man-computer dialogs?9. Outlook From the observation of the acceptance of the current version of the system, what areas of required enhancements become visible? What is the summary of the experience?
Cite
Citations (0)
Smalltalk
Programmer
Cite
Citations (0)
To have a language for an exact description of systems is an advantage not only for a communication among people (systems designers, investigators, reviewers, implementers, users etc.) but also among an investigator and computer (for modeling, tests of completeness and/or consistency of the description etc.). The start point how to realize that way consisted in some process-oriented simulation languages designed and implemented in the 60-ies of the last century. Note that the process orientation covers an offer to use so called quasi-parallel sequencing (further QPS) that permits a separate formulation of lives of system elements, that mutually switch in the common time flow. Nevertheless, beside the limits of each of those languages (implying that descriptions of some systems in a given language were either very difficult or even impossible), another difficulty rose during the development of our civilization: the inner control and relating communication in the systems became more and more complex and sometimes even rather contradictory (in the systems influenced by antagonistic and/or mutually competing entities) decisions rise and are implemented inside the systems.
The first obstacle (limitation) was surmounted by advent of the object-oriented programming (classes, subclasses and procedures/methods/functions), but, unfortunately, soon after the spread of that programming method further from its original simulation stimulus incorporated in Simula, QPS disappeared from may be every object-oriented programming language designed since 1980, although that sort of sequencing existed even in some simulation languages designed before 1960.
The second obstacle can be illustrated as follows: when one starts to describe a system he needs to prepare and order general notions used then by the description, but when one exists as a component in the system (a human or a computer) and influences it he needs to express something similar - namely general notions semantically ordered - and than to use them. The antagonistic views practiced by influencing components show that may express general notions mutually in a different way but also differently from the way in that they were considered by the author of the description of the system, i.e. by a person existing outside the system. More exactly, such an author, describing the system, must express not only the contents of the general notions how he recognizes them, but also that of notions how the inner components of the described system consider them. Moreover, he has to separate different interpretations of the notions, although they carry the same names and often pay role in a common way.
The obstacles may be surmounted very well by using programming languages that are not only object-oriented and, naturally, process-oriented (permitting QPS) but permit local classes, too. The number of such languages is very small and, unfortunately, with the exception of the above mentioned old Simula, they do not allow QPS. The users of some of them (like Java) offer subrogating QPS with help of threads, i.e. by something that does not concern the described system but only its computer model. It should be respected that the suitable language should strictly separate between what should exist in the described systems and what in its computer model.
The presentation will contain some existing applications in transport, machine production, health care and computer systems.
Simula
Control flow
Cite
Citations (0)
Discussion in this session centered around two major topics: experience using a particular language for systems programming and features which are required or desirable in a systems programming language. In general, as one might expect, the users of a particular language were happy with that language and felt they had made the right choice, even though they were not completely satisfied. There seemed to be general agreement that a higher level language than machine language (assembly language) should be used for systems programming. There was considerable difference of opinion as to how high level the language should be. There was a similar difference of opinion as to what features are desirable, and even necessary, in a systems programming language. Although the session was organized so as to discuss the two major topics separately, there was considerable discussion of desirable and necessary language features mixed in with the discussion of experience with specific languages. The session opened with a report by Bob Freiburghouse on the use of PL/I for implementation of Multics. "In general the project was successful. We're not about to switch to some other programming language. But we would like to enforce more discipline. I think we would like to recognize and enforce a subset of all this. He listed a number of key features, the most important of which was external procedures and external variables. Other important features included structured data with controlled packing, recursion, block structure, high level control statements, type checking, pointers and dynamic storage allocation, and % include . A few extensions were made to the language such as pointer valued functions, functions to construct and take apart pointers, P and V operations, and a notation for referencing Multics segments. In addition, a support routine called the binder was implemented. Using this routine one can combine a number of procedure and data segments into a single module. References to this module can be made using only designated names, all other names originally associated with the segments in the module will be hidden, that is, undefined outside the module.
Language primitive
Low-level programming language
Cite
Citations (0)
ion and design First, we need to highlight features of Java that are very helpful for designing good programs. These provide the programmer with support for abstraction which means that you can forget nasty details of some parts of the program because you ‘abstract them away’while you concentrate on other parts. The main abstraction tool in Java is the class. If the programmer makes good design decisions on which classes there should be within a project, it makes the rest of the programming much simpler. For example, suppose we are planning to build a large project for a bank to use in managing its business. Suppose we decide that one useful class is the Accountwhich represents what anyone familiar with banking will understand by a bank account. This immediately means that an account object has associated methods for doing things like depositing money, withdrawing it, getting a current balance, dealing with interest .... Having chosen the Account class as the right abstraction, we can think about the rest of the system, knowing that when we need to do 13.3 Structural issues: abstraction, prototyping, quality, reuse 177 something with accounts we will have appropriate methods available for this. The critical thing is that we don’t need to think at all about the internal details of the Account class. So abstraction enables us to build more complex systems that deal with bank accounts because we can think in terms of the abstract bank account. When you are designing a program, one of the most important tasks is to find the right abstractions for the task at hand. This is a job that is best done over a period of time and in discussion with other people so that you can debug your thinking about things. Essentially, you need to create new abstractions that enable you to think about the current task. So, in the banking example, you should ask yourself: ‘suppose I had a bunch of objects that were really useful for this task and that enable me to think about how to do it – what would those be?’ Similarly, within a class, we design a collection of methods. We have already mentioned the things we want to be able to do for an Account class. Each of these actions needs to be an interface method. The full set of methods constitute an extended vocabulary for thinking about objects. For example, a personal planner system might have a calendar class. This will have various interface methods that do things like get the calendar for a particular month. As we start designing this class, we will come to realise that there are a number of places that we need to be able to determine if a particular year is a leap year. As soon as we realise this, we decide that there should be a method for this. We need to write its header. At this point, we need to decide whether this method is needed at the interface. Remember, we want to localise each aspect of a program as far as possible. If this method is only needed inside the calendar class, it should be an internal method – invisible at the interface. This is an example of hiding details of the program where possible. Then we make abstraction work for us. We ignore the details of this method, simply assuming that they will be filled in properly in due course. We then go on designing the other methods which can then use it. Essentially abstraction is like extending the vocabulary of Java. Java has many useful things. For example, it supplies several mathematical functions like sqrt which calculates square roots. This eases the task for the programmer whose code needs square roots. The class libraries also enable the programmer to work at a higher level of abstraction, ignoring details of how these work and getting into the issues of the current task. Structural Prototyping A structural prototype is a cut down version of a program which shows the structure of the complete version. It should have the major classes written in skeleton form. The methods will only be present as stubs. This means that there is little or no code within them, but they will have a proper header with parameters and return values clearly shown, as well as method comments, preconditions, and postconditions. In a program development environment such as JBuilder or BlueJ, this means that the project picture will show the main classes and how they relate to each other. When you look at the interface to each of these, you should then be able to see the methods and the overall documentation for the class including the name of the author. If you expand the interface view to see the full code details, you will typically see there are no internal methods and most interface methods will do nothing. If the project has been well planned, the final system will look very similar to the prototype at the project and interface levels. A structural prototype is very valuable for several reasons: 178 Chapter 13 Software Engineering Concepts • the project design can be reviewed before a huge amount of programming effort has been expended and poor designs can be revised (or completely discarded); • the group members working on the project can get a good understanding of the whole task and how their contribution fits in; • the allocation of work between group members can be revised so that, for example, really important classes that are pivotal to the success of the project are allocated in a way that ensures they will be done well and on time while less critical classes can be planned as things to do if there is time. Design quality terms Good design is characterised by
Programmer
Abstraction
Cite
Citations (0)
There are many ways to define and call a real-time system with respect to their intended applications, but in a general sense, as its name implies, it is a system that carries out applications that are dedicated, focused, and above all are time sensitive. Depending on how the application needs to be carried out, there are systems that must execute their tasks at certain times; some give you a range of time to execute an application, and the rest want you to execute the application but are not too pushy about it. They are called hard real-time systems, soft real-time systems, and general purpose computers respectively. Depending on who we consult with, there are a lot of discussions in categorizing the computer systems of which some get into deep philosophical discussions about the concept of time. For the sake of our discussion, the above definitions about real-time systems can suffice.
Rest (music)
Cite
Citations (0)
In the previous chapter, you saw how vague statements can be transformed into a concrete and unambiguous specification of the problem logic realized as a set of executable models. The models contain problem-oriented concepts that you can discuss with your customers and users to make informed decisions about the relevant problem logic. Although completed models define exactly what the implementation should do, they do not say just how to do it.
Executable
Cite
Citations (0)
Code (set theory)
Advice (programming)
Cite
Citations (0)