Search Results

Search found 3321 results on 133 pages for 'patterns'.

Page 3/133 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

• Progressbar patterns (Eclipse)

  - by JesperE

  I've struggled quite a bit with Eclipse and progress-monitors to try to have good progressbars which report useful progress information to the user. Inevitably the code gets cluttered with lots of things like if (monitor.isCancelled()) return; ... lengthyMethodCall(monitor.newChild(10)); and all over the place I need to pass a IProgressMonitor as an argument to my methods. This is bad, for several reasons: The code gets cluttered with lots of code which is not relevant to what the function actually does. I need to manually guesstimate which parts of the code takes time, and which parts do not. It interacts badly with automated tests; where much of the information which goes into a progressbar instead should be logged for later inspection. Is there a way out of this? Are there tools which can help me out with one or more of these problems? Should I be looking at Aspect-Oriented Programming tools, or are there other alternatives?

  Read the article

• Should universities put more emphasis on teaching their students about design patterns?

  - by gablin

  While I've heard about design patterns being mentioned in a few courses at uni, I know of only a single course which actually teaches design patterns. In almost all other areas (algorithms, parallelism, architecture, dynamic languages, paradigms, etc), there are several, often a basic course and an advanced course. Should universities put more emphasis about teaching their students about design patterns and provide more courses in design patters? Are lack of knowledge about design patterns common in just-graduated junior developers?

  Read the article

• GoF Design Patterns - which ones do you actually use?

  - by CraigS

  I'm trying to educate my colleagues in the area of design patterns. Some of the original Gang of Four patterns are a little esoteric, so I'm wondering if there is a sub-group of "essential" patterns that all programmers should know. As I look through the list, I think I've probably used - Abstract Factory Factory Method Singleton Bridge Facade Command Which ones do you actually use in practice, and what do you use them for? Link for those wanting a list of patterns

  Read the article

• Design Pattern Advice for Bluetooth App for Android

  - by Aimee Jones

  I’m looking for some advice on which patterns would apply to some of my work. I’m planning on doing a project as part of my college work and I need a bit of help. My main project is to make a basic Android bluetooth tracking system where the fixed locations of bluetooth dongles are mapped onto a map of a building. So my android app will regularly scan for nearby dongles and triangulate its location based on signal strength. The dongles location would be saved to a database along with their mac addresses to differentiate between them. The android phones location will then be sent to a server. This information will be used to show the phone’s location on a map of the building, or map of a route taken, on a website. My side project is to choose a suitable design pattern that could be implemented in this main project. I’m still a bit new to design patterns and am finding it hard to get my head around ones that may be suitable. I’ve heard maybe some that are aimed at web applications for the server side of things may be appropriate. My research so far is leading me to the following: Navigation Strategy Pattern Observer Pattern Command Pattern News Design Pattern Any advice would be a great help! Thanks

  Read the article

• Who benefits from the use of Design Patterns?

  Who benefits from the use of design patterns is like asking who benefits from clean air or a good education. All of the stakeholders of a project benefit from the use of design patterns. Project Sponsor Project sponsors benefit from the use of design patterns because they promote reduced development time which translates in to shorter project timelines and greater return on investment compared to other projects that do not make use of design patterns. Project Manager Project managers benefit from the use of design patterns because they reduce the amount of time needed to design a system, and typically the sub components of the system already have a proven track record. System Architect/Engineer System architects/engineers benefit from the use of design patterns because reduce the amount of time needed to design the core a system. The additional time is used to alter the design pattern through the use of innovative design and common design principles to adhere to the project’s requirements. Programmer Programmers benefit from the use of design patterns because they can reuse existing code already established by the design pattern and only have to integrate the changes outlined by the system architects/engineers. Tester Testers benefit from the use of design patterns because they can alter the existing test established for the design pattern to take in to account the changes made by the system architects/engineers. User Users benefit from the use of design patterns because the software is typically delivered sooner than projects that do not incorporate the use of design patterns, and they are assumed that the system will work as designed because it was based on a system that was already proven to work properly.

  Read the article

