> The fundamental advice on Unicode is decode and encode on system boundaries. That is, you should never be working on non-unicode strings within your business logic. The same should apply to JSON. Decode it into business logic objects on entry into system, rejecting invalid data. Instead of relying on key errors and membership lookups, leave the orthogonal business of type validity to object instantiation.<p>This right here is the correct approach. Serialisation formats should be serialisation formats, whether they be JSON, S-expressions, protobufs, XML, Thrift or what-have-you; application data should be application data. There are cases where it makes sense to operate on the serialised data directly, for performance or because it makes sense in context, but in the general case operate on typed application values.
I'm not entirely in agreement.<p>Use of object-oriented programming paradigms here would merely distribute the logic that is necessary to achieve the desired mapping over multiple points in the code.<p>The example function presented is only marginally too complicated. I'd split it in two: one to obtain the book list given the same arguments as the example function, and one taking the result as its only argument to build the mapping.<p>I find myself shying away from rigorous adherence to encapsulation more and more these days. I prefer small functions that operate on data explicitly.<p>Edit: and I'm a bit confused how the example has anything to do with "JSON-driven development", other than the coincidence that a hash/dictionary is the core data structure being manipulated here. This example function could exist and be (mostly) reasonable had JSON never existed. I'd expect to see an argument that the JSON serialization schemes that abound are problematic, given the title.
I disagree with the anemic object argument. If an object is just there to store data and no behaviour, then that's fine - don't add behaviour if it doesn't need it. A large portion of back-end services are CRUD and data wrangling operations anyway - as in, convert data format A to data format B (which I guess could be a constructor or factory method if you're comfortable with having the conversion logic in a data class).
The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class".<p>I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata won't catch everything (they have to have a lowest-common-denominator notion of type) but distributed bugs are the hardest bugs to track down; anything that helps you spot a bad network request earlier is well worth having.
This basically repeats the ORM arguments/counter-arguments, but now it's a slightly more complex data structure instead of the DB-row-as-hash/array you get there. "row-driven" in this context often leads to barely wrapped DAO Objects.<p>On the other hand, sometimes (surprisingly often) a hash is good enough and the effort spent in modeling the database (...) doesn't need to be replicated.<p>And as with ORMs/SQL generators/DAOs/etc., there's a whole spectrum of solutions and you really have to look at the task to see what's appropriate...
This isn't JSON-driven development, it's just choosing to apply logic over loose-typed data structures instead of named constructs. It's more awkward in Python because it doesn't have sugar syntax to index an object like JavaScript has.<p>But using clean built-in data structures instead of named types has its benefits especially if you need to serialize for persistence of communication as it doesn't require any additional knowledge of Types in order to access serialized data, so you can happily consume data structures in separate processes without the additional dependency of an external type system that's coupled and needs to be carried along with your data.<p>This is why Redux uses vanilla data structures in its store or why JSON has become popular for data interchange, any valid JSON can be converted into a JavaScript object with just `JSON.parse()` which saves a tonne of ceremony and manual effort then the old school way of having to extract data from data formats with poor programatic fit like an XML document into concrete types.<p>If your data objects don't need to be serialized or accessed outside of the process boundary than there's little benefit to using loose-typed data structures, in which case my preference would be using classes in a static type system to benefit from the static analysis feedback of using Types.
Anemic objects and whether they are harmful or harmless has been debated in software engineering for long.<p>I find over-relying on encapsulation more harmful than useful nowadays specially if you are going to write scalable software that are inherently distributed. For example, hiding accessing a database behind a simple getter function makes another programmer ignore performance implication and other issues that may arise.
It sounds to me like these arguments aren't so much against JSON, per se. They're against using JSON.parse() (or json.loads() in Python, json_decode() in PHP, or whatever) as your entire data-import process.<p>Instead, the argument goes, one should load the JSON, walk the redulting structure, and use it to build your native data structure/objects/whatever. Similarly, when the time comes to save, you crawl through your native structure to build a dict/array/primitive structure, then call JSON.stringify() (or the analogous function) to serialize that.<p>Uncoupling your data structure from the serialization format, though, is really just basic good software design anyway, is it not? Does anyone argue in favor what this article calls "JSON-driven development" as a design principle? Or is it just a shortcut that developers -and I am no less guilty of this than anyone else- sometimes take in the interest of getting a quick-and-dirty solution out the door?<p>Yes, working directly on the output of JSON.parse() is a code smell. But I'm not sure that claiming there's a rising trend of "JSON-driven development" is entirely founded. It's just people taking shortcuts.
While I see the point the Ulaş is getting at, I wouldn't call this JSON-driven development. I think JSON-driven development would use abstraction layers that are based on JSON, like JSON schema, and perhaps an OOP library that leverages it.<p>What I'd actually call this problem is a lack of abstraction. In functional programming, simple data structures are often preferred, and composable functions are used to manage complexity. A functional programmer might declare a function `to_structured_dict(enumerable, path)` and call it with
`to_structured_dict(book_list, path=('shop_label', 'cell_label, 'book_id', count'))`
If you're in Python, and are afraid of "anemic" objects, I would recommend checking out collections.namedtuple. It's a fantastic lightweight and performant object-like data structure.<p>You also get a few additional features, such as in-order iteration, the parameters are fixed at run time, and there's a method for turning it into an ordered dictionary (which is serializable in, wait for it, JSON).
> Once you go dict, you won't go back. This style of development is too easy, since dictionaries are baked into Python, and there are many facilities for working effectively with them.<p>How is this an argument against using dictionaries?<p>After 10 years of Python development, I do find myself using dictionaries rather than objects, in just the way that the author proscribes, but I'm finding it to be a genuine pleasure.
I think this article is somewhat off-base. The problem isn't JSON, it's lack of respect for separation of duties. JSON is just a data exchange format.<p>Want to program in an OO way using JSON? Easy. Just build a factory to generate objects from JSON input. Put your validation and error handling right there. Now you can get a known valid object from the JSON, a class instance with all the encapsulation and business logic your heart desires. Need to share it with the outside world? Provide a JSON output method.<p>Translating data formats is at the heart of day-to-day programming. It ain't rocket surgery. Fix the problem, not the blame.<p>(And if you think JSON sucks, believe me, you never dealt with data file formats from the pre-XML days!)
There is so much wrong with this blog post that I don't even know where to begin. He appears to have included Python-specific details in his list of why he hates lists and dictionaries. Apparently Python throws exceptions if a key doesn't exist and seemingly has no Maybe/Option alternative? I don't know if that is true or not.<p>He claims using lists and dictionaries means you lose encapsulation - does it? A smarter programmer would realise that actually it entirely depends on the _types_ you are storing in those data structures.
The rule of thumb I've always used for when to use OO is "will there be more than one extant object at once or not?" If yes, and especially if these objects need real behavior, then use OO.<p>If you're essentially going through one object at a time, then discarding them, you're may just be doing conduit data processing, and so there's little advantage to using objects. I think what's missing in this (well-written) analysis is this distinction; if you're slurping data from one place, making a few changes (or especially if you're not making any), then sticking into a DB or vice versa, OO may be the wrong choice.<p>Ask yourself while writing the code: "are these active, behavior-driven objects that need encapsulation and relatively sophisticated behaviors, or is this just data I'm doing some relatively simple processing on?"
The author has lots of good points. Because I write most of my Python in the style he is advising against, I recognize that style has issues. The main issue for me is that a dict of dicts of dicts is not an interface. It doesn't have any constraints. It doesn't communicate expectations for use for the actual intent of the code. The best you can do is a comment explaining what to expect and a lot of error checking.<p>That said, almost all of the python I write these days is in the form of functional transforms on built-in data structures. And I love it!<p>There was a great Pycon2012 talk titled "Stop Writing Classes". You can find it linked and discussed here <a href="https://news.ycombinator.com/item?id=3717715" rel="nofollow">https://news.ycombinator.com/item?id=3717715</a>
On the one hand I agree with OP on directly interacting with JSON is not really a good idea but on the other hand I completely disagree with that behavior should be shoved into data objects. Also I think part of the problem is Python doesn't have much typing (I know they recently added optional typing in python but I don't think many use it).<p>As more of an FP guy I'm firm believer of the separation behavior and data. Clojure's Hickey sort of has a valid point... its freaking data... stop making it complicated to access it.
I'm surprised no-one has linked Steve Yegge's Universal Design Pattern – <a href="http://steve-yegge.blogspot.co.uk/2008/10/universal-design-pattern.html" rel="nofollow">http://steve-yegge.blogspot.co.uk/2008/10/universal-design-p...</a><p>It argues that loosely defined objects are an excellent design pattern, but I'm too tired to decide if it is directly relevant to this.
At this point everyone should be using an evolvable (thrift, protocol buffers, avro, etc) schema format when they are storing or transmitting their data if they want to run an always on service - there is no downtime for migrations in the real world. Trying to do this ad-hoc with JSON is a lost cause and will eventually lead you to failure at runtime or worse, data loss situations.
At least lists, dictionaries map relatively well to a tabular (SQL) format. Objects don't map well at all! Anyone who's spent enough time with "mature" ORMs knows this. Especially when there's a deadline and you have to write "native" SQL just to get whatever the hell you needed in the first place. "Well maybe you should have read everything and understood the ORM to its most minute detail..." NO! That's the whole point of abstraction! If I understood everything about that code, I'd be better off re-writing it to better suit MY specific problem. Look, I don't want to be another OO basher. OO definitely has a place in complex systems like game development, where the lives of the objects are longer than a page refresh. But in web dev, its becoming increasingly obvious to me that the OO paradigm is a huge time suck. /rant
I find that code that uses dictionaries a lot ends up with mysterious unnamed types used in various places throughout the system disguised as dictionaries. They have required fields, and must interacted with using business logic that is not obvious. This becomes a real problem when the original authors of the system are gone, and new maintainers have taken over and have to implement new features.<p>By using objects, or lightweight objects like namedtuple, which have already been mentioned in other comments a bunch, you formally document the data-structure. You give it a name, expected fields, and required behaviours when interacting with it. The code becomes much easier to follow and understand clearly. Bugs don't creep in when a new maintainer forgets about the mysterious undocumented required business logic.
Lots of religion in this thread!<p>I think the point is, if json is your data exchange format it <i>could</i> be bad if you let that structure propagate into your application.<p>so in general you should prefer :-<p>json => <chosen languages best form for dealing with data><p>over json => <chosen languages tools for dealing with json><p>Different languages are going to have different mechanisms. Some languages you may abstract from json completely, some languages may natively deal with json, and your persistence layer may deal with json also.<p>So what you need is a well considered design that takes advantage of your chosen languages philosophy / mechanics, whatever that may be. There is no one way to design anything. The thing to avoid is - not working out how to structure your code to make things easy / appropriate to the task at hand. That path leads to messy code.
For crying out loud, you don't have to build an object hierarchy around the thing (although it would make sense to in this case), but at least have the common sense, or the sense of shame, to abstract away data lookups into separate functions. That's data structure abstraction 101.
I take a couple of issues with the author here. I don't personally worry much about breaking away from strict OOP. When a pattern like this develops it is usually because the data is too dynamic for a static property list. An obvious example is for creating reports. No one is going to sit down and hand design every single multi column report in a large project (I tell a lie, people do, it just makes the code base a horror show). By letting the data be more dynamic (Usually with JSON) it is trivial to create generic report structures and populate them.<p>Additionally, if you are using NoSQL as a backing store then solutions like class serialization don't make any sense since you will need to communicate in JSON anyway.
The code in the example has poor encapsulation, but I do not think it's the "JSON" style that causes that.<p>Much OOP code includes a hodgepodge of exposed internal state and methods that offer a combination of derived state and behavior to mutate that state.<p>Often, using data literals (like JSON) can make code clearer by making it explicit what is going on with state (when/if it is being mutated), and making the system easier to snapshot, test, etc.<p>While much code that uses JSON-like constructs is overly verbose and error prone, adding a bit of structural typing (with Flow) or creating schemas to ensure system invariants (jsonschema) can lead to a system that is easy to reason about and maintain.
Use GraphQL or Really stick with RESTful routes. The more predictable the schema of these Dictionaries/hashes/JSON are the less likely you are to see that mess above. This is true whether you are using a FP approach or an OO approach. Using an Imperative coding style when doing ETL will always be hairy.<p>That function also violates the Single responsibility principle. I wouldn't even know where to begin to write a unit test for that other than breaking it down into smaller parts. There are design patterns that could be followed in dynamically typed languages that would avoid that mess altogether other than just OO.
Coupling your code to the JSON you receive over the web can lead to some interesting problems. If the system on the other end decides to make some change you are not expecting, it can lead to errors.<p>In JavaScript, a simple thing that helps is to use lodash.get and provide a path to the property you are wanting.<p><pre><code> lodash.get(someObject, 'path.to.a.property')
</code></pre>
If the path isn't there, the lodash.get returns undefined. This is much nicer than getting the error "Cannot read property 'to' of undefined" when "path" isn't there.
Yes, any useful technology will get over-applied, at the detriment of better ways to do things.<p>Not the fault of the technology, but of the developer who failed to consider alternate ways of accomplishing the same task.
JSON is best when it's solely used for serialization (or config files).<p>Using it deep into the project makes no sense, the first step in handling JSON should always be to code it into native data structures.
I think the "anemic objects[domain model]" is a red herring in this case. It would be much cleaner to create separate serialized and deserializers that convert your actual domain models to JSON and back. By the time you are doing something as shown in his example like building a book inventory it should be all proper objects and no primitives dictated by what should be the serialization layer.<p>Edit: Fixing phone auto correct typo - "property objects" -> "proper objects"
I actually saw this coding style <i>way</i> before JSON, for example at Apple. I even jokingly created DUKE: Developers United against Keyed Everything.<p>Another place I see this is in the eternal dynamic/typing debate. A lot of the criticism of dynamic typing will be with examples from JavaScript, Ruby, Python and maybe even PHP. Hardly ever from Smalltalk (or Objective-C), because Smalltalk code tends to not have the types of problems cited. This puzzled me for a while, because I also find these languages somewhat less "solid", yet couldn't quite put my finger on why.h<p>That is, until I realised that all of these languages use hashes as their basic object representation. Coincidence? I think not. So I coined the term "hash language" for these languages, both because they are hash-based and it appears to be easy to make a hash of things in them, possibly for precisely that reason.<p>That said, I think it's also a mistake to disregard the power this sort of very generic programming brings, especially once you consider objects composed of multiple facets that are interpreted in different contexts.<p>IMNSHO, the way to combat hash-programming is to provide powerful and convenient metaprogramming facilities for object representation, so dealing with objects generically is just as easy and obvious as dealing with dictionaries.<p>Not entirely surprisingly, my own language ( <a href="http://objective.st" rel="nofollow">http://objective.st</a> ) has some facilities for this, mostly by making identifiers into first class entities. More research needed ;-)
Is the OP familiar with Object.keys()?<p>You don't have to hard-code explicit dot notation into your code when you're processing JSON or any other hierarchical object serialization format, which is what JSON is.<p>If you want to make your code more robust, you should process the structure of the JSON document and infer meaning from its keys based upon your position in the tree and of the values of the key names that are meaningful to your application.<p>This makes it possible to accept any kind of JSON, even if the original format changes, and you won't get uncaught exceptions and your application can decide what to do in a more graceful manner.<p>You should also centralize the code that is responsible for serializing and deserializing your JSON wire format and creating objects. There's no reason to have ad-hoc code in each object constructor like his example. A good example of such a thing is dnode <a href="https://www.npmjs.com/package/dnode" rel="nofollow">https://www.npmjs.com/package/dnode</a>. It handles all the JSON abstraction (in this case for RPC) and you don't even need to worry about the JSON ever again.<p>This has nothing to do with JSON and more to do with poor design and tight coupling of interfaces.
I may be missing something, so I'd appreciate a correction, but why all that effort when you can use collections.namedtuple and a custom object_hook for json.loads?<p><pre><code> import json
from collections import namedtuple
data = '{JSON string goes here}'
fancy_data = json.loads(data, object_hook=lambda d: namedtuple('X', d.keys())(*d.values()))</code></pre>
I agree with this and I've raised it several times in Objective-C codebases that can some times end up littered with NSDictionary:s everywhere taking no advantage of the Objective-C type mechanics. I don't think it's necessarily as bad in python or javascript. This is because these languages are dynamically typed and that diminishes the benefits of deserializing json to a native model. It's still valuable because you can guard against bad data by rejecting at the boundary of your program.<p>In statically typed languages however the added bonus is a lot more significant because the type system increases the benefits of deserializing JSON to native models. Take this Swift example<p><pre><code> import Foundation
enum SerializationError: ErrorType {
case InvalidData
}
struct Thing {
let a: Int
let b: String
static func deserialize(fromDictionary data: [String:AnyObject]) throws -> Thing {
guard let a = data["a"] as? Int, let b = data["b"] as? String else {
throw SerializationError.InvalidData
}
return Thing(a: a, b: b)
}
static func deserialize(fromArray data: [[String: AnyObject]]) -> [Thing] {
return data.flatMap {
try? deserialize(fromDictionary: $0)
}
}
}
let data: [[String: AnyObject]] = [
[
"a": 10 as NSNumber,
"b": "Hello" as NSString
],
[
"a": "10" as NSString,
"b": 10 as NSNumber
]
]
let models = Thing.deserialize(fromArray: data)
</code></pre>
Not only do you end up with a native array of models you can also be certain that any type information is correct because invalid results have been thrown away during parsing.
This is what keeps dragging me back to moose & perl5. You describe the attributes of a class, the constructor for that class is created for you, and you can pass in hashes and it will automatically instantiate (and fail if the rules you have set for attributes are not met).<p>I've found that you can kinda sorta do the same with other languages (python/ruby/javascript) by writing static factory builders inside the class that do this checking for you and raise an exception or return an object for you, but it still doesn't compare to me to Moose/Moose::Util::TypeConstraints::coerce/subtype and attributes with the coerce option set. It makes it so easy to coerce a deep json object into a deep class structure.<p>I always try to hunt down things that are similar in other languages (python allows named arguments from a dict, IIRC, and that allows similar things, but you still have to write the constructor yourself), but I've yet to find something that makes it as simple.
And this is where we end up without easy to use and well supported schemas...<p>If this was XML, you'd write a very simple RELAX NG grammar (use the compact syntax: <a href="http://relaxng.org/compact-tutorial-20030326.html" rel="nofollow">http://relaxng.org/compact-tutorial-20030326.html</a> ) that describes the structure of the incoming data, then use it to validate the input data before processing it.<p>After that, you know data is valid and in the right structure, so you can throw away most of the "is this in the right place?" checks.<p>JSON and YAML's various schema implementations can't hold a candle to this, and it's been around for over a decade.<p>The XML ecosystem does have some very bad parts, but it's not all bad, so it's worth learning from places where it actually works well.
I agree that the supplied code is improvable. Consider this:<p><pre><code> def set_r(adict, keypath, val):
key = keypath[0]
if len(keypath) == 1:
adict[key] = val
return
if not key in adict:
adict[key] = {}
set_r(adict[key], keypath[1:], val)
def build_book_inventory(book_ids, shops):
shop_labels = [shop['label'] for shop in shops]
books = Persistency_books_table_read(
shop_labels=shop_labels,
book_ids=book_ids)
inventory = {}
keys = 'shop_label cell_label book_id'.split()
for book in book_list:
keypath = [book[k] for k in keys]
set_r(inventory, keypath, book['count']
return inventory
</code></pre>
First, the author clearly needed "autovivification" as supplied by Perl. We supply a substitute with set_r().<p>Second, I'd avoid creating local variables like "book_id". It creates mess. We never had the slightest interest in the book_id; it's just part of the wine we are pouring from one bottle into another.<p>Third, I've preserved (modulo names) the interface of this function but I suspect the surrounding code could also be improved. Also call a list of books "books", not book_list; list is the assumed sequence container in Python. "books=book_ids" is unfortunate; to thrive in a weakly typed language we need variable names that distinguish objects from ids.<p>Larger point: the author wants to create classes for the various business objects, which is a common enough pattern, but ultimately just makes extra work and redundant lines of code. A relational database can handle a wide variety of objects, with some knowledge of their semantics, without any custom code per-class.<p>As you know, the difference between dicts and objects in python is mostly semantic sugar. We can easily enough make a class that gives dot-notation access to values in a dict, if one objects to the noisiness of foo['bar'].<p>If you want to enforce object schema at system boundaries, there are better ways (more compact, expressive and maintainable) than writing elaborate "classes" for each type of object.
More generally, using data structures well-suited to your problem is really important but often underappreciated in software engineering. Elegant code and algorithms naturally follow.<p>In the example in the article, OO seems like a good way to go.
From an OO perspective I can completely agree with this and the encode/decode pattern the author is suggesting seems to be the right way to deal with this problem as it will also hopefully translate in having an esperanto data type which can be used for all sorts of APIs and formats.<p>But from a functional perspective I would disagree. The code example wouldn't even make sense in that world. You would query it as is and compare it with other data or create new structures as with any other data you handle in your language.
I agree 100% with the article.<p>I've just written a script which makes every one of the mistakes listed in the article. I am consuming a JSON based API in a long ugly mash of code, exactly as described. It doesn't look pretty.<p>In my defence, I wrote the code as I was trying to understand the API. I had not read ahead and didn't really know which API's I would need or how fiddly it would be to bring it all together.<p>I am now exposed to pain if the API changes or if anything breaks. Time to go back and tidy up the code!
JSON is the equivalent of a UNIX pipe; it is for passing data between applications on the Internet, just like a pipe is a way for passing data between applications on a machine.
In PHP we call it "Array Oriented Programming" ( <a href="http://www.epixa.com/2012/04/array-oriented-programming.html" rel="nofollow">http://www.epixa.com/2012/04/array-oriented-programming.html</a> ). So looks like Python developers finally discovered this paradigm too. Let's wait for JS developers now.<p>By the way, PHP has type hints for functions that help to understand what are the types of arguments and the return type.
Just an aside, I'm not sure I agree with the title of "JSON-driven" development.<p>The problem being described is about using parts of a language in an inefficient or ineffective way of solving a problem.<p>The solution to this particular problem can be summed up in concepts like encapsulation or DRY. More to the point, let's not blame components like JSON for basically poor implementation.
I prefer XML + schema (for which I use RelaxNG + jing) because this makes validating the input very straightforward and normalizes that process. But I understand the appeal of JSON and use it for some APIs myself. What experiences do people have with JSON.net Schema? Does anyone know of a json schema + validator system that is cross-language?
I like to wrap relevant objects around a type, that is responsible for creating, validating, serializing, deserializing and mutating that object.<p>But taking a JSON and passing it around, with no ownership, no predictability... it's the mindset of the tech debt programmer.
Thankfully there isn't really JSON <i>driven</i> development as a methodology. Its just a bit of a crappy pattern (for many tasks) that far too many people use. Hopefully no one is advocating it as <i>the</i> way to develop software.
Although I coincidentally mostly agree with the conclusion "encode on entry and decode on exit" I disagree substantially with the rest of the article.<p>> I know that it's now en vogue to sneer at OO<p>I don't <i>sneer</i> at it. OO has been the dominant coding religion for most of my career and I rage against the educators and propagandists who spend a decade smothering everyone with it. I curse them for all the time I wasted trying to build classes for my data only to realize that if I had used a simple dictionary or list my code would be shorter, simpler, more robust, and more flexible.<p>The logic in the article above is all premised on object-oriented religion. OO for OO's sake because OO. Using the power of dictionaries is bad, using the power of objects is good.<p>> It completely defeats object orientation.<p>You could just as easily say using objects defeats the point of having lists and dicts.<p>> It offers nothing of the abstraction powers of object orientation.<p>Most of the abstraction power of object orientation happens when you create the methods. If you aren't defining new classes, you write functions instead. You still have abstractions, what you don't have is the encapsulation of code with data.<p>> It doesn't say what it's doing.<p>Sure it does, and better yet since you are using the standard data types it will be said in a language that any other Python developer is likely understand immediately.<p>> The above code is filled with auxiliary logic that has nothing to do with what it actually tries to achieve.<p>The above code is filled with auxiliary logic because the author of it apparently didn't write any useful functions for operating on dictionaries.<p>I'm not sure that any of the auxiliary logic in that code has anything to do with the choice to use dictionaries. It's a standard data munging problem that comes from having data from different sources. You have the exact same problem with objects if you didn't write any useful methods for operating on them.<p>> but done right, it can be very powerful, especially in big and complex codebases.<p>And in my opinion, the right way to do Object-Orientation in Python is to <i>not do it</i> until you really know you need it: your code is heading towards big and complex and you need to lock it down and organize the data and methods into well-encapsulated classes. (Although maybe at that point you realize it's not a big deal and don't bother)<p>Designing around lists and dicts from the start is a much more flexible strategy than trying to get all the encapsulation exactly right on the first try. If you don't have lots of time to spend up front UML'ing an object heirarchy for your big, complex application, you're probably better off sketching and iterating with JSON in mind (and yaml if humans need to edit it). As your application takes shape, it will become apparent where it makes sense to lock down functions and data into objects.<p>This is especially true given that all of Python's standard types are inheritable classes.
Arguments for dict/list driven development:<p>NOTE: This isn't JSON driven-development, JSON just mimics base types like dict, list, string, numeric etc of all languages and a big reason it is so common especially in Python/Javascript.<p>- Large unknown lists/dictionaries data structures can be deserialized into dicts/lists for any language without issue.<p>Sometimes keys/data are unknown such as large attribute data sets that may always have new keys. In that case strong typing to an OO object will always be broken. Example: a facebook attribute set, keys/data that aren't set will not appear, new ones are added all the time, which would create a cat/mouse serialization/deserialization game. Same problem a binary structure has (offsets) when you really need a flexible keyed structure.<p>One missing key doesn't break your whole serialization/deserialization system built with strongly typed OO. Validation can be done on accept and <i>if necessary</i> convert into an OO system.<p>- If needed, classes that are backed/extended/inherited by a dict/list or set (or composition) that can load in the JSON/dict/lists and only expose the needed values after validation are useful.<p>i.e. a class that inherits from or composes to Dictionary<string,object> for instance in C# would only fill keys that are necessary for the view data, not a bunch of extra null fields because it might not have that key/property. It also has the ability to deserialize objects that may have new keys. Not everything is a perfect world where data structures are known before-hand.<p>- It reduces complexity many times, no need for an OO serialize/deserialize layer when you are passing back as basic dict/list or JSON.<p>Why add complexity to something simple?<p>- Unless you control the server and the client, real-world data structures aren't a perfect map of keys/values to OO properties.<p>Assuming that is a system ready to break in the real-world many times. Someone adds a field to the DB object then all clients that use it can't serialize/deserialize. Real world serialization/deserialization has to accept in basic types dict/list, validate and then use as needed (some go to OO objects behind scenes). I see too many systems where people just have an EF object and expose that over a web api and just expect it to work, that is a bad example of poor encapsulation. Some fields don't need to be serialized to public apis. In Microsoft land MVVM was created to help stop this practice but still creates two sets of OO objects and breaks on any new keys/data (though breaking here may be desired for strong typing).<p>- Dict/list data structures can be easily setup to have cleaner naming and keys without tons of attribute/helpers<p>i.e. first-name key instead of first_name, FirstName, or firstName. This is more friendly to web/url naming that is common.<p>- Noted in the article, less memory used in many cases and highly optimized time in basic lists/dicts.<p>There are many more reasons...<p>Dicts, lists and basic string, numeric types are the base of all languages and computer science types. The reason this is common is it is simple to work with these types without added cruft of OO when needed.<p>OO does add complexity and if it isn't necessary you are just upping complexity for no reason (and memory). It is similar to the complaints of C coders to C++, basic structs and sets are sometimes less complex than C++ OO objects. Same thing with dict/list of some monstrosity of an OO serialization/deserialization system that breaks on every new key or field and you have to update the server and client rather than just increment a version and validation. The longer you code the more you see this.<p>OO objects should not be used all the time just like dict/lists shouldn't be used all the time.
With dynamic languages (certainly Python, Ruby, and JS), there's a definite lack of nudge from the tooling to translate from "interchange" format into an internal "smart" format (procedural code + everything is a hash = easy hacks). Whereas with something like Scala, the tools make it very clear that if you serialize/deserialize on the periphery, you're in for a bag of hurt (or, at the very least, fighting with one hand tied behind your back).<p>This is not to say that one tool is better than the others, but tools do have opinions, and while being more permissive/ambivalent makes throwing together a quick script easier, a tool that nudges you in the direction of building something in a more-sustainable way is useful when building nontrivial systems.
> If an object is just there to store data and no behaviour, then that's fine - don't add behaviour if it doesn't need it.<p>In that case, you want values rather than objects. Alas, Python doesn't have compound values.