It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I see abstraction in processes.
I see abstraction in data.
I see that abstraction is losing the unimportant details.
I see that abstraction is giving a group of elements a name and treating them as one unit. (But I don't know why that is considered abstraction. So, please I need clarification on this particular point)
I know there are also levels of abstraction, and although the name implies something, I don't have a practical example, and I can't think of a specific one I'm confused about the definition of abstraction.
Can somebody write a comprehensive article? Scratch that. Can somebody give a comprehensive answer?
EDIT:-
Thank you for your answers.
However, I was looking for a generalized answer.
For example, I'm reading an article in which procedures are considered abstractions.
However, here the answers are about abstract classes in C# and Java, (until now.)
Thank you again.
Abstraction is the technique of hiding implementation. At it's core there's not much more to that answer. The bulk of meaning to abstraction come from how and why it is used.
It is used for the following scenarios
Reduce complexity. (Create a simple interface)
Allow for implementation to be modified without impacting its users.
Create a common interface to support polymorphism (treating all implementations of the abstracted layer the same.
Force users to extend the implementation rather than modify.
Support cross platform by changing the implementation per platform.
Quite simply, abstraction is the art of limiting your dependencies. The less you depend on, the more abstract you are. For example, if you write a DirectX renderer, then you're abstracted from what graphics card vendor and model you're running on. If you write another layer, you can be insulated from what OS you're running on.
Abstraction is hiding details of specific implementations and share common details among implementations. Example is java.util.List, java.util.ArrayList and java.util.Map. List is the parent (the abstraction), ArrayList and Map are specific implementation.
You want to do this whenever you have shared code between different classes, so that you don't repeat your code which is bad.
Abstraction is very useful in code reuse, dynamic behavior and standardization. For example, there is a method that you are using and it accepts a List, so to use this method, you can send any object that has list as its parent. Now inside this method, there could be different implementations depending on what is the type of the passed object, so you can achieve a dynamic behavior at run-time. This is very useful technique when you design a framework.
I am not sure if you are supposed to recommend books and if so let me know and I will delete my post but I like Pro C# by Troelsen. Abstraction is like an Interfaces but Interfaces do not allow you to define constructor(s). It is for generalizing. Like I have a grid I want to display some user fields in. The fields can be text, enumeration, single-value, multi-value. I built an abstract class FieldDef with an abstract string property DispValue. Then the various field type inherit from FieldDef. In the grid I have simple string to display. Then when the user updates a field properties and methods specific to the field type are exposed. The other example is all mammals have common proprieties but as you drill down you expose more properties but there is a single generalized view (interface) for all mammals and by inheriting from mammals there is a way to search across and display properties common to all mammals.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
The community reviewed whether to reopen this question 2 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
More specifically, how do you model a functional program, or one developed using the Functional Style (without classes) using a diagram, and not textual representation.
Functional programmers generally don't have a lot of use for diagrams. Many functional programmers (but not all) find that writing down types is a good way to encapsulate the design relationships that OO programmers put into UML diagrams.
Because mutable state is rare in functional programs, there are no mutable "objects", so it is not usually useful or necessary to diagram relationships among them. And while one function might call another, this property is usually not important to the overall design of a system but only to the implementation of the function doing the calling.
If I were feeling a strong need to diagram a functional program I might use a concept map in which types or functions play the role of concepts.
UML isn't only class diagrams.
Most of the other diagram types (Use case diagrams, activity diagrams, sequence diagrams...) are perfectly applicable for a purely functional programming style. Even class diagrams could still be useful, if you simply don't use attributes and associations and interpret "class" as "collection of related functions".
Functional programmers have their own version of UML, it is called Category Theory.
(There is a certain truth to this, but it is meant to be read with a touch of humour).
UML is a compendium of different types of modeling. If you are talking about the Object Diagram (Class Diagram), well you are not going to find anything that fits your desired use. But if you are talking about an Interaction Diagram (Activity Diagram) or Requirements Diagram (Use Case Diagram), of course they will help you and are part of the UML base.
To model a functional program, using a diagram, and not textual representation, you can use notation like the one used to program in Viskell or Luna
I realize this is an old thread but I'm not understanding the issue here.
A class is merely an abstraction of a concept that ties the functionality of it's methods together in a more human friendly way. For instance, the class WaveGenerator might include the methods Sine, Sawtooth and SquareWave. All three methods are clearly related to the class Generator. However, all three are also stateless. If designed correctly, they don't need to store state information outside of the method. This makes them stateless objects which - if I understand correctly - makes them immutable functions which are a core concept in the functional paradigm.
From a conceptual perspective I don't see any difference between
let Envelope Sine = ...
and
let Envelope Generator.Sine = ...
other than the fact that the latter might provide greater insight into the purpose of the function.
UML is an object approach because at graphical level you can not define functional modeling. A trick is to directly add constraints and notes at model and not in the diagram levels. I mean that you can write a full functional documentation on each model element directly in the metamodel and only display an object view using the UML editor.
This is maybe stupid but I found this demo in French language exactly on the same subject and using EclipseUML Omondo :
OCL and UML 2.2 (demo in French language 3mn): http://www.download-omondo.com/regle_ocl.swf
This demo explains how to add constraints directly on methods at metamodel level. The interesting point of this demo is that using a single model for the entire project allows to be flexible enough to extend traditional UML and avoid SysML, BPMN, DSL additionals models because all information is built on the top of the UML 2.2 metamodel. I don't know if it will be a success but this initiative is very interesting because reduce modeling complexity and open new frontiers !!
I haven't actually tried modelling a large system in UML and then going for a functional implementation, but I don't see why it shouldn't work.
Assuming the implementation was going to be Haskell, I would start by defining the types and their relationships using a class diagram. Allocate functions to classes by their main argument, but bear in mind that this is just an artefact of UML. If it was easier to create a fictional singleton object just to hold all the functions, that would be fine too. If the application needs state then I would have no problem with modelling that in a state chart or sequence diagram. If I needed a custom monad for application-specific sequencing semantics then that might become a stereotype; the goal would be to describe what the application does in domain terms.
The main point is that UML could be used to model a program for functional implementation. You have to keep in mind a mapping to the implementation (and it wouldn't hurt to document it), and the fit is far from exact. But it could be done, and it might even add value.
I guess you could create a class called noclass and put in functions as methods. Also, you might want to split noclass into multiple categories of functions.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
What are the limitations of using ApplicationBlocks (An Introduction and Overview of the Microsoft Application Blocks) for ASP.NET/VB.NET applications? I have found lots of websites that talk about the benefits e.g. divorcing the data tier from the web tier, but I cannot find a web page that discusses the limitations.
I don't think you can really get a plain list of disadvantages. Microsoft Enterprise Library is a good library, well documented, rich and with tons of features.
You should change your question to "When I do not need to use it?". Of course this question should be repeated for each block. I'll try to summarize a little bit.
For every block you should consider to do not use the library when you do not need its complexity. Features doesn't come without a cost and the most obvious one is complexity (first in deploying and configuration). If you have to document and your user have to change application's configuration you may need to provide some tool or a lot of documentation. Complexity can be hidden in code too, even if EL designers tried to make everything easy it can't be as easy as a raw solution.
Second important disadvantage is obviously the speed. Layers of abstraction can't be for free and you'll pay a speed cost for that. In some cases you may do not care (simple Logging, for example) but it may be a problem in other cases (so again the answer is "it depends"). Think, for example, to Unity Application Block: you'll get all the power of injection but you'll pay a great cost for this.
So when you should use it? In my opinion a big goal of this library is that you do not need to use it all together. You can pick blocks you need when you need them. It's very common, for example, to use Logging and Exception Handling but you may not need Unity in whole your life. The Data Access Application Block is a very thin layer above ADO, it simplifies many common tasks but you do not gain the level of abstraction you have, for example, with LINQ to SQL or Entities (hey, do not forget they have very different purposes) and you should consider to use it only if everything else can't suit what you need.
So, finally, in my opinion you should consider each block and use it only and only if you really need all the complexity that comes with an Enterprise level library. It's not designed for small single user applications (even if sometimes you may find that some Application Blocks may be great for a specific task). Its drawbacks aren't little: complexity and speed can't be ignored (both for short term solution and long term maintenance plans). Moreover if you really need all its power you'll find it's not as easy as a "ready-to-go" solution, to have the control you'll need to write more code.
The DevExpress XAF does much basis work for you, it creates a database based on your business objects, and dynamically generates a UI based on these, with basic functions like add, delete, sort etc. already present.
This leaves me wondering how to go about properly designing and modelling an application built on this framework. I could only model my business objects, or I could identify functions provided by the framework and include them in a details model down to sequence diagram level, but so much is being done by 'external' calls that I feel I would be wasting valuable time.
I am hoping someone with experience modelling application designs for this specific framework can give me some advice on what areas I should focus on.
As for DC, as Leon mentioned above, it has many benefits compared to the regular persistent classes. If all goes according to plan, we will release the Domain Components technology in the near future, and resolve all the remaining issues with it.
If you feel that it is hard to learn, please let us know the most difficult parts you experienced. We will be glad to review them and possibly make the things easier for you and other users.
P.S.
I apologize for the delay in responding; I was on sick leave. You will receive more timely responses if you post your questions in the DevExpress Support Center.
#ProfK:
Am I correct that you are looking for something like visual designer for your business models?
If so, then I am afraid that XPO (XAF) does not currently provide such a functionality. However, you can use free third-party tools for modeling, such as Liekhus ADO.NET Entity Data Model XAF Extensions
I hope you find this information helpful.
I'm using XAF for almost two years now and I'm very happy with it. Developing an app is very quick, nice architecture, both Win and Web the same time and great UI. As with all frameworks, it has a learning curve, but if your already familiar with DevExpress controls that it's not very hard.
As Dennis mentioned, most behaviour can be overriden or extended. Regarding your modelling question, if think an important choice you have to make is whether or not you will use their Domain Components technology. Basically they have 2 ways: the old fashion way by inheriting from the XAF or XPO base classes or by using DC. DC allows a clean separation in modules and allows multiple inheritance. They can do that by generating classes runtime, but it still has some issues.
And the framework comes with a Business Class Library, a set of common classes which may be useful.
When I get stuck or cannot find the answer myself, I always use their fantastic Support Center. Most issues I ran into were already asked and answer on that site.
Briefly, each XAF application consists of Modules. There can be standard (system) and extra (user-defined) modules. Each Module can contain business objects, so-called Application Model customizations, Editors, Controllers, and Actions to provide additional business logic, customize UI and provide interaction between framework parts. You can model and customize your application on each level listed above, including but not limited by the underlying framework's metadata and data store ones. You can find more information about the framework's architecture here:
http://documentation.devexpress.com/#Xaf/CustomDocument2559
I should emphasize that it is possible to override behavior of almost every part of the framework. For instance, create your own editors for detail and list forms, override certain standard controllers, etc.
If you experience any further difficulties with our framework, feel free to contact us through our Support Center. We will be always glad to not only answer you questions, but advice a certain technical or design solution, provide some example code, etc.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I saw AsP.NET Design Patterns Here
how can i understand which Design Pattern is Appropriate for our Projects?
most of our projects are Office Automation Projects.
I Had Never Used Any ASP.NET Design pattern In my projects.
just i used microsoft nettiers
Thanks.
I dont think any one can tell you which design pattern would be the best for your project. Because each design pattern solves some particular problem. And, you just have to choose a design pattern depending on the problem you want to solve in your project. You can also use combinations of design patterns to solve some particular problems.
Design patterns are efficient solutions for commonly faced problems and are generally used so that you dont reinvent the wheel. As you say you dont know much about design patterns I would suggest you to pick up some book to learn about design patterns. Head first design patterns was the first book I read about design patterns.You can start with that book. It will help you understand a number of commonly used design patterns and which pattern to use and when.
The design patterns to be found on your linked page (i.e. Factory pattern, Observer pattern, Decorator pattern, etc.) have a very general purpose and are helpful to design specific tasks in any kind of application framework and programming language. Usually a large application won't follow only one of them but will contain a mix of several of these pattern. They are not specific to ASP.NET.
Perhaps you are looking more for a design pattern which helps to create a clear and maintainable structure of an application as a whole. For ASP.NET Webforms a widely used application pattern is the Model-View-Presenter or MVP pattern which helps you to seperate concerns (for instance separate business logic from UI/code-behind logic) and improves automated testability for Webforms applications.
You can read more about the MVP pattern in relation to ASP.NET Webforms here (a brief introduction which also explains the various flavors of the pattern (like Passive View and Supervising Controller)) and more in detail here. (Last but not least combining the terms "ASP.NET", "Webforms", "MVP" or similar in your favourite search engine will reveal a lot more resources.)
Edit: Just to add one link more I just discovered: http://webformsmvp.com seems to be a website which focusses exclusively on the MVP pattern in ASP.NET Webforms.
Maybe check out this website to get an idea of the patterns available and when to use them:
http://www.dofactory.com/Patterns/Patterns.aspx
But again as #Pavanred says, it really depends what you want to use them for.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
The community reviewed whether to reopen this question 2 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
More specifically, how do you model a functional program, or one developed using the Functional Style (without classes) using a diagram, and not textual representation.
Functional programmers generally don't have a lot of use for diagrams. Many functional programmers (but not all) find that writing down types is a good way to encapsulate the design relationships that OO programmers put into UML diagrams.
Because mutable state is rare in functional programs, there are no mutable "objects", so it is not usually useful or necessary to diagram relationships among them. And while one function might call another, this property is usually not important to the overall design of a system but only to the implementation of the function doing the calling.
If I were feeling a strong need to diagram a functional program I might use a concept map in which types or functions play the role of concepts.
UML isn't only class diagrams.
Most of the other diagram types (Use case diagrams, activity diagrams, sequence diagrams...) are perfectly applicable for a purely functional programming style. Even class diagrams could still be useful, if you simply don't use attributes and associations and interpret "class" as "collection of related functions".
Functional programmers have their own version of UML, it is called Category Theory.
(There is a certain truth to this, but it is meant to be read with a touch of humour).
UML is a compendium of different types of modeling. If you are talking about the Object Diagram (Class Diagram), well you are not going to find anything that fits your desired use. But if you are talking about an Interaction Diagram (Activity Diagram) or Requirements Diagram (Use Case Diagram), of course they will help you and are part of the UML base.
To model a functional program, using a diagram, and not textual representation, you can use notation like the one used to program in Viskell or Luna
I realize this is an old thread but I'm not understanding the issue here.
A class is merely an abstraction of a concept that ties the functionality of it's methods together in a more human friendly way. For instance, the class WaveGenerator might include the methods Sine, Sawtooth and SquareWave. All three methods are clearly related to the class Generator. However, all three are also stateless. If designed correctly, they don't need to store state information outside of the method. This makes them stateless objects which - if I understand correctly - makes them immutable functions which are a core concept in the functional paradigm.
From a conceptual perspective I don't see any difference between
let Envelope Sine = ...
and
let Envelope Generator.Sine = ...
other than the fact that the latter might provide greater insight into the purpose of the function.
UML is an object approach because at graphical level you can not define functional modeling. A trick is to directly add constraints and notes at model and not in the diagram levels. I mean that you can write a full functional documentation on each model element directly in the metamodel and only display an object view using the UML editor.
This is maybe stupid but I found this demo in French language exactly on the same subject and using EclipseUML Omondo :
OCL and UML 2.2 (demo in French language 3mn): http://www.download-omondo.com/regle_ocl.swf
This demo explains how to add constraints directly on methods at metamodel level. The interesting point of this demo is that using a single model for the entire project allows to be flexible enough to extend traditional UML and avoid SysML, BPMN, DSL additionals models because all information is built on the top of the UML 2.2 metamodel. I don't know if it will be a success but this initiative is very interesting because reduce modeling complexity and open new frontiers !!
I haven't actually tried modelling a large system in UML and then going for a functional implementation, but I don't see why it shouldn't work.
Assuming the implementation was going to be Haskell, I would start by defining the types and their relationships using a class diagram. Allocate functions to classes by their main argument, but bear in mind that this is just an artefact of UML. If it was easier to create a fictional singleton object just to hold all the functions, that would be fine too. If the application needs state then I would have no problem with modelling that in a state chart or sequence diagram. If I needed a custom monad for application-specific sequencing semantics then that might become a stereotype; the goal would be to describe what the application does in domain terms.
The main point is that UML could be used to model a program for functional implementation. You have to keep in mind a mapping to the implementation (and it wouldn't hurt to document it), and the fit is far from exact. But it could be done, and it might even add value.
I guess you could create a class called noclass and put in functions as methods. Also, you might want to split noclass into multiple categories of functions.