• Low coupling processing big quantities of data

  - by vitalik

  Usually I achieve low coupling by creating classes that exchange lists, sets, and maps between them. Now I am developing a batch application and I can't put all the data inside a data structure because there isn't enough memory. I have to read and process one chunk of data and then going to the next one. So having low coupling is much more difficult because I have to check somewhere if there is still data to read, etc. What I am using now is: Source - Process - Persist The classes that process have to ask to the Source classes if there are more rows to read. What are the best practices and or useful patterns in such situations? I hope I am explaining myself, if not tell me.

  Read the article

• How to evade writing a lot of repetitive code when mapping?

  - by JPCF

  I have a data access layer (DAL) using Entity Framework, and I want to use Automapper to communicate with upper layers. I will have to map data transfer objects (DTOs) to entities as the first operation on every method, process my inputs, then proceed to map from entities to DTOs. What would you do to skip writing this code? As an example, see this: //This is a common method in my DAL public CarDTO getCarByOwnerAndCreditStatus(OwnerDTO ownerDto, CreditDto creditDto) { //I want to automatize this code on all methods similar to this Mapper.CreateMap<OwnerDTO,Owner>(); Mapper.CreateMap<CreditDTO,Credit>(); Owner owner = Mapper.map(ownerDto); Owner credit = Mapper.map(creditDto) //... Some code processing the mapped DTOs //I want to automatize this code on all methods similar to this Mapper.CreateMap<Car,CarDTO>(); Car car = Mapper.map(ownedCar); return car; }

  Read the article

• How often are design patterns used in the workplace using PHP

  - by Metropolis

  Hey everyone, I read a book awhile back called PHP Design Patterns and Practice, and ever since then I have been using design patterns whenever I think they are needed. However it just occurred to me that maybe most companies do not use design patterns very often for PHP, or at all. What I was wondering is, do most companies use design patterns to help improve code flexibility? And if so, what are the best design patterns to learn for PHP? Thanks for any help on this, Metropolis

  Read the article

• Has the emerging generation of programmers got the wrong idea about design patterns? [closed]

  - by MattDavey

  Over the years I've noticed a shift in attitude towards design patterns, particularly amongst the emerging generation of developers. There seems to be a notion these days that design patterns are silver bullets that instantly cure any problem, a proliferating idea that advancing as a software engineer simply means learning and applying more and more patterns. When confronted with a problem, developers no longer strive to truly understand the issue and design a solution - instead they simply pick a design pattern which seems to be a close fit, and try to brute-force it. You can see evidence of this by the many, many questions on Stack Overflow that begin with the phrase "what pattern should I use to...". I fall into a slightly more mature category of developers (5-10 years experience) and I have a very different viewpoint on patterns - simply as a communication tool to enhance clarity. I find this perspective of design patterns being lego bricks (collected like pokemon cards) a little disconcerting. Will developers lose this attitude as they gain more experience in software engineering? Or could these notions perhaps steer the direction of our craft in years to come? Did the older generation of developers have any similar concerns about us? (perhaps about OO design or similar...). if so, how did we turn out?

  Read the article

• Magento Design Patterns

  - by JonB

  Magento, IMHO, represents a PHP system that is built on well thought-out coding principles - reuseable design patterns being one of them. In terms of an example of a PHP system, I think it can be considered pretty cutting edge and therefore worth considering from an architectural point of view. As I understand it, there are many design patterns that are available to the OOP developer. Seeing such patterns being put to use in an open-source system such as Magento allows a developer to view examples of such patterns in real use and in situ, rather than in examples that can sometimes be rather achedemic, and even a little misleading. As such, I am wondering what patterns, other than the ones I have listed below, Magento programmers have used when developing for Magento. As a note, I understand that some of these patterns are in place as a consequence of being built on the Zend Framework, MVC / Front Controller being a couple of them, The obvious ones are: Factory: $product = Mage::getModel('catalog/product'); Singleton: $category = Mage::getSingleton('catalog/session'); Registry: $currentCategory = Mage::registry('current_category');

  Read the article

