Search Results

Search found 8692 results on 348 pages for 'patterns practices'.

Page 69/348 | < Previous Page | 65 66 67 68 69 70 71 72 73 74 75 76  | Next Page >

• Why avoid Java Inheritance "Extends"

  - by newbie

  Good day! Jame Gosling said “You should avoid implementation inheritance whenever possible.” and instead, use interface inheritance. But why? How can we avoid inheriting the structure of an object using the keyword "extends", and at the same time make our code Object Oriented? Could someone please give an Object Oriented example illustrating this concept in a scenario like "ordering a book in a bookstore?" Thank you in advance.

  Read the article

• Must all AI states be able to react to any event?

  - by Prog

  FSMs implemented with the State design pattern are a common way to design AI agents. I am familiar with the State design pattern and know how to implement it. How is this used in games to design AI agents? Consider a simplified class Monster, representing an AI agent: class Monster { State state; // other fields omitted public void update(){ // called every game-loop cycle state.execute(this); } public void setState(State state){ this.state = state; } // irrelevant stuff omitted } There are several State subclasses implementing execute() differently. So far, classic State pattern. AI agents are subject to environmental effects and other objects communicating with them. For example, an AI agent might tell another AI agent to attack (i.e. agent.attack()). Or a fireball might tell an AI agent to fall down. This means that the agent must have methods such as attack() and fallDown(), or commonly some message receiving mechanism to understand such messages. With an FSM, the current State of the agent should be the one taking care of such method calls - i.e. the agent delegates to the current state upon every event. Is this correct? If correct, how is this done? Are all states obligated by their superclass to implement methods such as attack(), fallDown() etc., so the agent can always delegate to them on almost every event? Or is it done in some other way?

  Read the article

• How can you tell whether to use Composite Pattern or a Tree Structure, or a third implementation?

  - by Aske B.

  I have two client types, an "Observer"-type and a "Subject"-type. They're both associated with a hierarchy of groups. The Observer will receive (calendar) data from the groups it is associated with throughout the different hierarchies. This data is calculated by combining data from 'parent' groups of the group trying to collect data (each group can have only one parent). The Subject will be able to create the data (that the Observers will receive) in the groups they're associated with. When data is created in a group, all 'children' of the group will have the data as well, and they will be able to make their own version of a specific area of the data, but still linked to the original data created (in my specific implementation, the original data will contain time-period(s) and headline, while the subgroups specify the rest of the data for the receivers directly linked to their respective groups). However, when the Subject creates data, it has to check if all affected Observers have any data that conflicts with this, which means a huge recursive function, as far as I can understand. So I think this can be summed up to the fact that I need to be able to have a hierarchy that you can go up and down in, and some places be able to treat them as a whole (recursion, basically). Also, I'm not just aiming at a solution that works. I'm hoping to find a solution that is relatively easy to understand (architecture-wise at least) and also flexible enough to be able to easily receive additional functionality in the future. Is there a design pattern, or a good practice to go by, to solve this problem or similar hierarchy problems? EDIT: Here's the design I have: The "Phoenix"-class is named that way because I didn't think of an appropriate name yet. But besides this I need to be able to hide specific activities for specific observers, even though they are attached to them through the groups. A little Off-topic: Personally, I feel that I should be able to chop this problem down to smaller problems, but it escapes me how. I think it's because it involves multiple recursive functionalities that aren't associated with each other and different client types that needs to get information in different ways. I can't really wrap my head around it. If anyone can guide me in a direction of how to become better at encapsulating hierarchy problems, I'd be very glad to receive that as well.

  Read the article

• Use decorator and factory together to extend objects?

  - by TheClue

  I'm new to OOP and design pattern. I've a simple app that handles the generation of Tables, Columns (that belong to Table), Rows (that belong to Column) and Values (that belong to Rows). Each of these object can have a collection of Property, which is in turn defined as an enum. They are all interfaces: I used factories to get concrete instances of these products, depending on circumnstances. Now I'm facing the problem of extending these classes. Let's say I need another product called "SpecialTable" which in turn has some special properties or new methods like 'getSomethingSpecial' or an extended set of Property. The only way is to extend/specialize all my elements (ie. build a SpecialTableFactory, a SpecialTable interface and a SpecialTableImpl concrete)? What to do if, let's say, I plan to use standard methods like addRow(Column column, String name) that doesn't need to be specialized? I don't like the idea to inherit factories and interfaces, but since SpecialTable has more methods than Table i guess it cannot share the same factory. Am I wrong? Another question: if I need to define product properties at run time (a Table that is upgraded to SpecialTable at runtime), i guess i should use a decorator. Is it possible (and how) to combine both factory and decorator design? Is it better to use a State or Strategy pattern, instead?

  Read the article

• Should HTTP Verbs Be Used Semantically?

  - by Xophmeister

  If I'm making a web application which integrates with a server-side backend, would it be considered best practice to use HTTP methods semantically? That is, for example, if I'm fetching data (e.g., to populate a menu, etc.), I would use GET, but to update data (e.g., save a record), I would use POST. (I realise there are other methods that may be even more appropriate, but we need to consider browser support.) I can see the benefits of this in the sense that it's effectively a RESTful API, but at a slightly increased development cost. In my previous projects, I've POST'd everything: Is it worth switching to a RESTful mindset simply for the sake of best practice?

  Read the article

• Where ORMs blur the lines between code and data, how do you decide what logic should be a stored procedure, and what should be coded?

  - by PhonicUK

  Take the following pseudocode: CreateInvoiceAndCalculate(ItemsAndQuantities, DispatchAddress, User); And say CreateInvoice does the following: Create a new entry in an Invoices table belonging to the specified User to be sent to the given DispatchAddress. Create a new entry in an InvoiceItems table for each of the items in ItemsAndQuantities, storing the Item, the Quantity, and the cost of the item as of now (by looking it up from an Items table) Calculate the total amount of the invoice (ex shipping and taxes) and store it in the new Invoice row. At a glace you wouldn't be able to tell if this was a method in my applications code, or a stored procedure in the database that is being exposed as a function by the ORM. And to some extent it doesn't really matter. Now technically none of this is business logic. You're not making any decisions - just performing a calculation and creating records. However some may argue that because you are performing a calculation that affects the business (the total amount to be invoiced) that this isn't something that should be done in a stored procedure and instead should be in code. So for this specific example - why would it be more appropriate to do one or the other? And where do you draw the line? Or does it even particular matter as long as it's sufficiently well documented?

  Read the article

• What are the advantages and Disadvantages of Using an Aspect Orientated Programming Paradigm

  - by JHarley1

  Ok so here is the question: What are the advantages and Disadvantages of Using an Aspect Orientated Programming Paradigm. My advantages and disadvantages thus far: Advantages: Complements object orientation. Modularizes cross-cutting concerns improving code maintainability and understandability. Disadvantage: Not the easiest of concepts to grasp - not as well documented as O-O O-O goes far enough in the separation of concerns... List item Would anyone like to challenge any of these/ add their own? Many Thanks, J

  Read the article

• Where we should put validation for domain model

  - by adisembiring

  I still looking best practice for domain model validation. Is that good to put the validation in constructor of domain model ? my domain model validation example as follows: public class Order { private readonly List<OrderLine> _lineItems; public virtual Customer Customer { get; private set; } public virtual DateTime OrderDate { get; private set; } public virtual decimal OrderTotal { get; private set; } public Order (Customer customer) { if (customer == null) throw new ArgumentException("Customer name must be defined"); Customer = customer; OrderDate = DateTime.Now; _lineItems = new List<LineItem>(); } public void AddOderLine //.... public IEnumerable<OrderLine> AddOderLine { get {return _lineItems;} } } public class OrderLine { public virtual Order Order { get; set; } public virtual Product Product { get; set; } public virtual int Quantity { get; set; } public virtual decimal UnitPrice { get; set; } public OrderLine(Order order, int quantity, Product product) { if (order == null) throw new ArgumentException("Order name must be defined"); if (quantity <= 0) throw new ArgumentException("Quantity must be greater than zero"); if (product == null) throw new ArgumentException("Product name must be defined"); Order = order; Quantity = quantity; Product = product; } } Thanks for all of your suggestion.

  Read the article

• Flags with deferred use

  - by Trenton Maki

  Let's say I have a system. In this system I have a number of operations I can do but all of these operations have to happen as a batch at a certain time, while calls to activate and deactivate these operations can come in at any time. To implement this, I could use flags like doOperation1 and doOperation2 but this seems like it would become difficult to maintain. Is there a design pattern, or something similar, that addresses this situation?

  Read the article

• How to choose between using a Domain Event, or letting the application layer orchestrate everything

  - by Mr Happy

  I'm setting my first steps into domain driven design, bought the blue book and all, and I find myself seeing three ways to implement a certain solution. For the record: I'm not using CQRS or Event Sourcing. Let's say a user request comes into the application service layer. The business logic for that request is (for whatever reason) separated into a method on an entity, and a method on a domain service. How should I go about calling those methods? The options I have gathered so far are: Let the application service call both methods Use method injection/double dispatch to inject the domain service into the entity, letting the entity do it's thing and then let it call the method of the domain service (or the other way around, letting the domain service call the method on the entity) Raise a domain event in the entity method, a handler of which calls the domain service. (The kind of domain events I'm talking about are: http://www.udidahan.com/2009/06/14/domain-events-salvation/) I think these are all viable, but I'm unable to choose between them. I've been thinking about this a long time and I've come to a point where I no longer see the semantic differences between the three. Do you know of some guidelines when to use what?

  Read the article

• How to control messages to the same port from different emitters?

  - by Alex In Paris

  Scene: A company has many factories X, each emits a message to the same receive port in a Biztalk server Y; if all messages are processed without much delay, each will trigger an outgoing message to another system Z. Problem: Sometimes a factory loses its connection for a half-day or more and, when the connection is reestablished, thousands of messages get emitted. Now, the messages still get processed well by Y (Biztalk can easily handle the load) but system Z can't handle the flood and may lock up and severely delay the processing of all other messages from the other X. What is the solution? Creating multiple receive locations that permits us to pause one X or another would lose us information if the factory isn't smart enough to know whether the message was received or not. What is the basic pattern to apply in Biztalk for this problem? Would some throttling parameters help to limit the flow from any one X? Or are their techniques on the end part of Y which I should use instead ? I would prefer this last one since I can be confident that the message box will remember any failures, which could then be resumed.

  Read the article

• I know of three ways in which SRP helps reduce coupling. Are there even more? [closed]

  - by user1483278

  I'd like to figure all the possible ways SRP helps us reduce coupling. Thus far I can think of three: 1) If class A has more than one responsibility, these responsibilities become coupled and as such changes to one of these responsibilities may require changes to other of A's responsibilities. 2) Related functionality usually needs to be changed for the same reason and by grouping it togerther in a single class, the changes can be made in as few places as possible ( at best changes only need be made to the class which groups together these functionalities) 3) Assuming class A performs two tasks ( thus may change for two reasons ), then number of classes utilising A will be greater than if A performed just a single task ( reason being that some classes will need A to perform first task, other will need A for second task, and still others will utilise it for both tasks ).This also means that when A breaks, the number of classes ( utilising A ) being impaired will be greater than if A performed just a single task. Can SRP also help reduce coupling in any other way, not described above? Thank you

  Read the article

• Torvalds' quote about good programmer

  - by beyeran

  Accidentally I've stumbled upon the following quote by Linus Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." I've thought about it for the last few days and I'm still confused (which is probably not a good sign), hence I wanted to discuss the following: What interpretation of this possible/makes sense? What can be applied/learned from it?

  Read the article

• Interfaces on an abstract class

  - by insta

  My coworker and I have different opinions on the relationship between base classes and interfaces. I'm of the belief that a class should not implement an interface unless that class can be used when an implementation of the interface is required. In other words, I like to see code like this: interface IFooWorker { void Work(); } abstract class BaseWorker { ... base class behaviors ... public abstract void Work() { } protected string CleanData(string data) { ... } } class DbWorker : BaseWorker, IFooWorker { public void Work() { Repository.AddCleanData(base.CleanData(UI.GetDirtyData())); } } The DbWorker is what gets the IFooWorker interface, because it is an instantiatable implementation of the interface. It completely fulfills the contract. My coworker prefers the nearly identical: interface IFooWorker { void Work(); } abstract class BaseWorker : IFooWorker { ... base class behaviors ... public abstract void Work() { } protected string CleanData(string data) { ... } } class DbWorker : BaseWorker { public void Work() { Repository.AddCleanData(base.CleanData(UI.GetDirtyData())); } } Where the base class gets the interface, and by virtue of this all inheritors of the base class are of that interface as well. This bugs me but I can't come up with concrete reasons why, outside of "the base class cannot stand on its own as an implementation of the interface". What are the pros & cons of his method vs. mine, and why should one be used over another?

  Read the article

• What Design Pattern is seperating transform converters

  - by RevMoon

  For converting a Java object model into XML I am using the following design: For different types of objects (e.g. primitive types, collections, null, etc.) I define each its own converter, which acts appropriate with respect to the given type. This way it can easily extended without adding code to a huge if-else-then construct. The converters are chosen by a method which tests whether the object is convertable at all and by using a priority ordering. The priority ordering is important so let's say a List is not converted by the POJO converter, even though it is convertable as such it would be more appropriate to use the collection converter. What design pattern is that? I can only think of a similarity to the command pattern.

  Read the article

• How to layer if statements when order of logic is irrelevant?

  - by jimmyjimmy

  Basically I have a series of logic in my website that can lead to 5 total outcomes. Basically two different if tests and then a catch all else statement. For example: if cond1: if mod1: #do things elif mod2: #do things elif cond2: if mod1: #do things elif mod2 #do things else: #do things I was thinking about rewriting it like this: if cond1 and mod1: #do things elif cond1 and mod2: #do things elif cond2 and mod1: #do things elif cond2 and mod2: #do things else: #do things Is there any real difference in these two coding options/a better choice for this kind of logic testing?

  Read the article

• Data Access Objects old fashioned? [on hold]

  - by Bono

  A couple of weeks ago I delivered some work for a university project. After a code review with some teachers I got some snarky remarks about the fact that I was (still) using Data Access Objects. The teacher in question who said this mentions the use of DAO's in his classes and always says something along the lines of "Back then we always used DAO's". He's a big fan of Object Relational Mapping, which I also think is a great tool. When I was talking about this with some of my fellow students, they also mentioned that they prefer the use of ORM, which I can understand. It did make me wonder though, is using DAO's really so old fashioned? I know that at my work DAO's are still being used, but this is due to the fact that some of the code is rather old and therefor can't be coupled with ORM. We also do use ORM at my work. Trying to find some more information on Google or Stack Exchange sites didn't really enlighten me. Should I step away from the use of DAO's and only start implementing ORM? I just feel that ORM's can be a bit overkill for some simple projects. I'd love to hear your opinions (or facts) about this.

  Read the article

• Storing a looong lookup table

  - by inquisitive

  Background The product i am working on has a very long lookup-table. the table contains static data and cannot be auto generated. there are about 500 rows and 10 columns. columns have mostly integers and strings. to complicate the matters, there are actually two such tables. every row in table-1 maps to zero-or-more rows in table-2. we use an SQLite database with two tables. the product installer places the SQLite file in the installation directory. the application is written in dot-net and we use ADO to load the data once on startup. now, the lookup table grows. in each release a month, we add about 10 new entries existing entries are adjusted. every release we fine tune existing entries. The problem a team of (10) developers work on the lookup table. Code goes in the SVN, but the little devil the SQLite does not. this prevents multiple developers to work on it. we do take regular backups of the file, but proper versioning is not possible. we never know who did the breaking change. the worse thing is we dont know if there is any change at all. diff'ing databases is tedious if not impossible. the tables are expected to grow quite large in years to come and we would need developers to work in parallel on it. the data is business critical. we need to be able to audit changes made to it. Question What would be a solution for the problems outlines above? one idea was to transform the whole thing to XML and treat it like just another source file. that way SVN can do the versioning and we can work in parallel. but the data shows relational behavior. with XML we loose the unique and foreign-key constraints. also we cant query it with sql like ease. any help here will be appreciated.

  Read the article

• Should this code/logic be included in Business Objects class or a separate class?

  - by aspdotnetuser

  I have created a small application which has a three tier architecture and I have business object classes to represent entities such as User, Orders, UserType etc. In these classes I have methods that are executed when the Constuctor method of, for example, User is called. These methods perform calculations and generate details that setup data for attributes that are part of each User object. Here is the structure for the project in Visual Studio: Here is some code from the business object class User.cs: Public Class User { public string Name { get; set; } public int RandomNumber { get; set; } etc public User { Name = GetName(); RandomNumber = GetRandomNumber(); } public string GetName() { .... return name; } public int GetRandomNumber() { ... return randomNumber; } } Should this logic be included in the Business Object classes or should it be included in a Utilities class of some kind? Or in the business rules?

  Read the article

• Visitor-pattern vs inheritance for rendering

  - by akaltar

  I have a game engine that currently uses inheritance to provide a generic interface to do rendering: class renderable { public: void render(); }; Each class calls the gl_* functions itself, this makes the code hard to optimize and hard to implement something like setting the quality of rendering: class sphere : public renderable { public: void render() { glDrawElements(...); } }; I was thinking about implementing a system where I would create a Renderer class that would render my objects: class sphere { void render( renderer* r ) { r->renderme( *this ); } }; class renderer { renderme( sphere& sphere ) { // magically get render resources here // magically render a sphere here } }; My main problem is where should I store the VBOs and where should I Create them when using this method? Should I even use this approach or stick to the current one, perhaps something else? PS: I already asked this question on SO but got no proper answers.

  Read the article

• Client-server application design issue

  - by user2547823

  I have a collection of clients on server's side. And there are some objects that need to work with that collection - adding and removing clients, sending message to them, updating connection settings and so on. They should perform these actions simultaneously, so mutex or another synchronization primitive is required. I want to share one instance of collection between these objects, but all of them require access to private fields of collection. I hope that code sample makes it more clear[C++]: class Collection { std::vector< Client* > clients; Mutex mLock; ... } class ClientNotifier { void sendMessage() { mLock.lock(); // loop over clients and send message to each of them } } class ConnectionSettingsUpdater { void changeSettings( const std::string& name ) { mLock.lock(); // if client with this name is inside collection, change its settings } } As you can see, all these classes require direct access to Collection's private fields. Can you give me an advice about how to implement such behaviour correctly, i.e. keeping Collection's interface simple without it knowing about its users?

  Read the article

• Design pattern: static function call with input/output containers?

  - by Pavlo Dyban

  I work for a company in software research department. We use algorithms from our real software and wrap them so that we can use them for prototyping. Every time an algorithm interface changes, we need to adapt our wrappers respectively. Recently all algorithms have been refactored in such a manner that instead of accepting many different inputs and returning outputs via referenced parameters, they now accept one input data container and one output data container (the latter is passed by reference). Algorithm interface is limited to a static function call like that: class MyAlgorithm{ static bool calculate(MyAlgorithmInput input, MyAlgorithmOutput &output); } This is actually a very powerful design, though I have never seen it in a C++ programming environment before. Changes in the number of parameters and their data types are now encapsulated and they don't change the algorithm callback. In the latest algorithm which I have developed I used the same scheme. Now I want to know if this is a popular design pattern and what it is called.

  Read the article

• Correct way to inject dependencies in Business logic service?

  - by Sri Harsha Velicheti

  Currently the structure of my application is as below Web App -- WCF Service (just a facade) -- Business Logic Services -- Repository - Entity Framework Datacontext Now each of my Business logic service is dependent on more than 5 repositories ( I have interfaces defined for all the repos) and I am doing a Constructor injection right now(poor mans DI instead of using a proper IOC as it was determined that it would be a overkill for our project). Repositories have references to EF datacontexts. Now some of the methods in the Business logic service require only one of the 5 repositories, so If I need to call that method I would end up instantiating a Service which will instatiate all 5 repositories which is a waste. An example: public class SomeService : ISomeService { public(IFirstRepository repo1, ISecondRepository repo2, IThirdRepository repo3) {} // My DoSomething method depends only on repo1 and doesn't use repo2 and repo3 public DoSomething() { //uses repo1 to do some stuff, doesn't use repo2 and repo3 } public DoSomething2() { //uses repo2 and repo3 to do something, doesn't require repo1 } public DoSomething3() { //uses repo3 to do something, doesn't require repo1 and repo2 } } Now if my I have to use DoSomething method on SomeService I end up creating both IFirstRepository,ISecondRepository and IThirdRepository but using only IFirstRepository, now this is bugging me, I can seem to accept that I am un-necessarily creating repositories and not using them. Is this a correct design? Are there any better alternatives? Should I be looking at Lazy instantiation Lazy<T> ?

  Read the article

• How can I optimize my development machine's files and directories? [closed]

  - by LuxuryMode

  Like any programmer, I've got a lot of stuff on my machine. Some of that stuff is projects of my own, some are projects I'm working on for my employer, others are open-source tools and projects, etc. Currently, I have my files organized as follows: /Code --/development (things I'm sort of hacking on plus maybe libraries used in other projects) --/scala (organized by language...why? I don't know!) --/android --/ruby --/employer_name -- /mobile --/android --/ios --/open-source (basically my forks that I'm pushing commits back upstream from) --/some-awesome-oss-project --/another-awesome-one --/tools random IDE settings sprinkled in here plus some other apps As you can see, things are kind of a mess here. How can I keep things organized in some sort of coherent fashion?

  Read the article

• Motivation for service layer (instead of just copying dlls)?

  - by BornToCode

  I'm creating an application which has 2 different UIs so I'm making it with a service layer which I understood is appropriate for such case. However I found myself just creating web methods for every single method I have in the BL layer, so the services basically built from methods that looks like this: return customers_bl.Get_Customer_Prices(customer_id); I understood that a main point of the service layer is to prevent duplication of code so I asked myself - well, why not just import the BL.dll (and the DAL.dll) to the other UI, and whenever making a change re-copy the dll files, it might not be so 'neat', but is the all purpose of the service layer to prevent this? {I know something is wrong in my approach, I'm probably missing the importance of service layer, I'd like to get more motivation to create another layer, especially because as it is I found that many of my BL functions ALREADY looks like: return customers_dal.Get_Customer_Prices(cust_id) which led me to ask: was it really necessary to create the BL just because on several functions I actually have LOGIC inside the BL?} so I'm looking for more motivation to creating ONE MORE layer, I'm sure it's not just to make it more convenient that I won't have to re-copy the dlls on changes? Am I grasping it wrong? Any simple guidelines on how to design service layer (corresponding to all the BL layer functions or not? any simple example?) any enlightenment on the subject?

  Read the article

< Previous Page | 65 66 67 68 69 70 71 72 73 74 75 76  | Next Page >