principles

Do you prefer compiled or scripted languages? [closed]

由 限于喜欢 提交于 2020-01-04 06:23:12
问题 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago . Since this is wide community using all kind of different technologies, it seems like appropriate place to ask this. Do you like to

Principles for Modeling CouchDB Documents

由 混江龙づ霸主 提交于 2019-12-18 09:59:49
问题 I have a question that I've been trying to answer for some time now but can't figure out: How do you design, or divide up, CouchDB documents? Take a Blog Post for example. The semi "relational" way to do it would be to create a few objects: Post User Comment Tag Snippet This makes a great deal of sense. But I am trying to use couchdb (for all the reasons that it's great) to model the same thing and it's been extremely difficult. Most of the blog posts out there give you an easy example of how

Are there reasons to avoid bit-field structure members?

由 可紊 提交于 2019-12-14 03:44:48
问题 I long knew there are bit-fields in C and occasionally I use them for defining densely packed structs: typedef struct Message_s { unsigned int flag : 1; unsigned int channel : 4; unsigned int signal : 11; } Message; When I read open source code, I instead often find bit-masks and bit-shifting operations to store and retrieve such information in hand-rolled bit-fields. This is so common that I do not think the authors were not aware of the bit-field syntax, so I wonder if there are reasons to

REST Best Practices: Should you return an entity on POST and PUT calls?

由 无人久伴 提交于 2019-12-04 15:59:55
问题 In order to respect the best practices of the REST principles, is it best to return the created/updated entity upon a POST/PUT ? Or return an empty HTTP body with the Location header? More precisely, When a resource is created by a POST, should we return: Status 201 + Location header + (the created entity in the HTTP body) ? or Status 201 + Location header + (empty body) ? When a resource is updated by a PUT, should we return: Status 200 + (the updated entity in the HTTP body) ? or Status 204

Best way to explain OOP Principles? [closed]

由 99封情书 提交于 2019-12-03 14:04:22
问题 Closed . This question needs to be more focused. It is not currently accepting answers. Want to improve this question? Update the question so it focuses on one problem only by editing this post. Closed 5 years ago . 1. Abstraction 2. Encapsulation 3. Inheritance 4. Polymorphism How to best explain these concepts, for example, in an interview? 回答1: 1. Abstraction Show only necessary thing to user that he required, not extra information (use public private, protected). Abstraction is done when

REST Best Practices: Should you return an entity on POST and PUT calls?

由 爱⌒轻易说出口 提交于 2019-12-03 10:07:33
In order to respect the best practices of the REST principles, is it best to return the created/updated entity upon a POST/PUT ? Or return an empty HTTP body with the Location header? More precisely, When a resource is created by a POST, should we return: Status 201 + Location header + (the created entity in the HTTP body) ? or Status 201 + Location header + (empty body) ? When a resource is updated by a PUT, should we return: Status 200 + (the updated entity in the HTTP body) ? or Status 204 (empty body) ? It might be beneficial to study the API's of other folks to see how they do it. Most of

Best way to explain OOP Principles? [closed]

由 倖福魔咒の 提交于 2019-12-03 09:03:33
1. Abstraction 2. Encapsulation 3. Inheritance 4. Polymorphism How to best explain these concepts, for example, in an interview? Waqar Ahmed 1. Abstraction Show only necessary thing to user that he required, not extra information (use public private, protected). Abstraction is done when we need to inherit from certain class but do not instantiate the objects of that class. 2. Encapsulation Group all relevant things together. I.e. encapsulation is wrapping/binding up of data and member functions in single unit. In simple, abstraction is hiding the implementation and encapsulation is to hide

Principles, Best Practices and Design Patterns for functional programming

由 血红的双手。 提交于 2019-12-03 03:43:50
问题 Are there any known principles, best-practices and design patterns that one can follow while writing code in a functional programming language? 回答1: There are folds, unfolds, maps, etc. I consider using them best practice, as it is pretty easy to reason about their behavior, and they often communicate the purpose of a function (for an example, just take a look at the famous Evolution of a Haskell Programmer and contrast freshman with senior, and with professor). 回答2: Design pattern: let types

OO Software Design Principles

由 狂风中的少年 提交于 2019-11-29 21:08:55
I am a huge fan of software design principles such as SOLID and DRY . What other principles exist for OO software design? Note. I’m not looking for answers like "comment your code" but instead looking for OO design principles like the ones discussed by Uncle Bob . A fairly comprehensive list from Wikipedia: http://en.wikipedia.org/wiki/List_of_software_development_philosophies Agile software development Agile Unified Process (AUP) Behavior Driven Development (BDD) Big Design Up Front (BDUF) Brooks's law Cathedral and the Bazaar Code and fix Constructionist design methodology (CDM) Cowboy

Design Principles [closed]

由 你。 提交于 2019-11-29 19:55:39
What principles do you generally follow when doing class design? Principles Of Object Oriented Class Design (the "SOLID" principles) SRP: The Single Responsibility Principle A class should have one, and only one, reason to change. OCP: The Open Closed Principle You should be able to extend a classes behavior, without modifying it. LSP: The Liskov Substitution Principle Derived classes must be substitutable for their base classes. ISP: The Interface Segregation Principle Make fine grained interfaces that are client specific. DIP: The Dependency Inversion Principle Depend on abstractions, not on
订阅 principles