• So Singletons are bad, then what?

  - by Bobby Tables

  There has been a lot of discussion lately about the problems with using (and overusing) Singletons. I've been one of those people earlier in my career too. I can see what the problem is now, and yet, there are still many cases where I can't see a nice alternative - and not many of the anti-Singleton discussions really provide one. Here is a real example from a major recent project I was involved in: The application was a thick client with many separate screens and components which uses huge amounts of data from a server state which isn't updated too often. This data was basically cached in a Singleton "manager" object - the dreaded "global state". The idea was to have this one place in the app which keeps the data stored and synced, and then any new screens that are opened can just query most of what they need from there, without making repetitive requests for various supporting data from the server. Constantly requesting to the server would take too much bandwidth - and I'm talking thousands of dollars extra Internet bills per week, so that was unacceptable. Is there any other approach that could be appropriate here than basically having this kind of global data manager cache object? This object doesn't officially have to be a "Singleton" of course, but it does conceptually make sense to be one. What is a nice clean alternative here?

  Read the article

• Best Design Pattern for Coupling User Interface Components and Data Structures

  - by szahn

  I have a windows desktop application with a tree view. Due to lack of a sound data-binding solution for a tree view, I've implemented my own layer of abstraction on it to bind nodes to my own data structure. The requirements are as follows: Populate a tree view with nodes that resemble fields in a data structure. When a node is clicked, display the appropriate control to modify the value of that property in the instance of the data structure. The tree view is populated with instances of custom TreeNode classes that inherit from TreeNode. The responsibility of each custom TreeNode class is to (1) format the node text to represent the name and value of the associated field in my data structure, (2) return the control used to modify the property value, (3) get the value of the field in the control (3) set the field's value from the control. My custom TreeNode implementation has a property called "Control" which retrieves the proper custom control in the form of the base control. The control instance is stored in the custom node and instantiated upon first retrieval. So each, custom node has an associated custom control which extends a base abstract control class. Example TreeNode implementation: //The Tree Node Base Class public abstract class TreeViewNodeBase : TreeNode { public abstract CustomControlBase Control { get; } public TreeViewNodeBase(ExtractionField field) { UpdateControl(field); } public virtual void UpdateControl(ExtractionField field) { Control.UpdateControl(field); UpdateCaption(FormatValueForCaption()); } public virtual void SaveChanges(ExtractionField field) { Control.SaveChanges(field); UpdateCaption(FormatValueForCaption()); } public virtual string FormatValueForCaption() { return Control.FormatValueForCaption(); } public virtual void UpdateCaption(string newValue) { this.Text = Caption; this.LongText = newValue; } } //The tree node implementation class public class ExtractionTypeNode : TreeViewNodeBase { private CustomDropDownControl control; public override CustomControlBase Control { get { if (control == null) { control = new CustomDropDownControl(); control.label1.Text = Caption; control.comboBox1.Items.Clear(); control.comboBox1.Items.AddRange( Enum.GetNames( typeof(ExtractionField.ExtractionType))); } return control; } } public ExtractionTypeNode(ExtractionField field) : base(field) { } } //The custom control base class public abstract class CustomControlBase : UserControl { public abstract void UpdateControl(ExtractionField field); public abstract void SaveChanges(ExtractionField field); public abstract string FormatValueForCaption(); } //The custom control generic implementation (view) public partial class CustomDropDownControl : CustomControlBase { public CustomDropDownControl() { InitializeComponent(); } public override void UpdateControl(ExtractionField field) { //Nothing to do here } public override void SaveChanges(ExtractionField field) { //Nothing to do here } public override string FormatValueForCaption() { //Nothing to do here return string.Empty; } } //The custom control specific implementation public class FieldExtractionTypeControl : CustomDropDownControl { public override void UpdateControl(ExtractionField field) { comboBox1.SelectedIndex = comboBox1.FindStringExact(field.Extraction.ToString()); } public override void SaveChanges(ExtractionField field) { field.Extraction = (ExtractionField.ExtractionType) Enum.Parse(typeof(ExtractionField.ExtractionType), comboBox1.SelectedItem.ToString()); } public override string FormatValueForCaption() { return string.Empty; } The problem is that I have "generic" controls which inherit from CustomControlBase. These are just "views" with no logic. Then I have specific controls that inherit from the generic controls. I don't have any functions or business logic in the generic controls because the specific controls should govern how data is associated with the data structure. What is the best design pattern for this?

  Read the article

• LSP vs OCP / Liskov Substitution VS Open Close

  - by Kolyunya

  I am trying to understand the SOLID principles of OOP and I've come to the conclusion that LSP and OCP have some similarities (if not to say more). the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification". LSP in simple words states that any instance of Foo can be replaced with any instance of Bar which is derived from Foo and the program will work the same very way. I'm not a pro OOP programmer, but it seems to me that LSP is only possible if Bar, derived from Foo does not change anything in it but only extends it. That means that in particular program LSP is true only when OCP is true and OCP is true only if LSP is true. That means that they are equal. Correct me if I'm wrong. I really want to understand these ideas. Great thanks for an answer.

  Read the article

• Avoiding the Anaemic Domain - How to decide what single responsibility a class has

  - by thecapsaicinkid

  Even after reading a bunch I'm still falling into the same trap. I have a class, usually an enity. I need to implement more than one, similar operations on this type. It feels wrong to (seemingly arbitrarily) choose one of these operations to belong inside the entity and push the others out to a separate class; I end up pushing all operations to service classes and am left with an anaemic domain. As a crude example, imagine the typical Employee class with numeric properties to hold how many paid days the employee is entitled to for both sickness and holiday and a collection of days taken for each. public class Employee { public int PaidHolidayAllowance { get; set; } public int PaidSicknessAllowance { get; set; } public IEnumerable<Holiday> Holidays { get; set; } public IEnumerable<SickDays> SickDays { get; set; } } I want two operations, one to calculate remaining holiday, another for remaining paid sick days. It seems strange to include say, CalculateRemaingHoliday() in the Employee class and bump CalculateRemainingPaidSick() to some PaidSicknessCalculator class. I would end up with a PaidSicknessCalculator and a RemainingHolidayCalculator and the anaemic Employee entity as seen above. The other alternative would be to put both operations in the Employee class and kick Single Responsibility to the curb. That doesn't make for particularly maintainable code. I suppose the Employee class should have some initialisation/validation logic (not accepting negative alowances etc.) So maybe I just stick to basic initialisation and validation in the entities themselves and be happy with my separate calculator classes. Or maybe I should be asking myself if Anaemic Domain is actually causing me some tangible problems with my code.

  Read the article

• Relationship between Repository and Unit of Work

  - by NullOrEmpty

  I am going to implement a repository, and I would like to use the UOW pattern since the consumer of the repository could do several operations, and I want to commit them at once. After read several articles about the matter, I still don't get how to relate this two elements, depending on the article it is being done in a way u other. Sometimes the UOW is something internal to the repository: public class Repository { UnitOfWork _uow; public Repository() { _uow = IoC.Get<UnitOfWork>(); } public void Save(Entity e) { _uow.Track(e); } public void SubmittChanges() { SaveInStorage(_uow.GetChanges()); } } And sometimes it is external: public class Repository { public void Save(Entity e, UnitOfWork uow) { uow.Track(e); } public void SubmittChanges(UnitOfWork uow) { SaveInStorage(uow.GetChanges()); } } Other times, is the UOW whom references the Repository public class UnitOfWork { Repository _repository; public UnitOfWork(Repository repository) { _repository = repository; } public void Save(Entity e) { this.Track(e); } public void SubmittChanges() { _repository.Save(this.GetChanges()); } } How are these two elements related? UOW tracks the elements that needs be changed, and repository contains the logic to persist those changes, but... who call who? Does the last make more sense? Also, who manages the connection? If several operations have to be done in the repository, I think using the same connection and even transaction is more sound, so maybe put the connection object inside the UOW and this one inside the repository makes sense as well. Cheers

  Read the article

• Is ORM an Anti-Pattern?

  - by derphil

  I had a very stimulating and interessting discussion with a colleague about ORM and it's Pros and Cons. In my opinion, an ORM is useful only in the rarest cases. At least in my experience. But I don't want to list my own arguments at this time. So I ask you, what do you think about ORM? What are the Pros and the Cons? P.S. I've posted this "question" yesterday on Stackoverflow, but some of the user think, that this should better posted here.

  Read the article

• Alternative to "inheritance v composition??"

  - by Frank

  I have colleagues at work who claim that "Inheritance is an anti-pattern" and want to use composition systematically instead, except in (rare, according to them) cases where inheritance is really the best way to go. I want to suggest an alternative where we continue using inheritance, but it is strictly forbidden (enforced by code reviews) to use anything but public members of base classes in derived classes. For a case where we don't need to swap components of a class at runtime (static inheritance), would that be equivalent enough to composition? Or am I forgetting some other important aspect of composition?

  Read the article

• Alternative to "inheritance versus composition?" [closed]

  - by Frank

  Possible Duplicate: Where does this concept of “favor composition over inheritance” come from? I have colleagues at work who claim that "Inheritance is an anti-pattern" and want to use composition systematically instead, except in (rare, according to them) cases where inheritance is really the best way to go. I want to suggest an alternative where we continue using inheritance, but it is strictly forbidden (enforced by code reviews) to use anything but public members of base classes in derived classes. For a case where we don't need to swap components of a class at runtime (static inheritance), would that be equivalent enough to composition? Or am I forgetting some other important aspect of composition?

  Read the article

• Is there an antipattern to describe this method of coding?

  - by P.Brian.Mackey

  I have a codebase where the programmer tended to wrap things up in areas that don't make sense. For example, given an Error log we have you can log via ErrorLog.Log(ex, "friendly message"); He added various other means to accomplish the exact same task. E.G. SomeClass.Log(ex, "friendly message"); Which simply turns around and calls the first method. This adds levels of complexity with no added benefit. Is there an anti-pattern to describe this?

  Read the article

• Acceptable placement of the composition root using dependency injection and inversion of control containers

  - by Lumirris

  I've read in several sources including Mark Seemann's 'Ploeh' blog about how the appropriate placement of the composition root of an IoC container is as close as possible to the entry point of an application. In the .NET world, these applications seem to be commonly thought of as Web projects, WPF projects, console applications, things with a typical UI (read: not library projects). Is it really going against this sage advice to place the composition root at the entry point of a library project, when it represents the logical entry point of a group of library projects, and the client of a project group such as this is someone else's work, whose author can't or won't add the composition root to their project (a UI project or yet another library project, even)? I'm familiar with Ninject as an IoC container implementation, but I imagine many others work the same way in that they can scan for a module containing all the necessary binding configurations. This means I could put a binding module in its own library project to compile with my main library project's output, and if the client wanted to change the configuration (an unlikely scenario in my case), they could drop in a replacement dll to replace the library with the binding module. This seems to avoid the most common clients having to deal with dependency injection and composition roots at all, and would make for the cleanest API for the library project group. Yet this seems to fly in the face of conventional wisdom on the issue. Is it just that most of the advice out there makes the assumption that the developer has some coordination with the development of the UI project(s) as well, rather than my case, in which I'm just developing libraries for others to use?

  Read the article

• Help identify the pattern for reacting on updates

  - by Mike

  There's an entity that gets updated from external sources. Update events are at random intervals. And the entity has to be processed once updated. Multiple updates may be multiplexed. In other words there's a need for the most current state of entity to be processed. There's a point of no-return during processing where the current state (and the state is consistent i.e. no partial update is made) of entity is saved somewhere else and processing goes on independently of any arriving updates. Every consequent set of updates has to trigger processing i.e. system should not forget about updates. And for each entity there should be no more than one running processing (before the point of no-return) i.e. the entity state should not be processed more than once. So what I'm looking for is a pattern to cancel current processing before the point of no return or abandon processing results if an update arrives. The main challenge is to minimize race conditions and maintain integrity. The entity sits mainly in database with some files on disk. And the system is in .NET with web-services and message queues. What comes to my mind is a database queue-like table. An arriving update inserts row in that table and the processing is launched. The processing gathers necessary data before the point of no-return and once it reaches this barrier it looks into the queue table and checks whether there're more recent updates for the entity. If there are new updates the processing simply shuts down and its data is discarded. Otherwise the processing data is persisted and it goes beyond the point of no-return. Though it looks like a solution to me it is not quite elegant and I believe this scenario may be supported by some sort of middleware. If I would use message queues for this then there's a need to access the queue API in the point of no-return to check for the existence of new messages. And this approach also lacks elegance. Is there a name for this pattern and an existing solution?

  Read the article

• Javascript: Avoid this and new - further reading? [closed]

  - by Thomas Deutsch

  I do not want this to end in a sort of religious discussion, i want to collect some sources for further reading on this topic. As shown here: Node.js Style and Structure Point 1: Avoid this and new you can find a good example when it could be better to use closures instead of a prototype, and to make every argument explicit. Ok, i agree - could be nice, but i need to know more. Can anyone recommend a good link? Would this make my code 100% object-pattern-free ? (no factory-, repository-, module- pattern?)

  Read the article

• Modular Database Structures

  - by John D

  I have been examining the code base we use in work and I am worried about the size the packages have grown to. The actual code is modular, procedures have been broken down into small functional (and testable) parts. The issue I see is that we have 100 procedures in a single package - almost an entire domain model. I had thought of breaking these packages down - to create sub domains that are centered around the procedure relationships to other objects. Group a bunch of procedures that have 80% of their relationships to three tables etc. The end result would be a lot more packages, but the packages would be smaller and I feel the entire code base would be more readable - when procedures cross between two domain models it is less of a struggle to figure which package it belongs to. The problem I now have is what the actual benefit of all this would really be. I looked at the general advantages of modularity: 1. Re-usability 2. Asynchronous Development 3. Maintainability Yet when I consider our latest development, the procedures within the packages are already reusable. At this advanced stage we rarely require asynchronous development - and when it is required we simply ladder the stories across iterations. So I guess my question is if people know of reasons why you would break down classes rather than just the methods inside of classes? Right now I do believe there is an issue with these mega packages forming but the only benefit I can really pin down to break them down is readability - something that experience gained from working with them would solve.

  Read the article

• Optimal communication pattern to update subscribers

  - by hpc

  What is the optimal way to update the subscriber's local model on changes C on a central model M? ( M + C - M_c) The update can be done by the following methods: Publish the updated model M_c to all subscribers. Drawback: if the model is big in contrast to the change it results in much more data to be communicated. Publish change C to all subscribes. The subscribers will then update their local model in the same way as the server does. Drawback: The client needs to know the business logic to update the model in the same way as the server. It must be assured that the subscribed model stays equal to the central model. Calculate the delta (or patch) of the change (M_c - M = D_c) and transfer the delta. Drawback: This requires that calculating and applying the delta (M + D_c = M_c) is an cheap/easy operation. If a client newly subscribes it must be initialized. This involves sending the current model M. So method 1 is always required. Think of playing chess as a concrete example: Subscribers send moves and want to see the latest chess board state. The server checks validity of the move and applies it to the chess board. The server can then send the updated chessboard (method 1) or just send the move (method 2) or send the delta (method 3): remove piece on field D4, put tower on field D8.

  Read the article

• Is implementing an interface defined in a subpackage an anti-pattern?

  - by Michael Kjörling

  Let's say I have the following: package me.my.pkg; public interface Something { /* ... couple of methods go here ... */ } and: package me.my; import me.my.pkg.Something; public class SomeClass implements Something { /* ... implementation of Something goes here ... */ /* ... some more method implementations go here too ... */ } That is, the class implementing an interface lives closer to the package hierarchy root than does the interface it implements but they both belong in the same package hierarchy. The reason for this in the particular case I have in mind is that there is a previously-existing package that groups functionality which the Something interface logically belongs to, and the logical (as in both "the one you'd expect" and "the one where it needs to go given the current architecture") implementation class exists previously and lives one level "up" from the logical placement of the interface. The implementing class does not logically belong anywhere under me.my.pkg. In my particular case, the class in question implements several interfaces, but that feels like it doesn't make any (or at least no significant) difference here. I can't decide if this is an acceptable pattern or not. Is it or is it not, and why?

  Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >